깃&깃허브 스터디 (2주차)

<깃에서 브랜치란>

- 깃을 시작하면 기본적으로 main이라는 브랜치 생성

-사용자가 커밋할 때마다 main 브랜치는 어떤 것이 최신 커밋인지에 대한 정보를 가짐 >> 커밋을 가리키는 포인터

-새 브랜치(분기(branch)한다)를 만들면 기존 파일은 main 브랜치에 그대로 유지하면서, 새 브랜치에서 기존 파일 내용을 수정하거나 새로운 기능을 추가

-새 브랜치에서의 작업이 끝난 후 분기했던 브랜치를 main 브랜치에 합치는 것 >> 병합(merge)한다

-기본 파일은 main 브랜치에 그대로 둔 상태에서 새로운 브랜치를 분기한 후 수정이나 추가 작업을 하고 완성하면, 새 브랜치의 내용을 main 브랜치와 병합하는 것

 

<브랜치 만들기 및 이동하기>

터미널 창을 열어 홈 디렉터리에 새 디렉터리 'manual' 생성, 해당 디렉터리로 이동

manual 디렉터리를 저장소로 만들고, ls -al 명령을 사용해서 .git 디렉터리가 만들어졌는지 확인 (위에 파란색 .git이 있으면 성공!)

manual 디렉터리 안에 work.txt파일을 만들고, 텍스트 파일에 'content 1'이라는 내용 추가 후 저장

work.txt를 스테이지에 올리고 커밋, 커밋 메세지는 "work 1"으로 해줌

git log을 입력하여 커밋 내역 확인

>> HEAD -> main은 HEAD가 현재 main이라는 브랜치를 가리키고 있다는 뜻, HEAD -> main이 붙어있는 커밋이 가장 최신 커밋임 (현재 work 1이라는 커밋이 최신 커밋이라는 것을 알려줌)

work.txt에 content1, 2, 3, 입력하고 수정, 초기 사용 설명서 만들고 커밋까지 완료

.git log를 입력하여 커밋 로그를 다시 확인. 3개의 커밋 만들어짐, 가장 최신 커밋인 work3에 (HEAD -> main) 표시

 

<새 브랜치 만들기>

$ git branch >> 브랜치를 만들거나 확인하는 명령 (저장소를 만들면 main 브랜치가 기본으로 생성, 그동안 main 브랜치에서 작업하고 있었다는 사실 확인 가능)

$ git branch apple >> 새로운 브랜치 만들기 (git branch 명령 다음에 브랜치 이름 적기), 브랜치 생성 여부를 확인하기 위해 다시 $ git branch를 써주면 main 브랜치 위에 apple 브랜치가 추가된 것 확인 가능(현재 작업 공간은 main 브랜치 위)

브랜치가 추가된 후 $ git log 명령으로 커밋 로그를 확인하면 (HEAD -> main) 표시가 (HEAD -> main, apple)로 바뀌어있음을 확인 가능. 저장소에 main과 apple이라는 2개의 브랜치가 있고, HEAD -> main이므로 현재 작업 위치는 main임을 알 수 있음

 

 

앞의 방법과 동일하게 적용하여 google 브랜치와 ms 브랜치 생성, $ git branch 명령으로 저장소 안에 있는 모든 브랜치 확인 가능 (현재 작업 중인 곳은 main)

 

main 브랜치에 새로운 커밋 추가, $ git lof --online 명령어(--online : 한 줄에 한 커밋씩 보여줌, 여러 커밋을 한눈에 확인)

(위 과정에서 실수로 깃 배시를 초기화시켰는데, 그 과정때문에 여기서 책 출력화면이랑 내 출력화면이 다르게 나타났다..)

원래는 최신 커밋인 main work 4가 main 브랜치에만 적용되어 있고, ms google apple 브랜치는 아직 work3 커밋 상태이어야 함. 새로 만든 커밋은 현재 브랜치(main)에만 적용, 나머지 브랜치에는 적용X

>> 브랜치별로 커밋 따로 관리 가능!

$ git switch 명령 >> 현재 브랜치에서 다른 브랜치로 이동, 브랜치마다 오가면서 작업 가능

브랜치를 스위치함에 따라 ~/manual 옆에 (apple) 문구 표시 >> 현재 apple 브랜치에서 작업하고 있다는 뜻

git log --oneline 명령어를 통해 현재 브랜치의 커밋 로그를 확인하면 HEAD -> apple을 토해 현재 apple에서 작업 중이라는 사실을 확인할 수 있음, apple 브랜치를 생성하기 전까지 main 브랜치에 있던 커밋들은 그대로 apple 브랜치에도 적용

