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

Index

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

---

5. branch 병합 1: merge

merge conflict?

Merge conflicts happen when you merge branches that have competing commits, and Git needs your help to decide which changes to incorporate in the final merge.
- About merge conflicts, github docs

merge conflict는 competing commit을 가지는 브랜치들을 병합하려할 때 일어난다. 그리고 이때 사용자가 최종 병합에서 포함해야하는 커밋을 결정해주어야한다.

Competing Commit은

1. 같은 파일의 같은 라인을 다르게 변경한 사항이 있거나,
2. 한 브랜치가 파일을 수정했는데, 다른 브랜치가 그 파일을 삭제한 경우

에 생긴다.

Resolve merge conflict

Git의 merge 방식에 따르면, merge conflict가 일어났을 경우 반드시 우리가 직접 어떤 변경사항을 새로운 커밋에 포함시킬지 결정해야한다.

예를 들어, 만약 나와 또 다른 누군가가 같은 레포지토리의 다른 브랜치를 사용하여 둘 다 styleguide.md 라는 파일의 동일 라인을 수정한다면, 이 두 브랜치들을 병합하려 할 때 컨플릭트 에러를 만나게 된다. 이 때 우리는

1. Git bash를 열고 해당 레포지토리로 이동한다.

   cd _REPOSITORY-NAME_

2. git status로 merge conflict 에 영향받은 파일들의 리스트를 본다. 이 예제에서는 styleguide.md 가 그러한 파일이다.

   $ git status
   > # On branch branch-b
   > # You have unmerged paths.
   > #   (fix conflicts and run "git commit")
   > #
   > # Unmerged paths:
   > #   (use "git add ..." to mark resolution)
   > #
   > # both modified:      styleguide.md
   > #
   > no changes added to commit (use "git add" and/or "git commit -a")

3. 해당 파일을 원하는 에디터로 연다.

4. 파일을 열고나서, merge conflict가 처음 발생한 부분을 찾기 위해서 <<<<<<<를 검색해본다. 그 부분으로 이동을 하면

   ```bash
   If you have questions, please
   <<<<<<< HEAD
   open an issue
   =======
   ask your question in IRC.
   >>>>>>> branch-a
   ```

   이런 식으로 <<<<<<< 뒤에 써있는 이름(HEAD) base branch의 변경사항이 있고, ======= 로 구분되어있는 뒷부분은 >>>>>>> 뒤에 써있는 이름을 가진 branch의 변경사항이 있는 것이다. 이 예제에서는 한 사람이 "open an issue"라고 base 또는 HEAD 브랜치에서 변경을 한것이고, 다른 사람은 같은 줄에서 "ask your question in IRC" branch-a라는 브랜치에서 변경을 한 것이다.

5. 컨플릭트를 해결하려면 위의 충돌사항들을 다 지워버리고 원하는 내용을 적어주면 된다.

깃크라켄에서의 예시를 만들어봤다.
일단 브랜치는 master와 mergeTest 가 있고, conflictTest라는 파일의 동일라인을 각자 다르게 수정하고 커밋했다.

그 후 master브랜치에서 mergeTest 브랜치를 병합하려고 하니

다음과 같이 conflict error 가 발생하였다.

오른쪽 패널의 ConflictedFiles 의 conflictTest를 더블클릭하니까 아래처럼 새로운 창이 떴다! 충돌하는 변경사항들을 보여주는 창이었다.

변경사항들 중에 원하는 것을 추가 Result에 추가할 수 있었다.

이런식으로 😃

다 했으면 우측 상단의 save 버튼을 눌러주면된다. 그리고나선 이전 화면으로 돌아오게 되는데, 패널이 다음과 같이 바뀌어있었다. 충돌사항을 해결했으니 새로운 커밋을 만들고, merge 해주었다.

merge conflict 해결도 깃크라켄으로 하면 너무 쉽당 💖

6. branch 병합 2: rebase

브랜치 병합 커맨드에는 merge 말고도, rebase 라는 것이 있다. merge랑은 방식이 조금 다른데! 지금부터 살펴보자 🤩

merge 와 rebase

아래 사진을 보고 차이를 설명을 해주신게 이해하기에 매우 좋았다.

merge를 보면, 이미지에서는 master 브랜치에 feature 브랜치를 병합해도 feature 브랜치의 커밋 히스토리가 원래 위치에, 원래 모습 그대로 남아있다.

