Git 요약 6. Branch(브랜치)란?, Merge(병합), Branch 활용법(workflow)

Branch(브랜치)란?

• 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행 가능
• Git은 브랜치를 만들어 작업하고 나중에 Merge 하는 방법을 권장. 하루에 수십번씩해도 괜찮다.

 

• Staging 하면 Git은
  • Git 저장소에 파일을 저장하고(Git은 이것을 Blob이라고 부른다)
  • Staging Area에 해당 파일의 체크섬을 저장
• Commit하면 Git은
  • root 디렉토리와 각 하위 디렉토리의 Tree(폴더구조) Object를 체크섬과 함께 저장소에 저장 후
  • Commit Object를 저장 
    • 1. 현 Staging Area에 있는 데이터의 스냅샷에 대한 포인터,
    • 2. Author나 commit message 같은 meta data,
    • 3. 이전 commit에 대한 포인터 등을 포함
• 이전 커밋 포인터가 있어서 현재 커밋이 무엇을 기준으로 바뀌었는지를 알 수 있다.
• 브랜치를 합친 Merge 커밋 같은 경우에는 이전 커밋 포인터가 여러 개 있다.

• git branch <branch> 새 브랜치 생성
  
  • git branch 아무런 옵션 없이 실행하면 브랜치의 목록을 보여준다.
  • git branch -v 브랜치마다 마지막 커밋 메시지도 함께 보여준다.
  • git branch --merged, Merge 된 브랜치인지 필터링
  • git branch --no-merged  Merge 되지 않은 브랜치인지 필터링해 볼 수 있다.
    
    • 아직 Merge 하지 않은 커밋을 담고 있기 때문에 git branch -d 명령으로 삭제되지 않는다.
    • git branch -D <branch> Merge 하지 않은 브랜치를 강제로 삭제
• git checkout <branch> 다른 브랜치로 이동
• git checkout -b <branch> 브랜치를 만들면서 Checkout까지 한 번에

• 실제로 Git의 브랜치는 어떤 한 커밋을 가리키는 40글자의 SHA-1 체크섬 파일에 불과하기 때문에 만들기도 쉽고
  지우기도 쉽다. 새로 브랜치를 하나 만드는 것은 41바이트 크기의 파일을(40자와 줄 바꿈 문자) 하나 만드는 것에
  불과하다.
• 브랜치를 이동하려면 해야 할 일이 있다. 아직 커밋하지 않은 파일이 Checkout 할 브랜치와 충돌 나면 브랜치를
  변경할 수 없다. 브랜치를 변경할 때는 워킹 디렉토리를 정리하는 것이 좋다. (Stashing과 Cleaning. 추후 설명)
• git branch -d <branch> Merge하여 더 이상 필요없는 브랜치는 삭제

반응형

Merge

• git merge <branch> branch를 합친다.
• Fast forward(빨리 감기) Merge
  • 기존 브랜치에 변경사항이 없고 새 브랜치의 내용을 덮어쓰기만 하면 되면 사용.
  • A 브랜치에 다른 B 브랜치를 Merge 할 때 B 브랜치가 A 브랜치 이후의 커밋을 가리키고 있기 때문에 A 브랜치가 B 브랜치와 동일한 커밋을 가리키도록 이동시킴.
• Merge Commit (3-way Merge)
  
  • 각 브랜치가 가리키는 커밋 두 개와 공통 조상 하나를 사용
  • 3-way Merge 의 결과를 별도의 커밋으로 만들고 나서 해당 브랜치가 그 커밋을 가리키도록 이동시킨다. 그래서 이런 커밋은 부모가 여러 개.
  • Conflict 충돌
    • Merge 하는 두 브랜치에서 같은 파일의 같은 부분을 동시에 수정하고 Merge하면 Git은 해당 부분을 Merge 하지 못한다.
    • Merge 충돌이 일어났을 때 Git이 어떤 파일을 Merge 할 수 없었는지 살펴보려면 git status 명령을 이용
    • 개발자는 해당 부분을 수동으로 해결한다.
    • ======= 위쪽의 내용은 HEAD 버전의 내용이고 아래쪽은 merge하려는 브랜치의 내용이다. 충돌을 해결하려면 위쪽이나 아래쪽 내용 중에서 고르거나 새로 작성하여 Merge 한다.
    • git add 명령으로 다시 Git에 저장
    • git mergetool -> 다른 Merge 도구도 충돌을 해결할 수 있다. 
      
      • Merge 도구를 종료하면 Git은 잘 Merge 했는지 물어본다. 잘 마쳤다고 입력하면 자동으로 git add 가 수행되고 해당 파일이 Staging Area에 저장된다. git status 명령으로 충돌이 해결된 상태인지 다시 한번 확인 가능
    • git commit 명령으로 Merge 한 것을 Commit하기 때문에 "Merge Commit"이라 부른다.

Branch Workflow

• Master branch
  • Long-running branch
  • 배포용으로 검증된 안정적인 프로그램만 있는 주류 브랜치
  • 태그로 버전 숫자가 매겨져 있다.
• Develop branch or next branch
  • master에서 갈라져 나와 개발을 진행하는 브랜치
• Topic branch or feature branch
  • 어떤 한 가지 주제나 작업을 위해 만든 짧은 호흡의 브랜치
  • 보통 로컬에서만 작업. 원격 서버에 올리지 않는다.
  • 새로운 기능 개발이나 버그 수정이 필요할 때 develop 브랜치로부터 분기
  • 수정이 완료되면 develop 브랜치로 병합
• Release branch
  • 개발 완료된 프로그램
  • 모든 기능이 정상적으로 동작하는지 테스트
  • 버그가 나오면 수정한다.
  • 모두 완료된 경우 master로 병합. Tag번호로 버전 번호 달기.
  • 수정된 내용을 develop에도 적용
• hotfix branch
  • master 브랜치에서 급히 그 부분만 수정해서 배포해야하는 문제를 수정
  • develop 브랜치는 이미 개발이 진행되고 있기 때문에 develop에서 작업한 뒤 다시 테스트하려면 많은 시간이 들어 기존 master에서 문제가 되는 부분만 수정한뒤 배포한다.
  • 수정된 내용을 develop에도 적용
• 프로젝트 규모가 크면 proposed 혹은 pu (proposed updates)라는 이름의 브랜치를 만들고 next 나 master 브랜치에 아직 Merge 할 준비가 되지 않은 것을 일단 Merge 시킨다.
• 중요한 개념은 브랜치를 이용해 여러 단계에 걸쳐서 안정화해 나아가면서 충분히 안정화가 됐을 때 안정 브랜치로 Merge 한다는 점이다.
• https://nvie.com/posts/a-successful-git-branching-model/ 참고

도움이 되셨다면 광고를 한 번씩 클릭 부탁드려요🥰