cat 명령을 사용해 work.txt 파일의 내용 확인 >> $ cat work.txt, 최신 커밋이 work3이기 때문에 content 1부터 content 3까지 3개의 행만 존재 >> main 브랜치에서 입력했던 main content 4가 없음, 이는 apple 브랜치를 분기한 후에 main 브랜치에 추가된 커밋이기 때문에 apple 브랜치에 영향을 미치지 않은 것.

 

<브랜치 정보 확인하기>

apple 브랜치에는 브랜치를 분기할 때 가져온 work.txt 파일이 존재 >> 'apple content 4' 텍스트를 추가하고 저장

수정한 word.txt 파일과 새로 만든 apple.txt 파일 2개를 묶어서 한꺼번에 커밋 >> git add . (한 칸 띈 후 마침표) 명령을 통해 현재 저장소에서 수정 내용이 있는 파일을 스테이지에 한꺼번에 올리기 가능, 'apple work 4' 메시지와 함께 커밋

git log 명령을 사용하여 커밋이 어떻게 저장되었는지 확인, HEAD -> apple을 통해 현재 apple 브랜치로 전환한 상태이고, apple 브랜치의 최신 커밋이 apple work라는 사실 확인 가능

--branches 옵션 추가 >> 브랜치마다 최신 커밋을 한눈에 확인 가능, main 브랜치에는 없고 apple 브랜치에만 있는 커밋만 보여줌

(HEAD -> apple), (main), (ms, google) >> 해당 커밋이 어떤 브랜치에서 만든 것인지 구별 가능

(HEAD -> apple)이라고 되어 있으니 현재 브랜치는 apple 브랜치고, 최신 커밋은 apple work 4이며 ms, google 브랜치의 최신 커밋은 work3임

 

<브랜치 병합하기>

1. git init 다음에 디렉터리 이름을 입력하면 새로운 디렉터리를 만들고 저장소를 초기화하는 과정을 한꺼번에 처리 가능

2. ls -al 명령을 사용하여 .git/ 디렉터리가 실제로 생성되었는지 확인

3. 빔에서 work.txt 파일 생성, 'work1' 이라는 메시지와 함께 커밋

4. o2라는 브랜치 생성(main 브랜치에 있는 상태, o2는 work1 커밋을 가리킴)

5. main브랜치에 main.txt 파일을 하나 더 생성 >> 'main work 2'라는 메시지와 함께 커밋

6. main브랜치에서 work1커밋과 main work2 커밋 생성 >> git switch 명령을 통해 o2 브랜치로 전환

7. o2 브랜치에서 o2.txt 파일 생성 >> 'o2 work 2'라는 메시지와 함께 커밋

8. git log 명령으로 현재 커밋의 상태 확인하면, work 1 커밋은 main 브랜치와 o2 브랜치가 똑같이 가지고 있음

    main 브랜치에는 main work 2 커밋이 생겼고 o2 브랜치에는 o2 work 2 커밋이 생김

    main 브랜치 입장에서 main work 1 -> main work 2 순으로 커밋 생성,

    o2 브랜치 입장에서 main work 1 >> o2 work 2 순으로 커밋이 생김

9. o2 브랜치의 내용을 main 브랜치에 병합하기 위해 우선적으로 main 브랜치로 전환

10. 'git merge + 가져올 브랜치 이름' >> 브랜치 병합 (여기서는 main 브랜치를 기준으로 o2 브랜치를 가져와 병합)

11. 빔이 자동으로 실행되면서 'Merge branch o2'라는 커밋 메시지 나타남 >> 브랜치 병합으로 인해 생성된 커밋 메시지

12. ls -al 명령 >> o2 브랜치에 있던 o2.txt 파일이 main 브랜치에 합쳐졌을 것으로 예상 가능

13. git log 명령 >> 브랜치와 커밋이 어떻게 병합되었는지 확인 가능

 

<서로 다른 브랜치에서 한 문서의 다른 부분 수정 후 병합하기>

1. main 브랜치에서 work.txt 생성, 커밋 메시지 'work 1'로 설정 후 커밋

2. o2라는 새로운 브랜치 생성 (main 브랜치와 o2 브랜치에 모두 work 1 커밋 존재)

3. 양쪽 브랜치 모두 work.txt가 있는 상태에서 우선 main 브랜치에서 문서 수정 및 커밋 (커밋 메시지 : main work 2)

4. o2 브랜치의 work.txt 파일 수정 및 커밋 (커밋 메시지 : o2 work2)

5. main 브랜치와 o2 브랜치 양쪽에서 work.txt 파일 수정 >> 문서 안의 수정 위치는 다름, 이 상태에서 병합하기 위해 o2 브랜치를 main 브랜치로 전환 (git switch 명령, git merge 명령 사용) >> 빔이 자동으로 실행, 커밋 메시지 나타남, 병합 완료

6. 터미널 창에 Auto-merging work.txt로 시작하는 병합 완료 메시지가 나타남, cat 명령을 사용하여 work.txt 파일을 확인하면 main 브랜치의 수정 내용과 o2 브랜치의 수정 내용이 자연스럽게 하나의 파일에 합쳐진 것을 볼 수 있음

 

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

