Git & Github 실무 활용 완벽 가이드 part2. (브랜치와 변경사항 처리 방법)

 

 

이전 part1에서는 깃의 기본적인 소개와 add로 스테이지 올리고 커밋하는 등의 기초 명령어를 다루었다.

 

이번 내용에서는 

섹션 6 : 브랜치로 작업하기

섹션 7 : 브런치 병합하기

 

브랜치 생성 및 병합과 충돌에 대해 정리해보았다.

 

 

 

---

 

 

 

섹션 6 : 브랜치로 작업하기

브랜치란?

 

• 이렇게 커밋이 순차적이라면 어떤 버그를 해결하기 위해 롤백하고 수정하는 등의 작업이 다른 작업과 충돌하여 문제가 생길 수 있다.
• 따라서 독립적으로 작업하는 것이 필요하다. 일부 작업들은 다른 사람들의 코드를 망쳐버릴 수 있다.
• 그래서 브랜치가 필요하며 깃 브랜치로 독립적으로 작업하고 합치는 것이 가능하다.

❇️   브랜치는 깃의 가장 특징적인 기능이며 프로젝트에서 일종의 타임라인 같은 것이다.
❇️   한 브랜치에서 작업한 내용은 다른 브랜치에 영향을 미치지 않고 독립적이다.

 

하나의 레포에서 다양한 브랜치로 뻗어나가고 합쳐지기도 한다

 

 

 

---

 

 

 

마스터 브랜치

 

master 브랜치.

새 저장소를 만들었을 때 생기는 기본 브랜치 이름으로 git init 명령을 실행했을 때 자동적으로 시작하는 브랜치가 바로 master이다.

userpc@DESKTOP-UQ5OHLV MINGW64 ~/Downloads/git_study/test (master)
$ git status
On branch master
nothing to commit, working tree clean

 

 

보통 마스터 브랜치를 공식적인 작업 코드 베이스로 취급한다. 따라서 다른 브랜치에서 작업하고 커밋해서 테스트해서 만약 제대로 작동하면 마스터로 돌아와 그것들을 결합한다.

 

++ 2020년 깃헙에서 기본 브랜치명을 master → main으로 변경한다고 했으나 이는 깃헙에서만 적용되며 실제 로컬 깃에서는 여전히 마스터로 표기되어 있다.

 

 

---

 

HEAD

브랜치 생성에 대해 알아보기 전에 알아야할 개념 한가지. 바로 HEAD이다.

 

 

git log에서 HEAD -> master 로 표시된 것을 볼 수 있다

헤드는 깃 용어 중 하나로 저장소에서 현재 우리의 위치를 가리키는 포인터이며 브랜치 레퍼런스를 가리킨다.

헤드는 우리가 보거나 확인하고 있는 현재 위치를 말하는 것으로, 언제나 master 브랜치에서 가장 최근에 커밋한 브랜치를 가리킨다.

헤드는 브랜치 포인터에 대한 레퍼런스 포인터이고 브랜치 포인터는 현재 브랜치가 있는 위치이다. 책의 북마크와 같다.

 

 

마스터 브랜치에서 Fitz, Ethel 브랜치로 옮기게 되면 해당 브랜치의 헤드는 가장 최근-마지막에 커밋한 곳이 헤드가 된다.

 

 

 

---

 

 

Git Branch

git branch : 해당 저장소의 브랜치들을 확인하는 명령어. 현재 존재하는 브랜치 목록만 보여준다

 

현재는 브랜치가 마스터 하나만 있으며, 현재 위치한 브랜치 왼쪽에 *로 표시해준다

 

 

---

 

 

브랜치 생성 및 전환

 

🔸 git branch <branch-name> : 새 브랜치를 생성한다. 브랜치 이름은 공백을 포함해선 안된다.

🔸 git switch <branch-name> : 브랜치 이동.

 

새로 생성한 브랜치에서 커밋한 내용들은 master 브랜치에 적용되지 않고 독립적이다

 

 

 

---

 

 

 

 

Git Checkout vs Git Switch

🔸 git checkout <branch-name> : git switch <branch-name> 명령과 동일한 작업을 수행한다. 브랜치 이름으로 이동하거나 작업 트리를 복원하기 위해 이 명령을 사용할 수 있다.

 

🔸 git switch -c <branch-name> : 브랜치를 이동하려면 먼저 브랜치를 만들어야하지만 -c 옵련을 통해 브랜치를 생성하고 이동하는 작업을 한번에 할 수 있다. -c 옵션을 넣지 않고 브랜치를 생성 및 이동하려면 에러가 발생하므로 옵션을 주의할 것.

