Git 브랜치 관리

Git Flow 기반 워크플로에서의 브랜치 관리 방식

• develop:
  • main 브랜치에 병합한 뒤에도 삭제하지 않는것이 일반적 (프로젝트의 지속적인 개발 흐름을 담당하는 브랜치이므로)
  • main 브랜치로 병합 시 merge 방식이 일반적 (릴리즈 단위의 기록을 보존하려는 목적, 여러 feature 통합 흔적 유지)
• feature/*:
  • develop 브랜치에 병합한 뒤 삭제하는 것이 일반적 (기능 개발이 완료되어 develop 에 반영되었기 때문에 더 이상 해당 브랜치가 필요 없음. GitHub, GitLab 등에서는 PR 을 머지할 때 자동으로 브랜치를 삭제하는 옵션도 있음)
  • develop 브랜치로 병합 시 squash 또는 rebase 방식이 일반적 (커밋을 정리해서 develop 히스토리를 깔끔하게 유지하려는 목적)

squash / rebase 이후 브랜치 관리

squash 또는 rebase 이후에는 해당 브랜치를 삭제하는 것이 일반적입니다. 커밋 히스토리를 기존 브랜치와 다르게 변경하므로, 병합 후 브랜치를 계속 유지하는 게 의미가 적거나 오히려 혼란을 줄 수 있습니다.

• squash:
  • 브랜치에서 작업한 모든 커밋이 병합되려는 브랜치에 하나의 새로운 커밋으로 변환되어 현재 브랜치와 연관이 없어짐 (squash 완료한 이후에 merge 를 진행하면 또 다시 새롭게 merge 를 하는 꼴이 됨)

before squash
(develop): c - d1 - d2 - d3
(feature/some-feature): c - f1 - f2 - f3
(origin/feature/some-feature): c - f1 - f2 - f3

after squash
(develop): c - d1 - d2 - d3 - new1
(feature/some-feature): c - f1 - f2 - f3
(origin/feature/some-feature): c - f1 - f2 - f3

• rebase:
  • 원래의 커밋 히스토리에 병합되려는 브랜치의 커밋이 들어오고 현재의 커밋은 새로운 커밋으로 변환되어 기존 브랜치와의 연결성이 끊어져버리며, 이에 따라 원격 저장소와 히스토리가 달라져 push 불가해짐 (git push 는 기본적으로 fast-forward 만 허용하며 안될 경우 force push 를 통해 강제 푸시 해야함)
  • 강제 푸시 이후에 pull 이 동작은 하지만 그렇게 되면 동일한 내용의 커밋이 중복되는 꼴

before rebase
(develop): c - d1 - d2 - d3
(feature/some-feature): c - f1 - f2 - f3
(origin/feature/some-feature): c - f1 - f2 - f3

after rebase
(develop): c - d1 - d2 - d3
(feature/some-feature): c - d1 - d2 - d3 - f1' - f2' - f3'
(origin/feature/some-feature): c - f1 - f2 - f3

커밋 해시 (commit hash)

커밋 해시는 (혹은 커밋 ID, commit ID) 커밋의 내용, 메타데이터, 부모 커밋 등을 바탕으로 계산된 커밋의 고유한 식별자입니다. (Git 은 기본적으로 SHA-1 을 사용하지만, 일부 최신 버전에서는 SHA-256 으로도 사용할 수 있게 되어 있습니다.)

SHA: 암호학적으로 안전한 고정 길이의 해시값을 생성하는 데 사용되는 Secure Hash Algorithm (보안 해시 알고리즘) 의 약자입니다.

 

Git 에서 커밋 해시는 다음 정보를 바탕으로 생성됩니다:

• 커밋의 내용 (트리 상태)
• 부모 커밋의 해시
• 커밋 메시지
• 커밋한 시간
• 커밋한 사람 정보 등

rebase 수행 시 기존 커밋의 부모 커밋이 달라지기 때문에 커밋 해시가 변경됩니다.

squash 또한 결과 커밋 자체가 완전히 새로 생성된 것이기 때문에 커밋 해시가 변경됩니다.