1. main 브랜치에서 word.txt파일 생성, 스테이지에 올리고 커밋 (커밋 메시지는 'work 1')

2. o2 브랜치 생성, main 브랜치의 최신 커밋 가져옴 >> 브랜치 양쪽에 work.txt 존재하게 됨

3. 먼저 main 브랜치에서 work.txt 수정 후 커밋 (커밋 메시지는 'main work 2')

4. 그 후에 o2 브랜치의 work.txt 수정 후 커밋 (커밋 메시지는 'o2 work 2')

5. main 브랜치와 o2 브랜치 양쪽에서 work.txt 파일을 수정했는데 문서 안의 수정 위치가 같음 >> o2 브랜치를 main 브랜치에 병합하기 위해 먼저 main 브랜치로 전환 후, git.merge 명령을 사용하여 o2 브랜치를 병합

6. git merge 명령을 실행했을 때 경고 메시지 등장 >> 충돌 발생, 충돌이 생긴 문서는 자동 병합이 불가. 따라서 사용자가 충돌 부분을 직접 해결한 후 커밋해야 함

7. 빔에서 work.txt를 열어보면 main 브랜치에서 수정한 내용, o2 브랜치에서 수정한 내용이 모두 나옴. 양쪽 브랜치의 내용을 참고하며 직접 수정해야 함

8. work.txt 수정 후 스테이지에 올리고 커밋 (커밋 메시지는 'merge o2 branch') >> 충돌 해결, 커밋 완료. git log를 활용하여 지금까지 만든 브랜치와 커밋의 관계를 한눈에 확인 가능

 

<병합이 끝난 브랜치 삭제>

1. git branch 명령으로 현재 저장소에 있는 브랜치 확인 가능 (현재는 main브랜치이므로 main 브랜치 앞에 * 표시)

2. 저장소의 기본 브랜치는 main >> 브랜치를 삭제하려면 main 브랜치에서 진행해야 함

3. git branch 명령 뒤에 -d(delete라는 의미, -D를 사용하면 병합하지 않은 브랜치도 강제로 삭제 가능)옵션 추가, 그 뒤에       삭제할 브랜치 이름 사용하면 해당 브랜치 삭제됨

4. Deleted branch o2처럼 메시지가 등장하면 브랜치 삭제에 성공한 것. 브랜치를 삭제하는 것은 저장소에서 전체를 완전히 지우는 것이 아니라 깃의 흐름 속에서 감추는 것!

 

<cherry-pick으로 병합하기>

브랜치 전체를 합치는 것이 아니라, 한 브랜치 중 특정 버전의 변경 내용만 합치려고 할 때 사용하는 기능 (다른 버전들은 합쳐지지 않음)

1. cherry-pick 디렉터리를 깃 저장소로 만들고, cherry-pick 디렉터리로 이동

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

    >>init.txt파일 생성, init.txt파일 스테이징, init 메시지와 함께 커밋 (현재 버전이 필요하기 때문에 새로운 빈 파일 생성)

3. 새로운 브랜치 topic 생성, git log를 통해 보면 init이라는 버전이 main과 topic 브랜치 양쪽에 있는 것 확인 가능. --all 옵션은 최신 커밋 뿐만 아니라 모든 커밋을 다 보여주기 위한 옵션

4. main 브랜치에 m1과 m2라는 2개의 버전을 더 만들어주기 >> git log로 확인하면 main 브랜치는 최신 버전 m2를 가리키고 있고, topic 브랜치에는 init 버전 상태인 것 확인 가능

5. topic 브랜치로 전환 후, 같은 방법으로 t1, t2, t3 버전 만들기 >> git log로 확인하면 main 브랜치는 init 버전부터 m1, m2 버전으로 연결, topic 브랜치는 init 버전부터 t1, t2, t3 버전으로 연결

6. main과 topic 2개의 브랜치 >> topic 브랜치의 t2 버전에서 적용했던 내용을 main 브랜치에도 적용하기 위해 cherry-pick 사용 >> 병합될 브랜치인 main 브랜치로 전환

7. topic 브랜치의 t2 버전만 병합하려면, cherry-pick 명령 다음에 t2에 해당하는 커밋 해시를 알려주면, 기존에 main 브랜치에 있던 init.txt, m1, m2 다음에 t2가 합쳐진 것 확인 가능 (ls 명령을 통해 확인 가능)

8. 마지막으로 git log를 통해 확인하면 topic 브랜치에 t2가 있고, main 브랜치에도 t2가 추가되어있음을 확인 가능

 

출처 :  Do it! 지옥에서 온 문서 관리자 깃&깃허브 입문 (이고잉 지음)

http://www.yes24.com/Product/Goods/113791485