git checkout -b <branch-name> 해당 명령어도 브랜치 생성 및 이동과 같은 동작을 수행한다.

 

 

스테이징되지 않은 변경사항으로 브랜치 전환하기?

 

동일한 파일에 대해 수정하고 다른 브랜치로 이동하려면 -

 

브랜치를 이동하기 전에 커밋이나 스태시하라고 에러가 뜬다. 즉 커밋되지 않았기 때문에 다른 브랜치로 이동하려고 하면 사라질 것이라고 경고하고 있다.

하지만 동일한 파일이 아닌 새로운 파일을 생성한 뒤 브랜치를 이동하면 - 위와 같은 에러가 뜨지 않고 추적되지 않은 파일이 있고 커밋하지 않았다고 뜬다.

 

 

 

브랜치 삭제 및 이름 바꾸기

🔸 git branch -d <branch-name> : 브랜치 삭제. 브랜치를 삭제하려면 자기 자신의 위치에서는 삭제할 수 없다. 이건 터미널에서 rm으로 디렉토리 삭제하는 것과 동일하다.

브랜치 삭제 테스트를 위해 임의의 브랜치를 생성하고 삭제해봤을 때 첫번쨰는 위치에 대한 에러가, 두 번째는 완전히 병합되지 않았다고 뜬다.

 

userpc@DESKTOP-UQ5OHLV MINGW64 ~/Downloads/git_study/roadtrip (deletme)
$ git branch -d deletme
error: cannot delete branch 'deletme' used by worktree at 'C:/Users/userpc/Downloads/git_study/roadtrip'

---

userpc@DESKTOP-UQ5OHLV MINGW64 ~/Downloads/git_study/roadtrip (master)
$ git branch -d deletme
error: the branch 'deletme' is not fully merged
hint: If you are sure you want to delete it, run 'git branch -D deletme'
hint: Disable this message with "git config advice.forceDeleteBranch false"

 

두 번째의 경우 대분자 -D 옵션을 사용해 병합 상태 상관없이 브랜치 강제 삭제를 진행할 수 있다. 예제의 경우 병합된 내용이 없으므로 강제 삭제한다.

 

 

🔸 git branch -m <another branch-name> 

 

userpc@DESKTOP-UQ5OHLV MINGW64 ~/Downloads/git_study/roadtrip (master)
$ git switch recentish-music
Switched to branch 'recentish-music'

userpc@DESKTOP-UQ5OHLV MINGW64 ~/Downloads/git_study/roadtrip (recentish-music)
$ git branch -m 2000s

userpc@DESKTOP-UQ5OHLV MINGW64 ~/Downloads/git_study/roadtrip (2000s)
$ git status
On branch 2000s
nothing to commit, working tree clean

 

브랜치 이름 변경은 삭제와 달리 해당 브랜치에 위치해야한다. 터미널에서 move로 파일명을 변경하는 것과 비슷하다.

 

 

 

 

 

 

---

 

섹션 7 : 브랜치 병합하기

병합은 브랜치 작업의 필수적인 특징 중 하나이다. 병합시 git merge 라는 명령어를 사용한다.

master 브랜치에서는 어떤 실험도 수행하지 않으며 다른 피처 브랜치에서 작업후 테스트를 거쳐 적절하다고 판단되면 master 브랜치에 해당 작업을 병합시킬 수 있다.

 

1. 병합은 특정 커밋이 아닌 브랜치를 병합한다. 원하는 커밋들을 선택해서 결합할 수 없다.

2. 항상 현재 헤드 브랜치에 병합한다.

 

 

두 번의 커밋이 실행된 Bugfix 브랜치를 master 브랜치에 병합하기를 원한다.

먼저 첫단계는 병합하길 원하는 브랜치로 이동한다. 따라서 master 브랜치로 이동한다.

 

 

 

먼저 git switch master로 마스터 브랜치로 이동한 뒤, git merge bugfix를 통해 Bugfix 브랜치에서 커밋된 내용을 병합하여 master를 동일한 커밋으로 이동시켜 몇 개의 커밋을 빨리 감기 하였다.

뒤의 내용에서 이러한 빨리 감기 병합에 대해 다룰 예정이다.

2개의 브랜치가 있고 브랜치 중 하나는 첫번째 브랜치가 갖고 있지 않은 추가 커밋을 갖고 있다. 따라잡기 위해서는 포인터를 앞으로 옮기면 된다. 이것이 git merge 명령이 이런 예제에서 수행하는 작업이다.

 

 