그런데 rebase의 결과를 보면, feature 브랜치의 base 커밋이 master 의 최신 커밋이 되고, feature 브랜치의 커밋들이 master의 최신 변경사항들을 반영하는(?) 커밋으로 바뀌었다.

그리고 또다른 차이는, 예시로 하면

master에 feature 를 merge할 때는

$ git checkout master
$ git merge feature

이렇게 master 브랜치에서 merge를 실행했는데,

feature의 base commit을 master로 rebase할 때는

$ git checkout feature
$ git rebase master

이런 식으로 feature 브랜치에서 rebase를 실행해야 한다는 점이다.

rebase의 장단점

차이는 알겠고 그럼 rebase를 왜 사용하는지 보면,

• 단순한 히스토리
• 여러 개발자들이 같은 브랜치를 공유할 때 커밋을 합치는 가장 직관적이고 깔끔한 방법이다.

단점으로는

• 충돌상황에서 다소 복잡하다. 커밋 순서대로 Rebase를 하는데, 각 커밋마다 충돌 해소를 순서대로 해주어야 한다.
• 해당 커밋들을 다른 곳에 푸시한 적이 있다면 히스토리를 다시 쓰는 것에 부작용이 발생한다. 👉🏻 이미 push 했다면 rebase 후 푸시 에러가 발생한다.

결론

rebase와 merge 를 상황에 따라 잘 사용해야한다.

1. 여러 개발자들이 같은 브랜치를 공유할 때는 pull & rebase 가 히스토리를 깔끔하게 유지하는데 좋다.
2. 완료된 기능 브랜치를 합칠 때는 merge를 사용한다.
3. 기능 브랜치에 부모 브랜치의 변경 내용을 반영하고 싶을 때
   • 브랜치를 다른 곳에 push한 적이 없을 때 👉🏻 rebase
   • Git을 사용하고 다른 사람이 이 기능브랜치를 체크아웃할 일이 없을 거라 확신 할 때 👉🏻 rebase
   • 이외의 상황 👉🏻 merge

7. branch-전략

대표적인 브랜칭 전략으로는

• Git-flow
• GitHub-flow
  가 있다.

1. Git-flow

Git-flow는 브랜치를 크게 네 가지로 나누어 개발하는 전략이다.

• Main branch
• Feature branch (Topic branch)
• Release branch
• Hotfix branch

가장 중심이 되는 브랜치는 main 브랜치이며, 머지된 feature, release, hotfix 브랜치는 삭제한다.

main branch

master

• 배포 가능한 상태만을 관리하는 브랜치

develop

• 다음에 배포할 것을 개발하는 브랜치
• develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.

Supporting branch

1) feature (topic)

• 기능을 개발하는 브랜치로, develop 브랜치로부터 분기
• feature 브랜치는 그 기능을 다 완성할 때까지 유지하고, 완성 후 develop에 머지 후 삭제
• feature 브랜치는 보통 개발자 저장소에만 있는 브랜치이고 origin에는 push하지 않는다.

2) release

• 배포를 위한 최종적인 버그 수정 등의 개발을 수행한다

3) hotfix

• 배포한 버전에서 긴급하게 수정할 필요가 있을 경우, master 브랜치에서 분기

---

2. Github-flow

Git-flow가 Github에서 사용하기에 복잡해서 나온 브랜칭 전략.
master 브랜치에 대한 역할만 정확하다면 나머지 브랜치들에 대해서는 관여하지 않는다. 즉, hotfix 브랜치나 feature 브랜치를 구분하지 않는다. 다만 우선순위가 다를 뿐이다. 이 때는 pull request 기능을 사용하도록 권장한다.

이 브랜칭 전략은 수시로 배포가 일어나고, CI와 배포가 자동화돼있는 프로젝트에 유용하다.

아.. 자세한건 Git 브랜칭 전략 - 갓우리코딩 여기서 보장

8. commit의 적정 단위와 협업, 메시지

• 커밋 하나는 하나의 작업만 하는 것이 좋다
• 작업에 필요한 파일들 이외의 파일을 건드리면 안 된다
• 적절한 브랜치에 커밋을 해야한다: 당장 필요하다고 현재 브랜치에 하는 것은 좋지 않다

끄읏 😃