[14주 3일차] 깃과 브랜치

chapter 03. 깃과 브랜치

 

 

 

03-1. 브랜치란?

 

브랜치는 각각의 코드를 만든 후 정상적인 작동을 할 시 소스 코드를 그대로 둔 채 소스 추가 버전을 따로 만들어 관리하고추가적인 소스 코드 버전을 따로 만들어서 관리하여 추가하고 잘못된 동작을 할 시 삭제도 편하게 할 수 있도록 한다.

 

깃에서는 기본적으로 main이라는 브랜치가 만들어진다.

사용자가 커밋할때마다 main 브랜치는 어떤게 최신 커밋인지 정보를 가진다.

새 브랜치를 만들면 기존 파일은 main 브랜치에 그대로 유지가 되면서 새 브랜치에서 기존 파일 내용을 수정하거나 새로운 기능을 추가할 수 있다.

그리고 이것은 '분기(branch)'라고 한다.

 

새 브랜치에서 우너하는 작업을 모두 끝낸 후 새 브랜치에 있던 파일을 원래 main 브랜치에 합칠 수 있다.

 

이렇게 분기했던 브랜치를 main 브랜치에 합치는 것을 '병합(merge)'한다고 한다.

이 말은 기본 파일은 main 브랜치에 그대로 둔 상태에서 새로운 브랜치를 분기한 후 수정이나 추가 작업을 하고 별 문제 없는지 확인을 한 후 완성되었다면 새 브랜치의 내용을 main 브랜치와 병합하는 것이다.

 

 

 

 

 

 

 

03-2. 브랜치 만들기 및 이동하기

 

 

 

실습 상황 만들기

 

1. manual 이라는 새로운 디렉터리를 만들어 해당 디렉터리로 이동한다.

$ cd desktop/manual
$ git init
$ ls -al

 

디렉터리를 만들어 둔 위치로 이동한 후 git init을 하여 .git디렉터리를 만들고 ls -al로 확인한다.

 

 

2. 이 후 manual 디렉터리 안에 work.txt 파일을 만들어 작성한 후 저장한다.

그리고 스테이징 작업을 한 후 커밋까지 해준다.

마지막으로 잘 커밋되었는지 확인하면 다음과 같이 확인할 수 있다.

 

이때 HEAD -> main 은 HEAD가 현재  main이라는 브랜치를 가리키고 있다는 뜻이며 HEAD가 붙은 커밋이 가장 최근의 커밋이다. 밑의 출력 메세지를 해석하면 work 1 커밋이 가장 최근 커밋이라는 것을 알 수 있다.

 

 

 

 

3. work.txt 를 두번 세번 작성하고 work 2, work 3이라는 이름으로 스테이징과 커밋한다.

 

 

 

 

 

 

---

 

 

 

새 브랜치 만들기

 

초기에 작성한 것과 다른 코드를 작성해야할 경우 복사해서 사용할 시 문제가 발생할 수 있다.

이럴때 브랜치를 사용하면 간단하게 사용할 수 있다.

 

 

1. 깃에서 브랜치를 만들거나 확인할 수 있다.

이때의 명령어는 git branch이다.

$ git branch

 

이때 아래와 같이 main이라고 나타나는데 지금까지 작성했던 곳은 main 브랜치이기 때문이다.

이로써 main이라는 브랜치가 기본적으로 생성되어있다는 것을 확인할 수 있다.

 

 

 

2. 새로운 브랜치를 만들려면 git branch 뒤에 브랜치 명을 작성하면된다.

아래는 apple이라는 이름의 브랜치를 생성한 명령이다.

$ git branch apple

 

git branch를 사용하여 브랜치를 확인하면 apple이라는 이름의 브랜치가 생성된 것을 볼 수 있다.

 

이후로 goole, ms 라는 이름의 브랜치를 만들어준다.

그 후로 잘 생성되었는지 확인하면 아래와 같이 확인할 수 있다.

이때 *main 표기는 *이 현재 작업하는 브랜치를 나타낸다.

 

 

 

 

 

---

 

 

 

새 커밋을 추가하면 어떻게 될까?

 

 

1. main , apple 브랜치를 생성 후 git log 명령어를 사용하여 확인해보았다.

