Branch & Merge

1. 각자 폴더 만들기

• 각자 폴더에 붙여넣기
• `new`로 브랜치 변경 후 `git pull`
• `new-{이름}-3rd`브랜치 생성 이후 `checkout`하고 작업하기

Branch & Merge

1. base는 무엇을 의미하나요?

• merge 하려 하는 branch들의 공통 조상 branch

2. branch, merge, conflict가 각각 무엇을 의미하는지 알려주세요.

• Branch: 마치 평행우주처럼 우리의 저장소를 여러 가지 상태로 공존할 수 있게 해주는 것
• Merge: 병합하다, 합치다
• Conflict: 두 개의 branch가 같은 이름의 파일에서 같은 부분을 수정했을 때 git은 자동으로 해당 수정 사항들을 병합하지 못함. 이때 생기는 현상이 conflict(충돌)임

3. merge를 왜 사용해야 하나요?

• 어떤 branch에서의 작업이 다른 branch에서도 유용할 것 같으면 ‘merge’를 해서 작업의 효율성을 높일 수 있음

4. 두 개의 branch를 병합(merge)할 때, 병합되는 쪽이 아닌 병합받는 쪽에 checkout을 해야하는 이유를 history와 관련지어 설명해주세요.

• 병합이 되는 쪽은 새로운 버전이 생기지 않기 때문임

Merge & Conflict

1. `Auto-merging`이 무엇인지 알려주세요.

• conflict(충돌)이 일어나지 않는 경우, git이 자동으로 merge(병합)해주는 것

2. 스터디 시간에 배운 `conflict`는 무엇을 의미하는 지 알려주세요.

• 두 개의 branch가 같은 이름의 파일에서 같은 부분을 수정했을 때 git이 자동으로 해당 수정 사항들을 병합하지 못하는 현상이 발생하는 데 이것을 conflict(충돌)이라고 함

3. 서로 다른 파일 병합, 같은 파일 다른 부분 병합, 같은 파일 같은 부분 병합 중 `auto-merging` 기능이 제공되는 것을 구분하고 제공되지 않는 것은 왜 제공되지 않는 지 알려주세요.

• 서로 다른 파일 병합: auto-merging 기능 제공됨
• 같은 파일 다른 부분 병합: auto-merging 기능 제공됨
• 같은 파일 같은 부분 병합: auto-merging 기능 제공되지 않음/양쪽 다 동시에 수정한 것이므로 git이 처리할 수 없어 사용자가 처리해야 함

4. fig.1은 conflict 발생을 유도한 후 명령창입니다. 이후 conflict를 해결하는 방법을 알려주세요.

• nano work.txt - 파일을 열어 편집할 수 있게 됨/구분자 등 git이 우리를 위해 제공한 내용을 지우고, 변경할 최종 사항만을 입력하기
• git add work.txt - 사용자가 충돌을 해결했음을 git에게 알림
• git commit - commit까지 완료해줘서 파일을 수정된 상태로 저장하기

Cherry-pick & rebase

1. `cherry-pick`와 `rebase`는 어떤 기능의 명령어이고 왜 필요한지 알려주세요.

• Cherry-pick: 특정한 commit(버전) 하나만 픽업하여 다른 commit(버전) 뒤에 붙일 수 있는 기능
• Rebase: 병렬적으로 나타나는 작업의 진행 흐름을 한 작업이 끝난 후 다른 작업이 진행된 것으로 나타내는 것(직렬로 나타냄)/훨씬 더 직관적으로 작업의 진행 흐름을 파악할 수 있게 함

2. fig.2을 직접 구현한 결과가 fig.3입니다. fig.2의 결과와 같게 만들려면 어떻게 해야하는 지 알려주세요.

• git checkout master - 현재 위치한 branch를 topic에서 master로 변경하기
• git cherry-pick daa4 - t2 가져오기(cherry-pick)

3. fig.3을 fig.4의 결과와 같게 만들고 싶다면 어떤 명령어를 쳐야하는지 알려주세요(HEAD는 HEAD->master에 있음.)

• git checkout master - 이동시키려는 branch로 이동하기
• git rebase topic - topic branch가 가리키고 있는 commit(버전)인 t3으로 base를 옮기기

