[git] Command

1. git 기본 명령어

$ git init 명령어

• $ git init

현재 디렉토리에서 git 버전 관리함을 선언합니다. 이때 .git directory가 생성됩니다.

 

 

$ git config 명령어

• $ git config --global user.name 'name'
• $ git config --global user.email 'email@gmail.com'

 

git 유저명 및 이메일을 설정하는 명령어입니다. 만약 git commit 할 때 로그인이 안되어 있으면 에러가 발생해서 위 방식으로 로그인 해야합니다.

 

 

$ git add 명령어

• $ git add test.txt
• $ git add .

add 명령어는 해당 파일을 추적하겠다는 의미인데, 추적된 파일들은 staging area[.git directory안에 index file]로 올라갑니다. staging area는 commit될 파일들이 모여있는 임시 저장소라고 생각하면 됩니다. 즉, commit을 하면 staging area 위에 올라가있는 파일들이 새로운 스냅샷을 만들고, 이 staging area 위에 파일을 올리는 행위가 git add 명령어입니다.

 

 

$ git commit 명령어

• $ git commit #이후 vim에서 commit 메시지 작성
• $ git commit -m "message"
• $ git commit am "message" # add 명령어 없이 바로 commit이 가능
• $ git commit --amend # 커밋 메시지를 수정하고 싶을 때 사용합니다.

staging area에 있는 스냅샷들을 로컬 repository에 추가하는 명령어입니다. commit을 실행하면 .git/objects 디렉토리에 git object가 생성됩니다. 또한, 커밋들은 hash를 사용한 commit id로 구분되며 나중에 이력을 편하게 보기 위해 '버그 수정', '기능 추가'등 작업 별로 구분해서 커밋하는 것이 좋습니다.

 

※ git scenario example

1. $ git init # git repo 관리 선언
2. $ git add test1.txt # staging area에 파일 추가
3. $ git add test2.txt # staging area에 파일 추가 
4. $ git commit -m "add test file" # staging area에 있던 파일들을 git db에 저장

 

2. git branch

마스터 기둥으로부터 필요에 따라 브랜치 가지들로 나눠 작업을 할 수 있습니다.

메인 작업을 하는 도중 브랜치를 따서 작업을 진행하면, 마스터 브랜치에 머지하기 전까지 아무런 영향을 끼치지 않습니다. 만약 맡은 기능을 모두 완성하면 마스터 브랜치로 머지 합니다. 그러면 마스터 브랜치에 변경사항이 적용됩니다.

브랜치를 통합하는 방식에는 크게 'merge'와 'rebase' 2가지가 존재합니다.

 

 

git branch sample

사용 예시

• 잘 돌아가고 있는 프로젝트를 건들지 않고 새로운 기능을 추가, 테스트, 버그 수정을 할 때 유용합니다. 예를 들어, 주 작업을 하는 마스터 브랜치에서 추가되는 기능을 구현하는 branch를 만들고 작업을 하다 다 구현이 되면 master branch로 merge합니다.
• 팀 프로젝트 시, 각자가 맡은 기능을 진행하고 중간중간 머지하는 과정에서 즉, "협업"시 유용합니다.

 

명령어

• $ git branch : 작업중인 working directory의 branch들을 보여줍니다.
• $ git branch branch_name : 새로운 branch를 생성합니다.
• $ git branch -d branch_name : 해당 branch를 삭제합니다.
• $ git checkout branch_name : 작업할 branch로 이동합니다. 이때 index[staging area]와 working directory의 파일들이 변경된 branch를 기준으로 변경됩니다.

 

3. git merge

서로 다른 두 브랜치의 작업을 하나로 합칠 때 사용하는 명령어입니다. 이때, merge를 수행하면 시간순으로 커밋이 기록됩니다. 반면 rebase는 시간순 커밋이 아니기 때문에 플로우는 간단하지만 히스토리 기록용으로는 적절치 않습니다.

 

명령어

• $ git merge target_branch
• $ git merge target_branch --no--ff # fast-forward임에도 merge commit을 남깁니다.

 

주의 할 점

• 항상 어떤 branch에 merge 할 것인지를 확실히 정하고, 해당 branch로 checkout 해야합니다. 즉, 반드시 코드가 반영될 branch(주로 master)에서 merge를 수행해야합니다.
• 다른 branch로 checkout 할 때는 branch의 변경된 사항을 모두 add하고 commit 한 뒤에 checkout하는것이 좋습니다. working 디렉토리의 파일이 날라갈 수도 있습니다.

 

fast-forward merge

현재 branch의 헤드가[아래 그림에서 master] 변경이 일어난 branch의[아래 그림에서 function] base commit과 동일한 경우 현재 branch(master)의 head를 변경이 일어난 branch의 head로 올려버립니다. 즉, function branch는 master branch의 모든 이력을 갖고 있기 때문에 master branch의 head를 단순히 올리기만 하면 됩니다.

 

 

