지난 시간에 이어서
'깃&깃허브 입문' 3장을 요약 및 실습하겠습니다.
03-1 브랜치 개념
깃으로 버전 관리 시작하면 master '브랜치'가 만들어집니다. 사용자가 커밋할 때마다 master 브랜치는 최신 커밋을 가리킵니다. 즉, 브랜치는 커밋을 가리키는 포인터와 비슷하다고 생각하면 됩니다.
분기(branch)한다 : master 브랜치에서 뻗어 나오는 새 브랜치
병합(merge)한다 : 분기했던 브랜치를 master 브랜치에서 합치는 것
branch , merge 의 이미지를 보고 '협업'에 탁월할 거 같다라는 느낌이 받으셨나요?
(아래는 참고한 사이트에서 가져온 설명입니다)
"""
여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 메인 브랜치에서 자신의 작업 전용 브랜치를 만듭니다. 그리고 각자 작업을 진행한 후, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용합니다. 이렇게 함으로써 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하고 그 결과를 하나로 모아 나가게 됩니다. 이러한 방식으로 작업할 경우 '작업 단위', 즉 브랜치로 그 작업의 기록을 중간 중간에 남기게 되므로 문제가 발생했을 경우 원인이 되는 작업을 찾아내거나 그에 따른 대책을 세우기 쉬워집니다.
"""
03-2 브랜치 만들기
-실습 환경 세팅-
work.txt 파일에 'content 1' 입력 후 저장 및 종료 -> 스테이징 ->커밋 하고 난 뒤에,
content 2 라는 입력 추가. 커밋. 3번하고 git log 로 commit 기록 살펴봅니다.
(위 캡쳐본 보면 무슨 말인지 알 거라고 생각합니다)
#새 브랜치 만들기
$ git branch : 깃에서 브랜치를 만들거나 확인하는 명령어
명령어를 통해 브랜치를 생성하고 확인합니다.
mater 앞에 *(애스터리스크) 표시는 아직 우리가 master 브랜치에서 작업하고 있다는 의미
#브랜치 사이 이동하기 - git checkout
$ git log --oneline
: git log 명령에 한 줄에 한 커밋씩 나타낸다
$ git checkout 브랜치이름
: 현재 브랜치에서 다른 브랜치로 이동 명령어
- 위 캡쳐본에서는 apple 브랜치로 이동한 것을 볼 수 있습니다.
- 이후 HEAD -> apple 을 가리키고 있습니다. apple 브랜치가 최신 커밋이라는 의미입니다.
- master content 4 커밋에는 'content 4'라는 내용까지 입력되어 있지만 apple 브랜치에는 work 3 커밋이 최신이기에 content 3 까지만 출력됩니다.
- apple 브랜치가 master 브랜치에서 분기된 이후에 master 브랜치에 추가된 커밋은 apple 브랜치에 영향을 미치지 않는 것을 확인할 수 있습니다.
03-3 브랜치 정보 확인하기
위 실습을 이어서 계속 진행합니다. (현재 브랜치 - apple)
# 새 브랜치에서 커밋하기
$ git add .
: 마침표(.)를 추가하면 현재 저장소에서 수정된 파일을 한꺼번에 스테이지에 올릴 수 있다.
$ git log --oneline --branches
: 각 브랜치의 커밋을 함께 볼 수 있다.
$ git log --oneline --branches --graph
: 각 브랜치와 커밋의 관계를 좀 더 보기 쉽게 그래프 형태로 표시
- 위 사진에서 결과물을 보면 왼쪽에 수직선이 보입니다. apple 브랜치의 최신 커밋은 'apple content 4'인데, 점선을 따라서 부모를 찾아가 보면 'work 3' 커밋을 만나게 됩니다. 즉, apple 브랜치에서는 'work 3' 커밋 다음에 'apple content 4' 커밋이 만들어졌다는 의미입니다.
- master 브랜치의 최신 커밋은 'master content 4'입니다. 수직선을 따라가 부모 커밋을 보면 'work 3' 커밋입니다.apple 브랜치의 커밋과 master 브랜치의 커밋이 같은 부모 커밋을 가지고 있습니다. 즉, master 브랜치나 apple 브랜치는 'work 3'커밋까지는 같고 그 이후부터는 브랜치마다 다른 커밋을 만들었다는 사실을 알 수 있습니다.
# 브랜치 사이의 차이점 알아보기
$ git log master..apple
:master 브랜치 기준으로 apple 브랜치가 어떤 차이점이 있는 지 보여준다. 즉, apple 브랜치에만 있는 커밋을 확인할 수 있다.
$ git log apple..master
:aplle 브랜치를 기준으로 master 브랜치에만 있는 커밋을 보여준다.
03-4 브랜치 병합하기
master-2 디렉토리를 생성 후 이동합니다. work.txt 에는 1 만 입력 후 저장 종료하고 스테이징, 커밋을 차례대로 합니다. 그 후 o2 브랜치를 생성합니다. master.txt 를 만들고 커밋합니다. 그리고 o2 브랜치로 checkout 하고 o2.txt 파일을 만들고 커밋합니다.
master 브랜치로 checkout 한 뒤, o2를 merge 합니다. o2 브랜치에 있던 o2.txt 파일이 master 브랜치에 합쳐졌습니다.
# 서로 다른 파일 병합하기
$ git init 디렉토리명
: 새 디렉터리 생성과 저장소 초기화를 한꺼번에 초기화한다.
$ git merge 브랜치명
:(master 브랜치로 checkout 상태에서) o2 브랜치를 가져와 병합
$ git merge o2 --no-edit
:브랜치를 병합할 때 자동으로 편집기가 실행된다. 이 때 --no-edit 옵션을 추가하면,
편집기 창을 열지 않고 깃에서 지정하는 커밋 메시지를 그대로 사용하겠다는 의미이다.
# 같은 문서의 다른 위치를 수정했을 때 병합하기
홈에서 manual-3 디렉토리를 생성 후 work.txt 파일을 만들고 커밋합니다. (chekcout - master 브랜치)branch o2를 생성하고 work.txt 파일을 수정합니다. (chekcout - o2 브랜치) work.txt 파일을 수정 후 커밋합니다. master 브랜치로 checkout 하고 o2 브랜치를 merge 시킵니다.
cat 을 통해서 파일이 잘 합쳐진 것을 확인할 수 있습니다.
# 같은 문서의 같은 위치를 수정했을 때 병합하기
바로 전에서 한 거와 유사하게 작업을 해줍니다. 합칠 파일들이 같은 줄에 내용이 있어야 합니다. 바로 위에서는 서로 다른 줄에 내용이 써졌있었습니다. (따로 그 부분은 캡쳐는 안했습니다) 여기서는 합치려고 하는 파일들이 같은 줄에 입력된 내용들이 있어서 충돌이 일어납니다.
conflict 가 발생했기에 vim 을 통해서 사용자가 직접 충돌 부분을 해결해야 합니다.
해결하고 난 뒤의 work.txt 파일의 내용들입니다. 원래 수정 전에는 '<<<<<<<HEAD' 와 가운데줄'==========' 같은 게 입력되어있습니다. 이러한 부분들을 삭제만 하고 난뒤의 모습이 바로 위의 파일입니다.
# 병합이 끝난 브랜치 삭제하기
$git branch -d o2
: o2 브랜치 삭제
03-5 브랜치 관리하기
#브랜치에서 checkout 과 reset 의 작동원리
test 디렉토리를 만든 후 c1.txt 파일을 만들어 '1'을 입력 후 저장합니다.
git log 명령을 실행하면, 커밋 로그 첫 번째 줄에 (HEAD->master) 표시가 있습니다.
여기서, HEAD 는 현재 작업 트리(워킹 디렉터리)가 어떤 버전을 기반으로 작업 중인지를 가리키는 포인터 입니다.
HEAD는 기본적으로 master 브랜치를 가리킵니다. 그리고 브랜치는 기본적으로 브랜치에 담긴 커밋 중에서 가장 최근의 커밋을 가리킵니다. 위에서는 c1 커밋을 만들면 HEAD는 master 브랜치를 가리키고 master 브랜치는 c1 커밋을 가리킵니다.
sub 브랜치를 만들고 c2.txt 를 만들고 커밋한 뒤, sub 브랜치로 checkout 합니다. s1.txt 에 's1' 입력 후 저장합니다. s1.txt 문서를 스테이지에 올리고 's1' 메시지와 함께 커밋합니다.
이제 HEAD는 sub 브랜치를 가리키고 sub는 s1 커밋을 가리키고 있습니다.
c2 커밋의 커밋 해시를 git reset 명령 다음에 입력하면 sub 브랜치의 최신 커밋이 c2로 바뀌었습니다. (그전에는 커밋이 s1이었습니다) 그리고 HEAD는 그대로 sub 브랜치를 가리킵니다. 이렇게 git reset 명령을 사용하면 현재 브랜치가 가리키는 커밋을 여러 브랜치 사이를 넘나들면서 제어할 수 있습니다. sub 브랜치는 c2커밋을 가리키고 있기 때문에 원래 가리키고 있던 s1 커밋은 연결이 끊기면서 삭제됩니다.
#수정 중인 파일 감추기 및 되돌리기 - git stash
커밋하지 않고 작업 중인 파일들을 감추고 되돌리는 실습을 해보겠습니다.
홈 디렉토리에서 st 라는 저장소를 만들고 이동합니다.
git stash 명령을 사용하려면 파일이 tracked 상태여야 합니다. 즉 한 번은 커밋한 상태여야 합니다.
f1.txt 와 f2.txt 를 만들고 각각 커밋합니다. 커밋 후, 두 파일 모두 열어서 내용을 수정합니다. 그 후 git status 명령를 실행하면 둘 다 modified 상태입니다. 이제 f1,f2 파일을 커밋하기 전에 다른 파일을 수정해야 한다고 가정하겠습니다. 커밋하지 않은 수정 내용을 어딘가에 보관하려면 git stash 명령을 사용합니다.
다시 git status 명령을 실행합니다. 조금 전에 나타나던 modified 메시지가 사라졌습니다. working tree clean 이라고 나옵니다. 감춘 파일들을 확인할 때는 git stash list 를 입력합니다.
이제 감춘 파일들을 다시 꺼내보겠습니다. git stash pop 을 입력하면 stash 목록에서 가장 최근 항목을 되돌립니다. 여기에서는 f1.txt 와 f2.txt 가 수정된 상태로 되돌아갑니다.
--------------------------------------------------------------
이상으로 3장 요약 및 실습 포스팅을 마칩니다 :)
--참고--
https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html
https://hoony-gunputer.tistory.com/entry/9-git-branch
'CS+ > 리눅스' 카테고리의 다른 글
리눅스 우분투 기초명령어 4. 명령행 편집, man, passwd, 터미널 종료 (0) | 2020.08.15 |
---|---|
리눅스 conky 설치 (2020.08.15) (0) | 2020.08.15 |
깃&깃허브 입문 2일차 - git init, add, commit, reset, checkout (0) | 2020.03.15 |
(우분투) 깃, 깃허브 입문하기 1일차 (0) | 2020.03.12 |
리눅스(우분투)입문자를 위한 기초 명령어3. I/O redirection , cat (0) | 2020.01.09 |