4. `rebase`의 조건이 있는데 어떤 것일 지 추측해보세요.

• 버전들이 원격 저장소로 push 되기 전까지만 rebase 가능(push 후에는 rebase 불가)/내 컴퓨터(나의 local)에서만 rebase 가능

Advanced

1. fig.5에서 `HEAD`가 `master`의 최신 버전이 아닌 `dc9d3c7`에 checkout 되어 `git merge topic`하게 된다면 어떻게 될지 추측해보세요.

• topic branch의 최신 commit인 e4b8d17이 포함된 새로 병합되어 만들어진 commit이 생성됨/병합 후 HEAD는 새로 병합되어 만들어진 commit을 가리키게 됨

2. fig.5에서 `git commit --amend`로 최신 버전(`33763e0`, `HEAD->master`)의 커밋 메세지를 수정할 수 있었습니다. 만약 최신 버전의 __커밋 내용__ 즉, 파일 안의 코드를 한 줄 수정하고 싶을 때는 히스토리를 아예 삭제하는 `git reset --hard dc9d3c7` 대신 어떤 명령어를 사용해야 하는지 알려주세요.

• nano work.txt - 파일을 열고 수정하기
• git add work.txt
• git commit --amend - commit message를 수정할 수 있는 editor가 열리므로 commit 내용을 수정할 수 있게 됨

3. `cherry-pick`에서도 `conflict`가 발생할 수 있습니다. 충돌 원인을 예상해보고 해결 방법을 알려주세요.

• 충돌 원인: 두 branch에서 같은 파일, 같은 부분을 수정하면 conflict 발생할 수 있음
• 해결:
• git status - 충돌이 발생한 파일을 알아내기
• nano work.txt - 충돌이 발생한 파일을 열어 수정하여 충돌 해결하기
• git add work.txt - git에게 충돌을 해결했음을 알리기

4. 터미널에 `git merge --help`를 쳐보면 merge에도 굉장히 많은 옵션이 있음을 알 수 있습니다. 이미 실행한 merge를 취소하는 옵션을 포함해서 세 가지의 옵션을 임의로 골라 알려주세요.

• --abort: 현재 진행 중인 병합을 중단하고, 병합 시도 전의 상태로 되돌림/병합 도중 충돌이 발생했거나 병합을 계속할 수 없는 경우에 유용함
  • git merge --abort
• --squash: merge하는 commit들을 하나의 commit으로 합침/병합된 branch들의 모든 변경 사항이 현재 branch에 적용되지만, merge된 commit 자체는 생성되지 않으므로 수동으로 commit 해줘야 함
  • git merge --squash [branch name]
  • git commit
• --no-ff: Fast-forward merge을 방지하고, 항상 새로운 merge commit을 생성하므로 merge의 history가 명확하게 남음/Fast-forward merge은 history를 단순화할 수 있지만, merge commit을 만들지 않기 때문에 merge 작업의 명시적 기록이 남지 않음
  • git merge --no-ff [branch name]

5. 정말 만약에... merge 한 브랜치를 push하고 pr이 승락된 브랜치를 되돌려야한다면 어떻게 되돌릴 수 있을 지

• 되돌리기 작업을 새로운 버전(commit)으로 기록하기 때문에 history를 보존할 수 있는 revert를 사용하면 됨
• git log - 현재 branch의 상태와 commit history 체크하기
• git revert "commit ID" - revert를 사용해서 되돌리기

6. branch간에 merge를 진행할 때 새로운 commit이 생겨날 수도 있고 아닐 수도 있습니다. 이 관점에서 `fast-forward merge`, `3-way merge`를 비교하여 알려주세요.

• Fast-Forward Merge: Fast-forward는 새로운 commit을 생성하지 않고, branch 포인터를 최신 commit으로 이동시키는 방식입니다. 이 방식은 history가 깔끔하지만, branch가 합쳐졌다는 기록이 남지 않으므로 작업의 흐름이 명확하지 않을 수 있습니다.
• 3-Way Merge: 3-way merge는 두 개의 branch와 그들의 공통 조상을 기준으로 새로운 commit을 생성하여 병합하는 방식입니다. 이 방식은 merge가 이루어졌다는 기록이 명확하게 남고, 복잡한 작업 이력을 관리하는 데 유리합니다.