[협업] Git 브랜치 전략 선택 이유, 명령어 소개

Git Branch 전략

왜 Branch 전략을 정해야 할까??

혼자서는 그저 main이나 master 브랜치에 머지하는 게 기능 개발에만 집중하기에 편했습니다.

하지만 모두와 함께 개발을 진행해가는데에 있어, 다른 분이 master에 푸시를 했는데 내가 Pull을 안하고 개발을 진행한다면?? 이게 중첩된다면?? 모든 코드를 다시 봐야하고 프로그래밍에 집중하지 못한 채 충돌난 부분만을 들여다봐야 할 것입니다.

즉, master 브랜치에서 작업하는 사람의 수가 늘어남에 따라 병합 충돌 횟수가 늘어납니다.

 

 

 

Github Flow

사용되는 브랜치

- main : 언제든 Stable한 상태여야 한다. 

- topic : main 브랜츠로부터 파생시켜 브랜치 생성

   ex. user-login-jwt, submoudle-init-task, subscribe-movie

- 기능이 완성안됐음에도 꾸준히 push한다. 

  - 구성원 모두가 끊임없이 커뮤니케이션 할 수 있기 위해서

  - 코드의 안정성을 위해 (노트북 분실, 고장, 정전)

Stable 한 : main의 모든 커밋은 언제 배포하든 문제 없어야하고, 언제든 브랜치를 새로 만들어도 문제 없어야 함

 

장점

- branch 구성 전략이 단순하다.

- Github 사이트에서 제공해주는 기능을 모두 사용해 진행하게 도와준다.

- rebase를 통해 커밋 history가 깔끔해 질 수도 있다.

- 작은 브랜치의 변경사항에 대한 잦은 병합/배포를 진행할 수 있다.

 

단점

- 기능적으로 분리된 브랜치를 쓰더라도, 서로 간 충돌이 발생할 우려가 크다,

- 프로젝트 규모가 커지면 같은 브랜치에서 시작했더라도, 머지하는 브랜치가 꼬여서 전체적으로 봤을 때 관리가 어려울 수 있다.

   ex. rebase 시에, 각각의 커밋마다 충돌 처리해줘야 한다 (복잡해지면 거의 포기해야함)

 

 

Git Flow

사용되는 브랜치

- master : 언제든 실제 프로덕트로 출시 될 수 있는 브랜치

- develop : 다음 출시 버전을 개발하는 브랜치

- feature : 각자 기능을 개발하는 브랜치
   ex. feature/[개발할 기능명] 으로 진행해주세요!!

   ex. feature/login 나  feature/subscribe

- release : 이번 출시 버전을 준비하는 브랜치

- hotflix : 출시 버전에서 발생한 버그를 수정하는 브랜치

 

장점

- 명령어를 명료하게 이해할 수 있다.

- 거의 모든 에디터(VSC, Intellij IDE)에 플러그인으로 이미 존재하고 있다.

 

단점

- branch 구조가 복잡해서 관리하기 어려울 수 있다.

- 쓰이지 않거나 애매한 위치의 branch가 생길 수 있다. (ex. release 브랜치?)

- 하루에 몇번이고 릴리즈 되는 웹 어플리케이션 개발에 있어서는 적합하지 않을 수 있다.

 

 

우리에게 맞는 브랜치 전략 선택

위 두 개의 Git branch 전략을 다함께 토론해 본 결과, 아래와 같은 결론이 나왔습니다.

1. 딱딱 분리된 branch로 명확히 역할을 나누는 게 구분하기 편할 거 같다.

2. QA보다 우리 속도에 맞춰서 전체 구현에 중점을 두자.

 

이를 모두 만족하고자 git Flow로 git branch 전략을 선택했습니다.

 

1. 새로운 기능을 추가할 때는 feature 형식에 맞춰서 작성해주세요!

2. 기능을 완료하셨다면 develop 브랜치로 머지해주세요!

3. QA를 위해 release 브랜치를 별도로 생성하기보다는 전체 구현을 위해 바로 master로 머지해주세요! - release 트레이드 오프

 

 

---

Git 명령어 기본 사용법

1. 깃 저장소에 Code 클릭 -> HTTPS 주소 복사 (이게 곧 해당 깃의 주소입니다.)

2. Git clone

git clone [해당 깃의 주소] //기존에 있는 저장소 clone 하기
git clone -b [특정 브랜치 명] --single-branch [해당 깃의 주소] //기존에 있는 저장소의 특정 브랜치만 clone 하기

ls //현재 파일명 나열하기
cd [해당 repository 이름] //클론한 프로젝트로 디렉토리로 이동하기

 

3. 브랜치 생성

git branch //브랜치 조회