그럼 아래와 같이 확인할 수 있는데

main, apple 브랜치도 최신 커밋이 work 3이라는 뜻이다.

 

 

 

 

 

 

2. 현재 위치하는 브랜치가 main일 경우 혹은 main으로 이동하여 커밋을 생성해보았다.

 

$ git switch main
$ git commit -am "R4"

 

그럼 아래와 같은 결과를 볼 수 있는데

이전과 다르게 ms, google, apple은 work 3이고 main은 R4에 위치한다는 것을 볼 수 있다.

현재 브랜치인 main의 최신 커밋은 R4라는 것과 ms, google, apple의 최신 커밋은 work 3이라는 것을 알 수 있다.

 

 

 

 

 

 

3. 바뀐 로그를 조회할 때 사용하던 명령어는 git log이다.

이때 옵션을 추가하여 확인할 수 있는데 --oneline옵션이다.

--oneline옵션은 한 줄에 한 커밋씩 보여줘 한눈에 확인할 때 편리하다.

 

 

 

 

 

---

 

 

브랜치 전환하기 - git switch

 

위에서 브랜치가 여러개이면 서로 다른 커밋을 만들 수 있다는 것을 확인했다.

그렇다면 브랜치를 옮겨가면서 작업을 할 수 있어야하는데

브랜치를 옮길 때 사용하는 명령어는 git switch이다.

이전 버전에서는 checkout을 사용했다.

(checkout은 restore와 switch 기능을 모두 가지고 있다.)

 

 

 

1. apple 브랜치로 전화을 해보았다.

$ git switch apple

 

git switch를 한 후 아래와 같이 apple 브랜치로 이동한 것을 볼 수 있다.

 

 

 

2. 작업 브랜치를 옮긴 후 로그를 조회했다.

이전과 다른 결과를 볼 수 있었는데 apple의 가장 최신 커밋은 work 3이기 때문에 그 이후의 커밋인 R4는 볼 수 없다.

 

 

3. work.txt 파일은 수정되어있는지 확인을 하기 위해 cat 명령어로 조회해보았다.

그러니 R4의 수정한 내용을 볼 수 없었다.

work 3의 내용까지만 존재한다.

 

 

 

 

---

 

 

03-3. 브랜치 정보 확인하기

 

 

전환한 브랜치에서 커밋하기

 

이전 내용에서는 apple 브랜치로 전환을 했다.

그러므로 apple 브랜치에서 새로운 커밋을 만들 수 있다.

 

 

1. apple 브랜치에서 work.txt를 수정한 후 커밋했다.

그후 로그를 조회해보았더니

apple의 최신 커밋은 apple work 4라는 커밋으로 바뀐 것을 볼 수 있었고 

ms, goole의 최신 커밋은 여전히 work 3이라는 것 또한 볼 수 있었다.

 

 

 

 

---

 

 

브랜치와 커밋 관계 알아보기

 

 

브랜치와 커밋이 어떻게 연결되어 있는지 확인할 수 있다.

 

1. git log 명령으로 로그 조회시 --branches 옵션을 추가하면 브랜치마다 최신 커밋이 어떤것인지 확인할 수 있다.

그럼 아래와 같은 결과를 볼 수 있는데

apple은 apple work 4 , main은 R4, ms와 google은 work 3이 가장 최근의 커밋이다.

 

 

 

그리고 여기서 --oneline옵션을 추가하면 한번에 확인할 수 있고

$ git log --oneline --branches

 

여기서 또 추가로 --graph 옵션을 추가하면 그래프 형태로 확인할 수 있어 브랜치과 커밋의 관계를 더 이해하기 쉽게 볼 수 있다.

$ git log --oneline --branches --graph

 

 

아래 그래프의 결과를 보면 work 3까지는 모든 브랜치가 같고 이후부터 브랜치마다 다른 커밋을 만들었다는 것을 확인할 수 있다.

 

 

 

 

---

 

 

브랜치 사이의 차이점 살펴보기

 

git log 명령에서 브랜치 이름 사이에 마침표 2개(..)를 넣는 명령으로 브랜치 간의 차이를 쉽게 확인할 수 있다.

 

$ git log main..aple

 

