Git은 개발자의 코드를 효율적으로 관리하기 위해서 개발된 '분산형 버전 관리 시스템'이다. Github는 Git Repository를 관리할 수 있는 클라우드 기반 서비스로, 오픈 소스(소스 코드가 공개된 소프트웨어) 기여도 가능하다.
# GitHub 원격 저장소와 로컬 연결
git init
git branch -m main
git remote add origin "github.com/your_ropo.git"
git add .
git commit -m "first commit"
git push -u origin main
기본 설정
🪄 User 등록
git config --global user.name "나의 사용자 이름"
git config --global user.email "내 이메일 주소"
🪄 도움말
git help -all # git에서 제공하는 모든 명령어 확인
git [command] -help # 특정 command에서 사용할 수 있는 모든 옵션 확인
🪄 세팅 및 초기화
git init # 현재 디렉토리를 기준으로 Git 저장소가 생성
git clone [url] # URL을 통해 리모트 레포지토리를 로컬 레포지토리에 복제
🪄 SSH
보안이 강화된 shell 접속으로, CLI 환경에서 다른 PC에 접속하거나 요청할 때 사용한다. 비대칭키로 사용자를 인증한다.
- Settings → SSH and GPG keys → New SSH Key
[SSH 키 생성]
ssh-keygen # ~/.ssh./에 id_rsa(개인키, 비밀키)와 id_rsa.pub(공개키)를 생성한다 = ssh 키 페어
[공개키(Public Key) 복사]
cat ~/.ssh/id_rsa.pub
- Unmodified: Commit 했던 파일을 수정하지 않은 상태
- Modified: Commit 했던 파일을 수정한 상태 → Staged 상태가 되려면 add 해야 한다.
- Staged: Commit 가능한 상태
- restore: discard changes = 변경 사항을 폐기
기본
🍇 commit, tag
commit: 파일 변경사항 묶음이며, 고유한 해시 값이 존재한다.
git status # 다음 커밋을 위해 현재 디렉토리에서 수정된 파일을 확인: staging area, untracked files
git add [file] # 다음 커밋을 위해 파일을 추가: Untracked files → Staging area : Git 관리하에 두기
git reset [file] # 추가한 파일을 언스테이징, 변경 사항 유지
git diff # 스테이지되지 않은 변경 사항 보기
git diff --staged # 스테이지했지만 커밋하지 않은 변경 사항
git commit -m “message” # 스테이지된 컨텐츠를 메시지와 함께 커밋(스냅샷 생성)
git restore [파일명] # Commit 혹은 staged 되지 않은 변경 사항 폐기: Clone 받은 상태로 돌아가기!
🍇 branch, tag
branch는 메인 개발 코드를 그대로 복사하여 새로운 기능 개발을 할 수 있는 버전 관리 기법이다. tag와 함께 커밋의 이름표라고 할 수 있다.
브랜치와 태그의 차이점은 새로운 커밋을 생성해 보면 알 수 있다.
- tag: 새로운 커밋에 옮겨 가지 않고, 하나의 커밋을 가리킨다.
- branch: 새롭게 생성된 커밋을 가리킨다. (가지 자체가 아니다. 새로운 커밋을 옮겨 다닌다.)
git branch # 목록
git branch [branch-name] # 새로운 브랜치 생성
git switch [branch-name] # 브랜치 전환
git checkout [branch-name]
git switch -c [branch-name] # 새로은 브랜치를 생성하고 전환
git checkout -b [branch-name]
git branch -d feat/todo # 머지된 브랜치 삭제
git branch -D feat/todo # 브랜치가 합쳐지지 않았는데 삭제하고 싶다면 -D 옵션을 사용
git tag v0.0.1
git tag -d v0.0.1 # 삭제
🍇 merge
두 브랜치를 하나의 작업으로 합치고 싶을 때 사용한다. 두 브랜치의 변경 사항을 모두 담은 merge commit이 생긴다. merge 충돌이 났을 때는 직접 파일을 열어서 수정해야 한다.
git merge [이동하고 싶은 브랜치] # 현재 브랜치에 특정 브랜치의 히스토리를 병합
🍇 log
별칭을 생성해서 로그를 간단하게, 간편하게 확인할 수 있다.
git log # 현재 브랜치의 모든 커밋 히스토리 확인
git config --global alias.l "log --oneline --decorate --graph"
git config --global alias.la "log --oneline --decorate --graph --all"
심화
🍎 비교 및 검사
git log branchB..branchA # 브랜치B에 없는 브랜치A의 모든 커밋 히스토리
git log --follow [file] # 해당 파일의 변경 사항이 담긴 모든 커밋을 표시(파일 이름 변경도 표시)
git diff branchB...branchA # 브랜치A에 있지만 브랜치B에 없는 것의 변경 내용(diff)을 표시(branch간 상태 비교)
git difftool
🍎 공유 및 업데이트
git remote add [alias] [url] # url을 통해 특정 리모트 레포지토리를 별칭으로 추가
git fetch [alias] # 별칭으로 추가한 리모트 레포지토리에 있는 모든 브랜치 및 데이터를 로컬로 가져오기
git merge [alias]/[branch] # 리모트 브랜치를 현재 작업중인 브랜치와 병합하여 최신 상태로 만들기
git push [alias] [branch] # 로컬 브랜치의 커밋을 리모트 브랜치로 전송
git pull # 리모트 레포지토리의 정보를 가져와 자동으로 로컬 브랜치에 병합
# git pull <pair> <branch>
git remote -v # 현재 Local Repository와 연결된 모든 Remote Repository 목록 확인
git push [<origin> <branch>] # origin: 프로젝트가 복제된 원격 저장소의 약칭, 원격 저장소의 <branch> 브랜치에 업로드
🍎 cherrry-pick, rebase
체리케이크에서 체리만 똑! 떼어서 먹고 싶을 때를 상상해 보자. 다른 브랜치에서 특정 커밋만 가지고 올 수 있다. 복사의 개념이므로 원본과 해시값이 다르다.
git cherry-pick [가지고 싶은 커밋 아이디]
git cherry-pick [가지고 싶은 커밋 아이디] [하나 더] [하나 더 가지고 올래]
git cherry-pick b2 .. b4 # b2 다음인 b3 커밋부터 b4를 가지고 온다
🍎 rebase, reset: 히스토리 수정
rebase는 베이스를 변경하는 것이다. 커밋을 수정하거나 히스토리를 지울 수 있다.
git rebase [branch] # 특정 브랜치의 분기 이후 커밋을 현재 작업중인 브랜치에 반영
git reset --hard [commitish] # 득정 커밋 전으로 돌아가며 스테이지된 변경 사항을 모두 지우기
Local에서 commit 한 내용을 취소한다.
git reset HEAD^ # 가장 최신 commit 취소, HEAD: 연속된 ^의 shortcut, HEAD3 = HEAD^^^
- merge: 두 브랜치를 합쳐서 머지 커밋이 생긴다. 부모가 둘이다.
- rebase: 두 브랜치를 합치는 것과 같지만 부모는 하나이다. 다른 팀원의 로컬에서는 상태가 다르므로 강제 push를 하고, 팀원도 강제로 pull을 받아야 한다. 충돌 문제가 발생하므로 여러 사람과 협업을 할 때는 merge를 사용하자.
🍎 임시 저장
브랜치를 전환하기 위해 변경되었거나 추적 중인 파일을 임시로 저장한다.
git stash # 수정하거나 스테이지된 변경사항을 스택에 임시 저장하고 현재 작업 내역에서 지우기
git stash list # 스택에 임시 저장된 변경사항의 목록 보기
git stash apply # 스택에 임시 저장된 변경사항을 다시 현재 작업 내역에 적용
git stash pop # 스택에 임시 저장된 변경사항을 다시 현재 작업 내역에 적용하고 스택에서 삭제
git stash drop # 스택에 임시 저장된 변경사항을 삭제
🍎 충돌 해결
같은 부분을 변경한 내용이 존재해서 자동으로 병합할 수 없을 때 자동 병합이 실패된다. git status 명령어를 통해 어떤 파일이 충돌하는지 확인하고, IDE에서 하나하나 직접 확인하여 수정이 필요하다.
- Accept Current Change: 내가 수정한 내용으로 반영
- Accept Incoming Change: Remote Repository 내용으로 반영
- Accept Both Changes: 변경 사항 모두 반영
- 혹은 직접 수정
수정을 마치면 병합 커밋(merge commit)을 생성해 주기 위해 파일을 staging area로 추가해야 한다. 자동으로 Commit 메시지가 생성된다.
Git flow
브랜칭 전략
Coz' Git flow
Git flow를 단순화했다.
- main: 사용자에게 언제든 제품으로 출시할 수 있는 브랜치
- dev(elopment): 다음 버전 배포를 위한 "개발 중" 브랜치
👉 CI/CD 파이프라인이 잘 구축되어 있다면 dev 브랜치의 코드도 배포를 해 두고 확인 가능 - feat(ure)/{작업 이름}: 기능 개발, 리팩토링, 문서 작성을 위한 브랜치
👉 Conventional Commits
👉 각 개인의 로컬 리포지토리에서 만들고 작업한다.
merge 전략
- rebase-and-merge: 커밋 기록을 남긴다.
- squash-and-merge: 기능마다 깔끔하게 커밋을 남긴다.
'Etc > CS' 카테고리의 다른 글
SPA(Single Page Application)를 만드는 기술: AJAX (0) | 2022.08.02 |
---|---|
[네트워크] 웹 애플리케이션 작동 원리 - 네트워크를 만드는 기술 (0) | 2022.08.02 |
Linux - 패키지, 사용 권한, 환경변수 (0) | 2022.06.30 |
Linux - CLI 기본 명령어 (0) | 2022.06.30 |
Windows 개발 환경 세팅 (0) | 2022.06.24 |
댓글