fast forward merge

 

하지만 아래 그림처럼 새로운 branch가 기존 branch의 모든 이력을 모두 포함하지 않는 경우 fast-forward merge가 안됩니다.

 

 

3 way merge

아래 그림처럼 새로운 branch가 기존 branch의 모든 이력을 포함하지 않는 경우(red commit 때문) fast forward merge가 안됩니다. 즉, 간단하게 master head만 단순히 움직여서 해결이 힘듭니다. 따라서 새로운 머지 커밋을 만들어[이를 merge commit이라고 부릅니다.] 문제를 해결합니다. 하지만 fast forward merge보다 그래프가 복잡하여 git rebase를 사용하는 경우도 있습니다.

3 way merge

 

※ git merge scenario example

1. $ git branch
2. $ git branch test_branch
3. $ git checkout test_branch
4. $ test_branch에 작업 진행 (git add . -> git commit 반복)
5. $ git checkout master
6. $ git merge test_branch
7. $ git merge -d test_branch

 

4. git rebase

$ git rebase base_branch

현재 브랜치의 base commit을 새롭게 설정한다는 의미입니다.  즉, 현재 브랜치의 base commit을 base_branch의 head로 이동합니다.

 

rebase example

1. $ git checkout function # 아래 그림에서 위에가 master, 아래가 function 브랜치입니다.
2. $ git rebase master   # 현재는 function 브랜치인데, base commit을 master의 head로 옮깁니다.
3. $ git checkout master # master branch로 이동합니다.
4. $ git merge function # master 브랜치를 fast-forward 합니다.

 

git rebase

 

3 way merge와 실행 결과는 같지만 커밋의 히스토리가 달라집니다.

• merge는 쉽고 안전하지만 커밋 히스토리가 지저분합니다.
• rebase는 커밋 히스토리를 깔끔하게 관리 할 수 있습니다. 하지만 로그 히스토리 순서가 바뀔 수 있어 시간순의 이력을 파악하는데 어렵고, 잘못 사용할 경우 커밋들이 꼬일 수 있습니다.

 

※ Automatic merge failed; fix conflicts and then commit the result.

다른 브랜치에서 수정한 파일을 자신의 브랜치에서도 중복으로 수정하면 나오는 로그입니다. 이는 수동으로 수정하면 문제 해결이 가능합니다.

 

 

※ git rebae 활용 예제

master는 release된 브랜치, server는 개발중 브랜치, client도 개발중인 브랜치인 상황을 가정해봅니다. 그런데 client 브랜치를 급하게 릴리즈 버전에 업데이트 한다면 C8, C9 커밋을 마스터 브랜치에 merge 해야합니다. 물론 3 way merge를 한다면 지금까지 배운 방식으로 처리할 수 있지만 work flow가 조금 복잡해집니다.

이런 경우 server 브랜치와 server 커밋 히스토리에 영향을 주지 않고 rebase할 수 있는 옵션이 있습니다.

git rebase example-1

 

$ git rebase --onto [newbase] [upstreawm] [branch]

newbase인 master, upstream인 branch의 공통조상 C3, 대상 브랜치인 client 이 3가지를 활용합니다.

 

• $ git rebase --onto master server client

git rebase example 2

 

• $ git checkout master # change branch
• $ git merge client # fast forward merge 

git rebase example 3

 

• $ git checkout server # change branch
• $ git rebase master # server 브랜치의 base commit을 master head로 이동합니다.
• $ git checkout master
• $ git merge server # fast forward merge

 

git rebase example 4

 

요약

merge
서브 브랜치의 이력 모두를 기록하며, 머지 커밋은 두 개의 부모 커밋을 가집니다. 모든 히스토리를 파악할 수 있지만 복잡한 플로우를 야기합니다.
$ git checkout master
$ git merge my-branch

squash and merge
서브 브랜치의 이력을 기록하지 않으며, 머지 커밋은 한 개의 부모 커밋을 가집니다. 일부 히스토리를 파악할 수 있지만 깔끔한 플로우를 가집니다.
$ git checkout master
$ git merge --squash my-branch

rebase and merge
서브 브랜치의 이력 모두를 기록하며, 각 커밋은 한 개의 부모 커밋을 가집니다. 하지만 각 커밋은 시간순의 히스토리를 파악하는데 어려움이 있습니다.
$ git checkout my-branch
$ git rebase master
$ git checkout master
$ git merge my-branch

merge strategy

 

 

Reference)

https://velog.io/@kwonh/Git-Rebase%EB%9E%80

[Git] Rebase란?

https://devye.tistory.com/27

[Git] Branch를 만들어보자! 🌿

https://www.git-scm.com/

Git