위와 같이 작성하면 main 브랜치에 없고 apple 브랜치에만 존재하는 커밋을 보여준다.

 

 

$ git log apple..main

 

이전과 다르게 apple..main과 같이 작성을 하면 apple에는 없고 main에만 존재하는 R4라는 커밋을 보여준다.

이렇게 ..앞에는 비교하는 대상의  브랜치 .. 뒤에는 기준이되는 브랜치가 작성된다.

 

 

 

 

 

 

---

 

 

 

 

03-4. 브랜치 병합하기

 

브랜치 병합(merge)는 상황에 따라 작성한 작업을 기존의 브랜치와 합쳐야하는 경우가 발생한다. 이때 브랜치를 병합 즉 합치는 것을 말한다.

 

 

 

서로 다른 파일 병합하기

 

1. desktop에서 manual-2라는 디렉터리를 만든다.

그 후 git init하여 저장소를 만들고 work.txt를 스테이징한 후 work 1이라는 이름으로 커밋하여 주었다.

 

주의할 점

** 만약 desktop에서 init할 경우에는 git init manual-2로 해야됨 desktop의 누구를 init해라
만약 manual-2에서 init할 경우 git init만 하면 됨 이미 manual-2안에 있기 때문에 

$ git init

$ git add work.txt

$ git commit -m "work 1"

 

 

2. 위와 같은 방법으로 o2 브랜치를 만들었다.

$ git branch o2
$ git add main.txt

 

 

 

3. main에서 main work 2라는 커밋을 만들어주었다.

$ git commit -m "main work 2"

 

 

 

4. o2 브랜치로 전환해주었다.

$ git switch o2

 

 

 

5. o2 브랜치에서 o2.txt라는 파일을 만든 후 저장하고 o2 work 2 라는 이름으로 커밋했다.

$ git add o2.txt

$ git commit -m "o2 work 2"

 

 

6. 현재 커밋의 상태를 확인하기 위해 gti log --oneline --branches --graph 명령어를 사용하여 확인해보았다.

그래프를 확인하면 work 1까지는 같이 가지고 있지만 main 브랜치에는 main work2 커밋, o2에는 o2 work 2라는 커밋이 생긴 것을 알 수 있다.

 

 

 

 

7. o2 브랜치의 작업이 모두 끝난 후 o2의 내용을 main 브랜치와 병합해야한다.

그럴려면 main 브랜치로 전환을 해야만 한다.

병합하는 명령어는 gti merge 병합할 브랜치명

$ git switch main

$ git merge o2

 

주의할 점

** main에서 병합해야한다.

o2에서 하면 main이 o2에 흡수되어 main의 코드가 없어짐

(반대로 하면 o2의 코드가 main에게 흡수되어 o2의 코드가 없어진다.)

 

 

 

8. 로그를 확인하기 위해 gti log --oneline --branches --graph 명령어를 사용하여 확인해보았다.

그럼 아래와 같은 그래프를 확인할 수 있는데 

그래프를 확인하면 work 1까지는 같이 가지고 있지만 이후부터 각 각 다른 커밋을 가지고 있는 것을 볼 수있었다.

병합을 하여 두개의 브랜치가 합쳐 진 것을 볼 수 있다.

 

 

 

 

 

---

 

 

 

서로 다른 브랜치에서 한 문서의 다른 부분을 수정했을 때 병합하기

 

 

2개의 브랜치에서 같은 문서를 수정하는 경우도 존재할 수 있다.

이럴 경우 앞에서 본 경우와 다르게 병합을 해야한다.

 

 

 

1. manual-3이라는 디렉터리를 만들고 깃 저장소를 만들어 이동한다.

이 후 work.txt 문서를 수정한 후 스테이징 한 뒤 work 1으로 커밋한다.

 

$ cd ..

$ cd manual-3

$ git add work.txt

$ git commit -m "work 1"

 

 

2. o2 라는 새로운 브랜치를 만들어 준다.

그럼 o2와 main은 work 1 이라는 커밋이 있게 된다.

$ git branch o2

 

 

 

3. 양 쪽 브랜치 모두 work.txt가 존재하게 한 뒤 main 브랜치에서 문서를 수정하여 main work2로 커밋한다.