git merge bugfix, 이 명령은 만약 우리가 master 브랜치에 있다면 포인터를 bugfix로 옮기는 것이다. 그래서 이제 master도 모든 이력을 갖게 되는데 이전 작업뿐 아니라 bugfix가 갖고 있는 작업들을 모두 갖는다.

 

 

빨리 감기 병합 수행하기

 

1. 목적지, 병합하려는 브랜치로 이동. 여기의 경우 master 브랜치로 이동.
2. git merge 명령에 master로 병합하고 싶은 브랜치 이름 추가하기. 이 명령어를 통해 master가 bugfix 브랜치에서 이 두 커밋을 따라잡을 것임. 다른 상황에서 bugfix에는 없고 master에만 존재하는 커밋이 있을 경우에는 추가적인 작업을 해야하고 또는 충돌 정보가 있을 수 있다.

강의에서는 이전에 실습을 통해 만들어둔 플레이리스트 텍스트 브랜치들을 활용하였다.

master브랜치에서 분기되어 나온 브랜치에 여러번 커밋되어 내용이 추가된 브랜치를 병합하는 작업.

master에 oldies 브랜치를 병합하면 커밋했던 내용들을 따라잡으면서 oldies의 모든 노래가 추가되며 업데이트가 된다. 로그를 확인해보면 커밋 또한 추가되있음을 볼 수 있다.

여기서 주의할 점은 병합한다고 해서 병합했던 oldies 브랜치가 삭제되지 않고 여전히 남아있으며 oldies로 돌아가서 새로운 작업을 하면 이 내용들은 master에 실시간으로 반영되는 것이 아니다. 여전히 독립성을 유지한다.

 

 

 

병합 커밋 생성하기

 

작업 후 마스터 브랜치에 병합하려 할 때 다른 사람이 이미 마스터 브랜치에 작업하여 bugfix 브랜치에는 없는 10개의 커밋이 마스터 브랜치에 있는 상황. 이러한 경우 마스터가 다른 브랜치를 따라잡는게 아니므로 빨리 감기 병합을 할 수 없다.

 

이런 경우 bugfix 브랜치에는 없는 새로운 정보들이 있고, bugfix가 갖고 있는 정보들은 마스터에 없다.

현재 예제는 병합시 충돌하지 않을 경우를 가정한다.

 

 

빨리 감기 병합이 아니라면 - 병합 커밋이라는 것이 생성되는데 기본적으로 깃은 병합의 기준이 되는 브랜치에 커밋을 생성한다. 새 커밋을 만들고 커밋 메세지를 포함하라는 메세지를 표시한다.

 

또 주의할 점은 병합 커밋은 두 개의 다른 부모 커밋을 갖는다. 따라서 병합 커밋은 둘뿐만 아니라 다수의 부모 커밋을 가질 수 있다.

이렇게 두 개의 브랜치를 병합했을 때 커밋 메세지가 뜨면서 편집 가능하다.

 

 

 

병합 중 충돌 발생

깃은 자동적으로 병합하는 방법을 알지 못해서 어떤 것을 유지하고 어떤 것을 제거해야 하는지 결정하지 못한다.

그래서 병합 충돌이 발생한다.

 

git merge를 실행할 때 충돌이 생기면 이런 메세지가 뜨면서 특정 파일에서 충돌이 발생하여 자동 병합은 실패했고 충돌을 해결한 다음에 결과를 커밋하라고 나온다.

Merge 시 충돌

 

 

 

충돌이 발생한 파일의 HEAD 부분에 이상한 표시와 브랜치 이름을 볼 수 있다.

 

현재 내가 있는 HEAD가 가리키는 브랜치에서 가져올 컨텐츠이고 병합해서 넣으려는 기준 브랜치이며 작은 화살촉 ==== 사인으로 표시된다

 

<<<<<<<<HEAD

I have 2 cats

I also have chickens ⬅️여기가 병합해서 넣으려는 기준 브랜치

============

