깃 브랜치 Git Branch

Creating branch

git branch testing #새로운 브랜치 만들기
git checkout -b testing #새로운 브랜치 만들고 그 브랜치로 이동
git switch -C testing #새로운 브랜치 만들고 그 브랜치로 이동

git checkout testing #해당 이름 브랜치로 이동
git switch testing #해당 이름 브랜치로 이동

Managing Branch

git branch #local의 모든 브랜치의 간단한 리스트 보기
git branch -r #remote 브랜치 보기
git branch --all #local과 remote 브랜치 모두 보기

git branch -v #각 브랜치들의 최근 커밋 보기

git branch --merged #현재 브랜치에 merge된 브랜치 보기
git branch --no-merged #현 브랜치에 merge되지 않은 브랜치 보기

git branch -d testing #브랜치 삭제
git push origin --delete testing #remote에 브랜치 삭제 반영

git branch --move wrong correct #브랜치 이름 변경
git push --set-upstream origin correct #remote에 브랜치 이름 변경 반영

Comparing

git log branch1..branch2 #branch1과 branch2 사이의 모든 커밋 보기
git diff branch1..branch2 #branch1과 branch2 사이의 바뀐 코드 보기

Merge

fast-forward merge : 새로운 브랜치가 생성된 후에 새로운 커밋이 생기고 그 동안 기존(보통 main)브랜치에서는 변경사항이 없는 경우, 기본적으로 merge를 하면 main브랜치의 pointer만 옮기는 fast-forward merge가 된다. 마치 원래 그 브랜치에서 작업했던 것처럼 히스토리에 머지사실이 남지 않는다.

$ git merge [합칠 브랜치 명]

모든 merge 사실을 기록으로 남기길 원한다면 fast-foward가 아닌 three-way merge를 통해 merge commit을 남겨야 한다.

$ git merge —no—ff [합칠 브랜치 명] → 커밋 메세지 입력

merge 후에는 기존 브랜치를 삭제하도록 한다. $ git branch -d 기존브랜치

Three-way merge

fast-forward merge가 불가능한 경우

Merge Conflict

merge → conlict → 해결(수정) → continue → merge commit

동일한 파일을 두 브랜치에서 수정해서 충돌이 나는 경우.

터미널에서 수정해도 되고 tool을 사용해서 수정해도 된다.

merge conflict를 할 때는 다른 코드는 수정하지 않는다.

fast-forward merge가 아니기 때문에 merge commit이 만들어진다. 다음 화면과 같은 창이 뜨면 commit message를 작성하고 저장하고 닫으면 머지가 완료된다.

git merge featureA #현지 브랜치에 featureA의 내용을 머지. 내용에 따라 fast-forward merge되거나 conflict가 발생함.
git merge --squash featureA #suqash merge, only one commit
git merge --no-ff featureA #fast-forward가 아닌 merge commit을 만들며 병합 
git merge --continue # 충돌 수정 후 머지 계속하기
git merge --abort #머지 취소
git mergetool #git merge 후 conflict 발생했을 때 mergetool을 실행해 보고 편집 

Merge tool Config

vscode로 merge편집 후 원래 충돌났던 파일이 .orig(예 main.orig)로 생성되는데 이것을 끄는 옵션

$ git config --global mergetool.keepBackup false

기존 남아있는 untracked .orig파일 삭제하려면 $ git clean -fd (force directory)

무료로 이용가능한 merge tool ⇒ p4merge 검색 후 다운로드

[merge]
    tool = vscode #p4merge로 변경 가능
[mergetool]
	keepBackup = false
[mergetool "vscode"]
    cmd = code --wait $MERGED
[mergetool "p4merge"]
    path = "/Applications/p4merge.app/Contents/MacOS/p4merge"

Rebasing

rebase로 브랜치가 파생된 시점의 포인터를 변경하면 fast-forward merge가 가능해진다. 혼자 브랜치에서 작업할 때 매우 유용한다.

단, 다른 개발자와 같은 featureA 브랜치에서 작업중이라면 주의해야 한다.

rebase를 하면 e가 가리키고 있는 포인터를 d에서 g로 변경하게 되는데, 이렇게 포인터를 변경하면 기존의 commit이 유지되는 것이 아니라 새로운 e, f의 커밋이 만들어진다. 겉으로는 같아보이지만 실제로는 다른 e, f의 commit이 생기는 것이다. 만약 다른 개발자가 동일한 브랜치에서 작업중인데 내가 rebase 후 push로 서버에 변경된 정보를 업데이트 하게되면 다른 개발자가 가지고 있는 e, f의 커밋과 새로 업데이트한 e, f의 커밋은 전혀 다른 커밋이기 때문에 나중에 Merge Conflict가 발생할 수 있다.

다른 개발자와 같은 브랜치에서 작업을 하고 있고, 이미 히스토리가 서버에 업로드되어 있는 경우라면, 업로드된 히스토리는 절대 rebase하면 안된다.

git checkout feature-a #브랜치 이동 후
git rebase master #최근 마스터 브랜치 커밋으로 포인터 리베이스
git branch -d feature-a #기존 브랜치 삭제

master에서 파생된 service 브랜치에서 파생된 ui 브랜치인데 service 브랜치 내용은 사용하지 않고 ui 브랜치 내용만 사용하고자 할 경우 rebase —onto를 사용한다.

git rebase --onto master service ui #take commits of the ui branch forked from the service branch and move them to master

최신 master브랜치 커밋에 ui브랜치 내용이 옮겨지므로 fast-forward merge가 가능해진다.

같아보이지만 실제로는 새로운 커밋이 생성되므로 rebase와 마찬가지로 다른 개발자와 작업하거나 서버에 이미 히스토리가 올려져 있으면 사용하지 않는다.

Cherry picking

브랜치에서 작업이 오래걸리거나, 파생된 브랜치에서 작업중인 여러 커밋 중 특정한 커밋만 main으로 합치고자 할 경우 cherrypick을 사용한다.

master branch에서 가져오고자 하는 hash로 cherry-pick

git cherry-pick hash #applies the given commit