$ git commit -am "main work 2"

 

 

4. o2 브랜치로 스위치하여 work.txt를 수정한 뒤 o2 content 2라는 이름으로 커밋한다.

 

$ git switch o2
$ git commit -am "o2 work 2

 

 

 

5. main 브랜치와 o2 브랜치 양쪽에서 work.txt를 수정한 후 병합해보았다.

main 브랜치에 o2를 합칠 것이기 때문에 main으로 이동한 후 병합한다.

$ git switch main
$ git merge o2

 

 

6. 이후 work.txt 파일을 확인하기 위해 cat 명령어를 사용해 확인했다.

그럼 아래와 같이 확인할 수 있는데

o2의 내용과 main의 내용이 자연스럽게 하나의 파일에 합쳐진것을 볼 수 있다.

이전과 다르게 같은 문서로 다른 위치를 수정했을 경우 자연스럽게 합쳐준다.

 

 

 

 

 

---

 

 

서로 다른 브랜치에서 한 문서의 같은 부분을 수정했을 때 병합하기

 

깃에서는 줄 단위로 변경 여부를 확인하는데 서로 다른 브랜치에서 같은 문서의 같은 줄을 수정했을 경우, 브랜치를 병합하면 브랜치 충돌이 발생한다. 이럴경우를 대비하여 서로 다른 브랜치에서 한 문서의 같은 부분을 수정했을 때 병합하는 방법을 알아보자.

 

 

 

1. 홈 디렉토리로 다시 이동한 후 manual-4라는 이름의 깃 저장소를 만들어 이동한다.

$ cd manual-4
$ git init

 

 

2. work.txt 파일을 작성하고 스테이징한 후 work 1로 커밋한다.

$ git add work.txt

$ git commit -m "work 1"

 

 

 

 

3. o2라는 브랜치를 만든 후 work.txt를 생성한다.

$ git branch o2

 

 

 

4. main 브랜치에서 work.txt를 수정하고 main work 2로 커밋한다.

git commit -am "main work 2"

 

 

 

 

5. o2 브랜치의 wokr.txt 파일도 수정한다.

이전에 o2 브랜치로 전환하여 수정해야한다.

$ git switch o2
git commit -am "o2 work 2"

 

 

 

 

6. main 브랜치와 o2 브랜치 양쪽에서 work.txt 파일을 수정했는데 문서 안의 수정 위치가 같다. (텍스트 파일에서 수정한 곳이 같다는 뜻)

이럴경우 병합하면 어떻게 될지 확인해보기 위해 o2 브랜치를 main 브랜치에 병합한다.

(main 브랜치로 전환 후 git merge 해야함)

git switch main
git merge o2

 

 

 

 

7. git merge o2할 경우 아래와 같이 경고 메시지가 나타난다.

이것의 뜻은 work.txt를 자동 병합하는 동안 충돌이 발생했다는 의미이다.

 

 

 

 

 

8.  충돌이 생긴 문서는 자동으로 병합될 수 없기 떄문에 사용자가 충돌 부분을 직접 해결한 후 커밋해야만 한다.

그 전에 충돌이 생긴 work.txt 는 어떻게 되었는지 확인을 해보았다.

그럼 아래와 같이 <<<<<<HEAD =======이  나타난 것을 볼 수 있는데 HEAD와 ==== 사이의 내용은 현재 브랜치, main 브랜치에서 수정한 내용이고 ====와 >>>o2사이의 내용은 o2 브랜치에서 수정한 내용이다.

 

 

 

 

9. <<<HEAD나 >>>>>>o2 가로줄(====)을 삭제한다. 그리고 수정한 work.txt를 스테이징하고 커밋하는데 이떄 커밋은 merge o2 branch 이다.

 

$ git commit -am "merge o2 branch"

 

 

 

 

 

10. git log 명령을 사용해 지금까지 만든 브랜치와 커밋의 관계를 확인한다.

$ git log --oneline --branches --graph

 

제대로 병합된 것을 볼 수 있다.

 

 

 

 

---

 

 

 

병합이 끝난 브랜치 삭제하기

 

브랜치를 병합한 후 더 이상 사용하지 않는 브랜치는 깃에서 삭제할 수 있다.

