💥 저세상 깃터디 2일차 (1)

Index

1. .gitignore 파일은 뭔가요?
2. amend, squash : 커밋 갖고 놀기
3. stash : working tree를 잠깐만 저장
4. branch와 checkout
5. branch 병합 1: merge
   1) 3-way merging
   2) merge conflict?
6. branch 병합 2: rebase
7. branch-전략
8. commit의 적정 단위와 협업, 메시지

이번 2일 차 복습은 글 두 개로 나눠서 쓸건데
이 글에서는 5-1까지만 다룬다!

---

1. .gitignore 파일은 뭔가요?

깃이 관리하지 않았으면 하는 파일들을 저장해두는 파일이다.

자세히 말하자면 git을 사용하면서 원격 저장소에 파일을 올릴 일이 정말 많은데, 깃이 관리하는 파일들은 모두 원격저장소에 올라가기 때문에 만약 공유하고 싶지 않은 파일이 있다면 .gitignore에 미리 저장해야 한다.

나 혼자 local에서 작업을 할 때도 굳이 변경사항을 관리하지 않아도 되는 파일들을 써놓아도 된다.

이런 식으로, .gitignore에 이름을 저장해둔 파일들은 git add를 실행해도 파일들이 tracking 되지 않는다.

#을 사용하면 주석처리된다.

위와 같은 .gitignore 파일을 최상위 디렉토리에 저장해놓고나서, README.txt와 text/README.txt, one.pdf 이렇게 세 개의 파일을 생성하고, node_modules/ 라는 디렉토리도 생성한다.

git status의 결과는 어떻게 될까? 우리가 추가한 파일들이 Tracking 돼야하는 파일로 인식될까, 아닐까?

정답은 No.
status 명령 시 출력되는 untrackted files에 포함되지 않는다.

그럼 자연스럽게 git add 시에도 .gitignore에 포함되는 저 파일들은 Index로 올라가지 않는다는 걸 받아들일 수 있다. 🥰

그런데❗❗ 실수로 파일을 Tracking한(index 영역에 들어간) 후에 .gitignore에 파일명을 추가하면 .gitignore에 의해 필터링되지 않기 때문에 계속해서 Index/local repository에 남아있게 된다.

이럴 때는 git rm -r --cached 명령어를 .gitignore의 위치에서 실행해주면 된다.

로컬에서 커밋 기록까지 지우고 싶다면 git reset을 사용하면 되겠다.

만약 remote repository에 올라가있을 경우에는 reset 후 force push를 하면 된다. (여러가지 방법 중 하나라고 하셨다.) 👉🏻 이거는 협업할 때 비밀키를 잘못올리거나 했을 때의 해결책이 될 수 있을 것 같다.

---

2. amend, squash : 커밋 갖고 놀기

방금 한 커밋을 수정하고 싶어요: amend

amend 옵션은 가장 최근의 commit message/descreption 을 수정하거나 Index에 있는 변경사항들을 최근 커밋에 합치고 싶을 때 사용한다.

CLI :

$ git commit --amend # 최근 커밋에 합칠 때
$ git commit --amend -m "commit message" # 최근 커밋메시지 수정

더 편한 방법:

GitKraken 에서는 이렇게 커밋 창에서 간단하게 Amend 체크박스만 설정해주면 amend 옵션을 적용해 커밋한다. 넌 최고의 오징어야..⭐

커밋들을 하나로 합치자: squash

CLI

$ git rebase -i HEAD~n
# HEAD가 가리키고 있는 커밋으로부터 n개의 커밋을 하나로 합친다.

Gitkraken

쨘! 저렇게 커밋들을 선택하고 Squash 4 commits를 누르면 끝이다.

그럼 이렇게 커밋 히스토리가 변한다. 근데 여기서 조심해야하는 건, 이미 remote repository에 push를 해둔 상태에서 commit을 합치면 local의 브랜치와 remote의 브랜치가 다른 커밋 히스토리를 가지게 되는 것이므로, 이후에 push를 하면 error가 생긴다는 것이다. 그래서 이럴 때 squash 를 사용하는 것을 주의해야한다.

---

3. stash : working tree를 잠깐만 저장

우리가 파일의 변경사항을 git add 명령어를 실행해서 Index 영역에 올려놓은 뒤 그걸 저장해 놓을 수 있다. 무슨 말인지 한 번 보자.

Working directory에 stashTest 라는 파일을 생성했다. 그리고 나서 git status를 실행하니 Untracted files에 stashTest가 포함되어있음을 알 수 있다.

그 후 git add로 파일의 변경사항을 Index 영역에 저장한다.

그럼 당연히 stashTest가 추가되었다는 변경사항이 Changes to be committed에 포함되게 된다.

여❗기❗서❗ 이 변경사항을 stash push 명령어를 사용해서 잠시 저장해보자

명령을 실행하고 출력된 것을 보면 working directory와 index의 상태가 master(브랜치) 에 저장되었다고 써있다. 여기서 git status를 확인해보고 싶었다. 그래서 실행을 해보니까