I used to have a dog :( ⬅️  여기가 bugfix 브랜치에서 온 것으로 병합해서 넣으려는 내 브랜치

>>>>>>>bug-fix

 

 

 

간단히 단계별로 정리하자면

1. 충돌이 발생하면 깃은 충돌이 생긴 파일을 알려준다.

2. 그 파일을 열어서 편집하여 충돌 부분을 해결한다. 

3. 변경사항을 등록하고 커밋해서 완료한다.

 

 

 

 

 

병합 중 충돌 발생

마스터 브랜치에서 playlist.txt를 만들고 popsong과 trendy 두 브랜치를 생성하였다.

=>> playlist.txt
this is new playlist

 

각각의 브랜치로 이동하여 같은 playlist.txt 파일에서 서로 다른 내용을 추가하였다.

 

popsong 브랜치

this is new playlist


add popsong
faded
fall
blabla etc....

 

trendy 브랜치

this is new playlist

add trendy songs
aa
bb
cc

 

동일한 파일에 대해 각각의 브랜치에서 내용을 추가하고 스테이지에 올리고 커밋을 해주었다.

그런 다음 trendy 브랜치에서 popsong 브랜치와 병합을 하려 했더니 아래와 같은 에러가 발생한다. 충돌이 발생했으니 수정해달라는 경고이다.

 

그럼 trendy 브랜치의 playlist.txt 파일을 들어가보면

 

humandeep@DESKTOP-FSOD2IH MINGW64 ~/Downloads/git_study/test (trendy|MERGING)
$ vim playlist.txt
--------------------------
this is new playlist

<<<<<<< HEAD
add trendy songs
aa
bb
cc
=======
add popsong
faded
fall
blabla etc....
>>>>>>> popsong

 

이렇게 저번 강의에서 보여준 형태를 띄고 있다.

 

HEAD가 가리키는 부분이 현재 브랜치 위치의 내용이고 아래가 popsong 브랜치의 내용이다.

 

this is new playlist

add trendy songs
aa
bb
cc


add popsong
faded
fall
blabla etc....

 

해당 내용을 이렇게 수정하였다.

수정하려면 <<<<HEAD, ======, >>>>>popsong 과 같은 부분들을 삭제하고 내가 원하는 형태로 수정하고 저장하면 된다.

 

lee@DESKTOP-FSOD2IH MINGW64 ~/Downloads/git_study/test (trendy|MERGING)
$ git status
On branch trendy
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   playlist.txt

no changes added to commit (use "git add" and/or "git commit -a")
(base)

 

그런다음에 git status를 통해 상태를 확인해보면

On branch trendy  : 현재 trendy 브랜치에 있고

fix conflicts and run "git commit"  : 충돌 상황이 있으며 playlist.txt 파일이 수정되었다고 메세지를 출력한다.

 

 

깃 시각화

lee@DESKTOP-FSOD2IH MINGW64 ~/Downloads/git_study/test (trendy)
$ git log --graph --all --oneline
*   31fed02 (HEAD -> trendy) resolve conflicts
|\
| * 4ed90cd (popsong) add popsong
* | 22d73f2 add trendy songs
|/
* e336985 (master) add new playlist

 

git log --graph --all --oneline 해당 명령어를 통해 터미널 창에서 커밋과 브랫치 그래프를 볼 수 있으나 가독성이 영 좋지 않다. 

그래서 VS Code에서 Git Graph를 이용하였다.

깃 그래프에 대한 자세한 내용은 아래 글들을 보면 좋을 것 같다

• https://thinkingtool.tistory.com/entry/VSCODE-%EC%97%90%EC%84%9C-git-branch-%EA%B7%B8%EB%9E%98%ED%94%84%EB%A1%9C-%EB%B3%B4%EA%B8%B0
• https://jhyeok.com/vscode-git-graph/

 

해당 레포 폴더로 VS Code를 열고 맨 왼쪽 칸 중 Source Control 에 들어간다음 옆의 아이콘을 누르면 아래처럼 각 브랜치의 분기와 커밋 로그들을 확인할 수 있다. 꼭 깃크라켄을 쓸 필요는 없는 것 같다.

 

 

VS Code 사용해 충돌 해결하기

git checkout -b <branch-name> : 브랜치를 새로 생성하여 해당 브랜치로 이동하는 명령어

VSCode를 사용해 충돌 상황을 해결하고자 임의로 merge시 충돌을 일으켰다.

master브랜치에서 새로운 브랜치, silence를 생성한 뒤에 동일한 파일에 대해 서로 다른 작업을 수행한 다음 master 브랜치에서 silence 브랜치를 병합시켰다.

 

 

충돌발생. 해당 레포에서 VSCode를 열어보면

 

 

충돌이 발생한 파일에서 충돌 내용에 대해 설명을 해준다.

이때 위의 Accept Curent Change / Accept Incoming Change / Accept Both Changes / Compare Changes 버튼을 눌러서 충돌 상황을 수정할 수 있고 또는 원하는대로 새로 수정하는 것도 가능하다.

해당 내용을 수정한뒤에는 다시 add, commit을 거쳐 커밋을 한다음 병합하면 정상적으로 master 브랜치에 병합된다.

 

 

만약 충돌이 발생한 파일을 수정만 하고 스테이지에 안올리고 커밋을 안하면 다음과 같은 에러가 발생하니까 주의할 것.