git checkout [브랜치 명] //해당 브랜치로 이동

git checkout -b [작업할 브랜치 명] //브랜치 생성&이동

 

해당 브랜치 내용 가져오기

git pull origin [브랜치 명]

 

해당 브랜치 커밋하기

git commit -m "커밋 내용" 
커밋 내용 예시 -> "feat: 로그인 기능 완료", "hotfix: 로그인 기능 버그 수정"

 

해당 브랜치 내용 푸시하기

git push origin [브랜치 명]

 

브랜치 병합

git merge [브랜치 명]
or
git rebase [브랜치 명]  // 같은 base 브랜치를 둔 서로 다른 브랜치에서 한 브랜치의 base를 다시 설정

 

기타 자주 쓰이는 명령어

git status // 현재 상태 확인
git log // 커밋된 로그 확인
git init // git 저장소 생성

 

 

마무리

- 이외에도, gitlab flow나 Trunk-based Development 등 전략이 존재하지만 현재는 협업에 있어 가장 많이 사용되는 것을 투입함으로써 '개발을 시작'함에 초점을 맞추고 싶기 때문에 이에 대해서는 다루지 못했습니다. 향후 기회가 된다면 다루어보고 싶네요..

 

실제 사용 예시

정윤수@DESKTOP-6MG09PT MINGW64 ~ (master)
$ git clone https://github.com/dbstn1325/hongflix.git
Cloning into 'hongflix'...
remote: Enumerating objects: 752, done.
remote: Counting objects: 100% (752/752), done.
remote: Compressing objects: 100% (596/596), done.
remote: Total 752 (delta 153), reused 696 (delta 125), pack-reused 0
Receiving objects: 100% (752/752), 12.49 MiB | 8.93 MiB/s, done.
Resolving deltas: 100% (153/153), done.

정윤수@DESKTOP-6MG09PT MINGW64 ~ (master)
$ ls
'3D Objects'/
 AppData/
'Application Data'@
 Contacts/
 Cookies@
 Desktop/
 Documents/
 Downloads/
 eclipse-workspace/
 Favorites/
 IntelGraphicsProfiles/
'Internet Explorer.lnk'*
 Links/
'Local Settings'@
 Music/
'My Documents'@
 NetHood@
 NTUSER.DAT
 ntuser.dat.LOG1
 ntuser.dat.LOG2
 NTUSER.DAT{53b39e88-18c4-11ea-a811-000d3aa4692b}.TM.blf
 NTUSER.DAT{53b39e88-18c4-11ea-a811-000d3aa4692b}.TMContainer00000000000000000001.regtrans-ms
 NTUSER.DAT{53b39e88-18c4-11ea-a811-000d3aa4692b}.TMContainer00000000000000000002.regtrans-ms
 ntuser.ini
 OneDrive/
 Pictures/
 Postman/
 PrintHood@
 react/
 Recent@
'Saved Games'/
 Searches/
 SendTo@
 source/
 Templates@
 test.py
 test1/
 Videos/
 wetube-reloaded/
hongflix/
'내 PC - 바로 가기 (2).lnk'*
'내 PC - 바로 가기.lnk'*
'네트워크 - 바로 가기.lnk'*
'시작 메뉴'@
 파이썬/
'휴지통 - 바로 가기.lnk'*

정윤수@DESKTOP-6MG09PT MINGW64 ~ (master)
$ cd hongflix/

정윤수@DESKTOP-6MG09PT MINGW64 ~/hongflix (main)
$ ls
frontend/  README.md  backend/

정윤수@DESKTOP-6MG09PT MINGW64 ~/hongflix (main)
$ git branch
* main

정윤수@DESKTOP-6MG09PT MINGW64 ~/hongflix (main)
$ git checkout yoon
Switched to a new branch 'yoon'
branch 'yoon' set up to track 'origin/yoon'.

정윤수@DESKTOP-6MG09PT MINGW64 ~/hongflix (yoon)
$ ls
frontend/  README.md  backend/

정윤수@DESKTOP-6MG09PT MINGW64 ~/hongflix (yoon)
$ code .

정윤수@DESKTOP-6MG09PT MINGW64 ~/hongflix (yoon)
$ git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.

정윤수@DESKTOP-6MG09PT MINGW64 ~/hongflix (main)
$ code .

정윤수@DESKTOP-6MG09PT MINGW64 ~/hongflix (main)
$ git checkout develop
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.

 

 

Reference

https://www.gitkraken.com/learn/git/git-flow

https://medium.com/hackernoon/git-merge-vs-rebase-whats-the-diff-76413c117333

https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/

https://www.youtube.com/watch?v=etnFe2tBD5I 

https://githubflow.github.io/