아까 우리는 commit을 하지 않았었는데도 nothing to commit이라며 Index 영역에 있던 변경사항들이 사라진 것을 알 수 있다.

우리가 stash push로 저장한 변경사항들을 확인 하려면 stash list를 실행하면 된다.

이런 식으로 stash 했던 것들을 바로 볼 수 있다. stash는 스택처럼 LIFO 형식으로 데이터를 저장하기 때문에 먼저 push 한 변경사항들이 나중에 pop된다.

---

4. branch와 checkout

branch란?

우리는 Git으로 협업을 할 때 각자의 작업공간을 마련한다. 이걸 가능하게 해주는 게 Git의 branch이고 많은 사용자들이 git을 사용하는 이유이기도 하다. branch를 사용하면 프로젝트를 목적과 기능별로 분리해서 작업하는 것이 쉬워진다.

Git 브랜치는 커밋 사이를 가볍게 이동할 수 있는 어떤 포인터같은 것이다. 기본적으로 Git은 master 브랜치를 만든다. 처음 커밋하면 이 master 브랜치가 생성된 커밋을 가리킨다. 이후 커밋을 만들면 master 브랜치는 자동으로 마지막 커밋을 가리킨다.

이해가 잘 되는 사진이 있어서 가져왔다.

사진 출처 : Git 브랜치 - 브랜치란 무엇인가

보면 v1.0 이라는 브랜치와 master라는 브랜치가 있고 모두 f30ab (커밋)을 가리키고 있다. 그리고 현재 HEAD 포인터는 master를 가리키고 있는 것이다. 그래서 지금 상태에서 커밋을 추가하면 master가 최신 커밋을 가리키게 되고 head는 master를 그대로 가리키게 되는 것이다.

새 브랜치 생성하기 - git branch

브랜치를 하나 만들어보자!! 아래와 같이 git branch 명령으로 kayoung 브랜치를 만든다.

$ git branch kayoung

새로 만든 브랜치(kayoung)도 지금 작업하고 있던 마지막 커밋을 가리킨다.

checkout

git checkout 이라는 명령어는 다른 브랜치로 이동할 수 있게 해준다.

다른 브랜치로 이동한다 함은! HEAD 포인터가 원하는 브랜치를 가리키게 만드는 것과 같다.
현재 HEAD포인터가 kayoung 브랜치를 가리키고 있으면, master로 이동하기 위해 다음 명령을 실행하면 된다.

$ git branch master

---

5. branch 병합 1: merge

merge가 머지?

Git에서 브랜치를 여러 개 사용해서 개발할 때, 분업을 했던 것을 합쳐야하는 과정이 있어야할 것이다. 이럴 때 사용하는 명령이 merge다.

git branch를 사용할 때는 현재 내가 어느 브랜치에 있는지를 파악해야한다. 명령 뒤에 오는 브랜치가 현재 HEAD가 가리키는 브랜치에 합쳐지는 것이기 때문이다.

예를 들어,

이런식으로 현재 나는 master 브랜치에 있고 kayoung 브랜치가 따로 있다고 가정해보자. 이 때 git branch 명령을 밑에처럼

$ git merge kayoung

이렇게 사용해야하는 것이다.
그럼 결과는

CLI :

GUI :

이러고 나서는 kayoung branch를 삭제해도 된당!

편 안 🤗

3-way merging

브랜치 충돌(conflict)를 다루기 전에 Git이 브랜치를 병합할 때 같은 파일의 변경사항은 어떻게 처리하는지 살펴보자!!

Git은 3-way merging을 따라 merge를 수행한다.

설명하기 앞서 밑의 그림을 보면, Base는 branch를 생성하기 전의 원래 파일 상태이고, Source는
병합을 수행하는 브랜치에서의 파일 상태, 마지막으로 Target은 병합할 브랜치의 파일 상태이다.

3-way merging은 바로 이 세 가지 파일상태를 모두 비교하여 Merge하는 방식을 말하는 것이다.

그림으로 다시 돌아가자. Base와 Source, Target 파일들을 보면 첫번째 줄은 모두 같아서 Merged 파일에도 그대로 병합이 된다.

그리고 두번째 줄을 보면 Source에서만 바뀌었는데도 Git이 Base와 비교해서 바뀐 상태로 merge 한것을 알 수 있다. (B6로 바뀜)

세번째 줄은 마찬가지로 Target에서 변경된 사항을 merge해서 새로운 파일이 C4로 바뀌었음을 알 수 있다.

그리고 네 번째 줄이 merge conflict가 일어나는 과정이다! Source의 "D3"와 Target의 "D4"가 Base랑 비교해서 모두 변경이 일어났기 때문에 Git의 병합 알고리즘으로는 어떤 걸로 merge 해야할지 결정하지 못한다.

마지막으로 다섯 번째와 같이 Source와 Target 브랜치의 변경사항이 일치하는 경우에는 충돌이 일어나지 않고 변경된 사항으로 병합이 이루어진다.

---

어렵다 깃
고프다 배