[문과 코린이의 IT 기록장] Git 심화 - Brnach 심화 (Fastforward vs 3-way merge, 다른 브랜치에서 원하는 커밋만 따오기, 다른 브랜치에서 파생된 브랜치 옮겨붙이기, 여러 커밋들을 하나로 묶어 가져오기, 협업을 위한 브랜치 활용법)
제대로 파는 Git & GitHub - by 얄코 - 인프런 | 강의
코알못도 따라올 수 있는 친절하고 쉬운 강좌! 현업 개발자는 Git 박사로 들어주는 끝판왕 강좌!, - 강의 소개 | 인프런...
www.inflearn.com
[문과 코린이의 IT 기록장] Git 심화 - 커밋 관리하기 (커밋하는 방법 (권장사항), 보다 세심하게 스
[문과 코린이의 IT 기록장] Git 심화 - 커밋 관리하기 (커밋하는 방법 (권장사항), 보다 세심하게 스테이징하고 커밋하기, 커밋하기 애매한 변화 치워두기, 커밋 수정하기, 과거의
vansoft1215.tistory.com
[문과 코린이의 IT 기록장] Git 심화 - 취소 및 되돌리기 (관리되지 않는 파일들 삭제하기, 커밋하
[문과 코린이의 IT 기록장] Git 심화 - 취소 및 되돌리기 (관리되지 않는 파일들 삭제하기, 커밋하지 않은 변경사항 되돌리기, reset 이후 복구 방법) 제대로 파는 Git & GitHub - by 얄코..
vansoft1215.tistory.com
2022.04.14 - [문과 코린이의, [Git] 기록] - [문과 코린이의 IT 기록장] Git 심화 - 태그 (커밋에 태그 달기, 원격의 태그와 릴리즈)
[문과 코린이의 IT 기록장] Git 심화 - 태그 (커밋에 태그 달기, 원격의 태그와 릴리즈)
[문과 코린이의 IT 기록장] Git 심화 - 태그 (커밋에 태그 달기, 원격의 태그와 릴리즈) 제대로 파는 Git & GitHub - by 얄코 - 인프런 | 강의 코알못도 따라올 수 있는 친절하고 쉬운 강좌! 현업
vansoft1215.tistory.com
1. Fastforward vs 3-way merge
- Git에서 merge하는 두 가지 전략 : Fastforward vs 3-way merge
1) Fast forward
- 두 브랜치가 공통의 조상을 가지고 있지만, 한쪽 브랜치에만 그 이후의 커밋이 있을 경우 사용한다.
- A와 B를 병합할 때 이를 위한 새로운 커밋을 만드는 것이 아닌, 그냥 A의 헤드를 B로 옮기는 과정이다.
- 이 과정이 완료된 후, 병합된 브랜치는 없애준다. (즉, A브랜치만 남게 됨)
- 단점 : 작업이 완료된 후 부터는, 어떤 브랜치를 사용했고 언제 병합했는지 등 기록을 확인할 수 없다.
2) 3-way merge
- 원 브랜치의 변화가 없도록, fast-forward하지 않고 병합 커밋을 만들어서 merge하는 방식을, 3-way merge라고 한다.
$git merge --no-ff 병합할 브랜치명- 각 브랜치의 마지막 커밋 2개 + 공통 조상, 이렇게 총 3가지의 커밋을 이용해, 새로운 커밋을 만들어내는 과정이다.
* 2-way merge인 경우에는, 동일하게 관찰되는 부분을 제외하고는, 기존에 어떤 것이었는지를 확실하게 정하기가 어려우며, 따라서 충돌 여부 또한 확인하기 어렵다. (3-way merge는 확인 가능)
2. 다른 브랜치에서 원하는 커밋만 따오기
cherry-pick은 merge, rebase와는 달리, 특정 커밋만 복사해서 가져오는 것이며, 이 복사해온 커밋은 기존 복사한 커밋과는 다른 것이다.
$git cherry-pick 커밋해시
* 소스트리 : 가장 최근에 생긴 커밋을 펼쳐서 보여줌
3. 다른 브랜치에서 파생된 브랜치 옮겨붙이기
$git rebase --onto 도착브랜치 출발브랜치 이동할브랜치
$git rebase --onto main fruit citrus
$git switch main
$git merge citrus
# main 브랜치 헤드를 옮겨주는 것
4. 여러 커밋들을 하나로 묶어 가져오기
브랜치 커밋들의 내역들을 디테일하게 기억하지 않고, 해당 커밋들을 모아서 하나의 커밋으로 만들어 추가시키고 싶을 경우 사용하는 방법이다.
$git merge --squash 대상브랜치이 명령어를 수행하면, 대상 브랜치의 커밋들이 하나로 묶여 추가되었지만, 커밋된 상태가 아닌 staging에 존재하는 상태로 만들어진다. 이는 $git status를 통해 확인할 수 있다.
$git commit
# 이후 commit 진행
최종으로 main에 추가적으로 붙여진 결과물 확인
* squash해서 커밋한 내역들이 사라지는 것이 아니라, 그대로 남아있음
5. 협업을 위한 브랜치 활용법
- Gitflow : 오늘날 it기업들에서 함께 협업을 통해 SW를 만들 때, brnach를 활용하는 하나의 방법론을 의미한다.
* 이는 하단의 링크를 그대로 활용해도 되고, 프로젝트 및 기업의 성격에 맞게 적용해서 쓰는 것도 가능하다.
A successful Git branching model
In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful.
nvie.com
[ 사용되는 브랜치들 ]
1) master = main
- 사용자들에게 실제로 선보여질, 즉 출시되어 배포될 버전들이 merge가 되는 부분이다.
- 따라서 하나의 커밋마다 태그가 붙여진다.(ex. v1.2.1)
2) develop
- main을 만들기 위한 실제 개발작업은 develop브랜치에서 진행된다.
- 새로운 기능 추가, 부분 수정 등을 통해 커밋들을 수정해나간다.
3) feature
- 굵직한 기능들은 feature 브랜치들을 통해 개발된다. 따라서 하나의 develop 브랜치에 feature는 여러 브랜치로 뻗어나갈 수 있다.
- feature 브랜치에서 만들어진 것은 다시 develop 브랜치로 보낸다.
4) release
- 어느 정도 개발이 완료 되면, 출시 되기 전에 release 브랜치로 보내게 된다.
- 이는 QA팀 등 테스트 하는 사람들을 통해 검증이 이루어지는 곳이다.
- 즉, 앞서 작업한 내용들이 main에 출시되어도 될 정도로 문제가 없는지, 버그 등은 발생하지 않는지를 확인하는 브랜치이다.
- 수정사항들이 발견되면 다시 devleop 브랜치로 보내 수정해나가면서 검증과정이 이루어진다.
- 최종으로 검증이 완료되면, main브랜치로 merge시킨다.
5) hotfix
- 기존에 출시된 버전 중 긴급한 오류 및 버그가 발견되었을 때, hotfix브랜치를 만들어서 이를 해결하고, 다시 main에 병합시킨다.
- merge된 main 브랜치는, 맨 끝의 버전이 올라간다. ex. v1.1.1 => v1.1.2
| * 유의사항 - 아직 공부하고 있는 문과생 코린이가, 정리해서 남겨놓은 정리 및 필기노트입니다. - 정확하지 않거나, 틀린 점이 있을 수 있으니, 유의해서 봐주시면 감사하겠습니다. - 혹시 잘못된 점을 발견하셨다면, 댓글로 친절하게 남겨주시면 감사하겠습니다 :) |
