Git
왜 Branch를 쓰는 걸까요?
Branch는 프로젝트의 개발 과정에서 독립적인 작업 흐름이다.
기존 코드 베이스에서 파생된 복사본이라 생각하면 쉽다. 원본 코드와 상관 없이 독립적으로 개발을 진행 할 수 있게 해준다.
그래서, 새로운 기능이나 실험적인 수정을 진행할 수 있고, 안정성이 확보된다.
버전 관리도 용이하다.
Git의 브랜치는 커밋 사이를 가볍게 이동할 수 있는 Pointer같은 것이다. 기본적으로 Git은 main 브랜치를 만든다. 처음 커밋하면 이 main 브랜치가 생성된 커밋을 가리킨다.
git 공식 홈페이지엔 아직 master와 checkout으로 설명이 되어있으니 주의..!
옵셔널한 얘기로 이전에 git push origin master에 익숙해진 나머지 master를 썼다가 오류가 나서 알게 된 정보를 풀어본다!
master? main?
master라는 용어는 초기 버전부터 사용되어온 기본 브랜치의 이름이다.
최근 몇 년간 기술 커뮤니티와 소프트웨어 개발 커뮤니티에서 인종 차별과 포용성 문제에 대한 논의가 더욱 활발해지면서, master라는 용어의 사용에 대한 비판이 제기되었다. 남부 흑인 노예들이 백인 주인을 마스터라고 불렀기 때문이다.
master를 계속 언급하게 되는 환경을 없애기 위해 GitHub과 같은 대표적인 Git 호스팅 플랫폼과 Git 커뮤니티는 기본 브랜치의 이름을 master에서 main으로 변경하는 움직임을 보였다.
변경을 통해 개발 커뮤니티에서 더 포괄적이고 통합적인 분위기를 조성하고, 모든 개발자들이 차별이 없는 환경에서 작업할 수 있도록 하는 것을 목표로 했다.
- Microsoft-owned coding site Github to replace the term 'master' in push to remove slavery references
merge
Fast forward merge
브랜치를 실제로 merge 하는 대신, Git이 히스토리를 통합하기 위해 해야 할 일은 현재 브랜치 끝에서 대상 브랜치 끝으로 이동(즉, 빨리 감기)하는 것뿐이다. 이렇게 하면 대상 브랜치에서 도달할 수 있는 모든 커밋을 현재 브랜치를 통해 사용할 수 있으므로 히스토리를 효과적으로 통합할 수 있다.
--no-ff 옵션도 있다. (말그대로 ff merge 안해.의 뜻)
- 히스토리가 선형적으로 유지
- 추가적인 커밋이 생성되지 않는다.
- 병합 기록이 간단하다!
3-way/Recursive merge
쉽게 말해서 내 브랜치 커밋, 다른 브랜치 커밋을 병합해서 새로운 커밋을 생성하는 방법
- 공통 기반 커밋: 두 브랜치를 병합하기 위해서는 공통으로 공유하는 기반 커밋이 있어야 한다. 이 기반 커밋은 두 브랜치의 조상이 되는 커밋이다.
- 동시 수정: 기반 커밋 이후에 두 브랜치에서 동시에 같은 파일 또는 같은 부분을 수정했을 경우, Git은 이러한 변경 사항을 병합해야함.
- 동시에 수정된 부분을 자동으로 결합하고 충돌을 최소화하여 브랜치를 통합한다.
- 3-way merge를 하면 병합 커밋이 생성되기 때문에 트리가 다소 지저분해진다는 단점이 있다.
rebase
두 개의 공통 Base를 가진 Branch에서 한 Branch의 Base를 다른 Branch의 최신 커밋으로 branch의 base를 옮기는 작업.
base를 새롭게 설정한다.
- 공유 Branch의 최신 변경사항을 즉각 반영할 수 있다.
- 커밋 이력을 남기지 않아 history가 깨끗하다.
- 작업 Branch의 각각 commit 마다 conflict를 해결해야한다.
- Rebase를 하게되면 충돌이 일어난 파일을 하나씩 수정해야함. 모든 충돌이 해결되고 리베이스가 성공한 이후에는 강제 푸시를 진행한다.
- 커밋 체크섬 값도 달라진다!
- 혼자 사용하는 브랜치에만 사용하는 것을 권장. (여러 Git 가이드에서 원격 저장소에 존재하는 브랜치는 rebase를 하지 않는 것을 권장함.)
rebase --onto <new base>
현재 브랜치에서 선택한 기준 커밋까지 이동한 후, 다른 브랜치 위에 해당 커밋을 적용하여 새로운 커밋을 생성한다.
여러 커밋 가져오기 가능!, 커밋 히스토리를 재배치하여 새로운 커밋을 생성함.
(선택한 커밋들을 기준 커밋 위에 순차적으로 적용하는 것을 의미)
git rebase --onto <newbase> <upstream> [<branch>]
내가 원하는 커밋들만 떼어서 반영할 수 있는 것..!
의존성을 제거할 수 있다. 버그가 있거나, 기능을 따로 구현하게 되었다거나 등등의 상황에서 좋을듯.
Cherry-pick
rebase onto랑 비슷한 것 아니야? 할 수 있는데 차이점이라면 cherry-pick은 단일 커밋만 들고올 수 있음.
실습으로 연습해보는 것만이 살 길... 연습 해보겠다 👀!
참조 ✅
- Git 스터디 📚🤓
- Git 브랜치 - 브랜치란 무엇인가
- Git Merge
- [Git] Git Rebase란?
항상 좋은 글 감사합니다.