삭제하더라도 완전히 지워지는 것은 아니고 같은 이름의 브랜치를 만들면 예전 내용을 다시 볼 수 있다.

 

 

브랜치를 삭제 할 떄는 main 브랜치로 이동하여 git branch 명령에 -d 옵션과 그 뒤 삭제할 브랜치 이름을 작성하여 삭제한다.

$ git switch main
$ git branch -d o2

 

 

 

 

 

 

 

---

 

 

 

 

 

cherry-pick 으로 병합하기

 

병합하는 방법 중 cherry-pick이라는 방법이 있다.

기존의 병합에서는 mt3 버전이 두개의 브랜치를 합쳤기 때문에 main 브랜치의 모든 변경사항과 topic 브랜치의 모든 변경 사항을 함꼐 포함한다.

 

하지만 cherry-pick 의 경우에는 브랜치 전체를 합치는 것이 아닌 topic 브랜치 중 특정 버전의 변경 내용만 합치려고 할 때 사용하는 기능이다.

 

예를 들어 topic 브랜치의 t1 버전에서 변경된 것만 main 브랜치에 합칠 수 있다.

이럴 경우 새로운 버전은 만들어지지 않고 main 브랜치에 t1 버전이 합쳐진다. 이것을 부분병합이라고 한다.

topic 브랜치에 있는 다른 버전들은 합쳐지지 않는다.

main 브랜치에 topic 브랜치를 merger했을 때

 

(A+B+C+m1+m2)+(A+B+C+t1+t2)=mt3

 

 

main 브랜치에서 topic 브랜치를 cherry-pick 했을 때

 

 

 

 

1. 홈 디렉터리에 cherry-pick 디렉터리를 만들고 이동하여 저장소를 만든다.

$ cd cherr-pick

$ git init

 

 

 

2. 그후 버전을 만들어 준다. 

아래의 명령과 같이 입력하면 되는데 touch init.txt는 init.txt 파일을 만들고 git add init.txt;는 init.txt 파일을 스테이징한다. 그리고 git comit -m "init"은 init 메시지와 함께 커밋한다는 뜻이다.

원래는 따로 명령했지만 같이 명령을 할 수도 있다.

$ touch init.txt; git add init.txt; git commit -m "init"

 

 

 

3. 모두 생성한 후 topic 브랜치를 만들고 깃로그를 확인한다.

$ git branch topic

$ git log --oneline --all --graph

 

 

 

 

4.  main 브랜치에 m1과 m2라는 2개의 버전을 만들고 git log로 확인하면 main 브랜치는 최신버전 m2를 가르키고 있고 topic 브랜치에는 init 버전 상태인것을 볼 수 있다.

$ touch m1; git add m1; git commit -m "m1"
$ touch m2; git add m2; git commit -m "m2"

 

 

 

 

5. topic으로 전환한 후 t1, t2, t3을 만든다.

$ touch t1; git add t1; git commit -m "t1"
$ touch t2; git add t2; git commit -m "t2"
$ touch t3; git add t3; git commit -m "t3"

 

 

 

6. 모두 생성한 후 상태를 확인한다.

그럼 그래프를 확인할 수 있는데 main 브랜치는 init 버전부터 시작해 m1,m2 버전으로 연결되어 있고 topic 브랜치 버전부터 시작해 t1,t2,3 버전으로 연결된다.

 

 

 

 

7. 현재 2개의 브랜치가 있는데 topic 브랜치의 t2버전에서 적용했던 내용을 main 브랜치에도 적용하고 싶을 때 cherry-pick을 사용한다.

topic 브랜치의 여러버전 중 하나를 골라서 병합한다.

병합하기 전 main브랜치로 이동하여 topic 브랜치의 t2 버전만 병합한다.

$ git switch main

$ git cherry-pick 체리픽할 해시

 

cherry-pick 명령 뒤에 체리픽할 해시를 작성하면 병합이 끝난다.

 

체리픽할 해시는 git log했을때 볼 수 있는 숫자다.

(예) 그래프일 경우 * 나 | 뒤에 오는 숫자 영어 합쳐진 것)

마지막으로 ls하면 t2가 합쳐진 것을 볼 수 있다.