[250228] Git 전략과 협업 방법

Git 전략

Git의 꽃은 ‘협업’이라고 봐도 무방하다.

물론 포트폴리오처럼 나의 프로젝트들을 관리하는 용도로 사용할 수 있지만 Git을 사용하는 가장 주목적은 ‘협업’에 있다고 해도 무방하다.

그만큼 협업을 하기에 유용한 기능들이 많이 있다.

가장 많이 쓰는 방법이 branch를 활용하는 건데, 이를 깔끔하게 만들도록 도와주는 방법론이 많다.

뭐가 좋은데 ?

1. 브랜치 관리가 쉬워진다
2. 팀원이 아무리 많아도 개발 절차가 매끄러워진다

Git 전략의 종류 1. Git Flow

보통 대규모 개발에서 ‘안정적인 배포’를 해야할 때 사용하는 전략

main : 유저에게 배포할 버전

hotfilx : main에서 급하게 업데이트 할 내용이 있을 때 (버그)

release : 실제로 업데이트 하기 전 베타 버전

develop : 개발자가 작업하는 공간 (release에서 생기는 버그 수정)

feature branches : R&R(역할 분배) 개발자별로 개발하는 공간

Git flow의 장점

브랜치별 역할이 정해져 있다

배포하기 전 release에서 베타 테스트와 수정 후 배포하기 때문에 안정적으로 버전별 배포가 가능하다

그렇다면 언제 써야 할까?

• 우리가 만드는 프로그램이 항상 안정적으로 배포해야할 때 (이미 배포돼서 사용자가 많은 경우)
• 버전 별로 차곡차곡 배포해야 할 때 (게임 개발 등)

꿀팁

아직 그래도 현업 개발자까지는 아니므로, 여기서 좋다고 생각되는 브랜치를 몇 개 골라서 써도 된다

변형에 이유만 있으면 된다 (개발자는 항상 왜가 중요하다)

Trunk-based

브랜치 하나만 잘 관리하는 전략이다.

1. 기능 추가, 버그 수정이 필요하면 main 브랜치에서 새로운 브랜치를 하나 만들어서 코드를 짠다
2. → 이때 브랜치명을 잘 지어야 한다.
3. 기능이 완성되면 main 브랜치에 합친다
4. 합치고 나서 쓸모없는 브랜치는 삭제한다
5. main브랜치에 있는 코드를 필요할 때마다 유저들에게 배포한다

Trunk-based의 장점

코드를 한 브랜치에서만 관리하기 때문에 편리하다

크게 개발해서 한 번에 merge하는 것보다 작은 단위로 merge 하는 것이 더 안전한다

하지만, main 으로 바로 합치므로 테스트나 코드 리뷰를 자주 해야 한다

그렇다면 언제 써야할까?

• 우리가 만든 코드를 바로 유저에게 배포해도 상관 없을 때
• 크게 대격변의 업데이트를 안하는 안정적인 프로그램일 때

정리

• 어느 정도 개발이 진행되었거나 코딩 천재들만 있는 팀이라면 → trunk-based 훨씬 편리
• 출시된 버전의 안전성이 중요한 프로그램들, 아직 뼈대가 확실하지 않아 연구식, 실험식으로 개발하는 프로그램들
• → git flow 가 적절할 수 있음

(이것도 정답은 아님, 각 전략을 선택하는 이유만 있으면 됨)

Git 협업 방법 알아보기

git clone

원격 저장소에 있는 프로젝트를 내 로컬 저장소에 그대로 복제해 오는 것

git clone으로 복제하고, pull + push 하기

1. git-practice-collabo레포를 만들어서 clone한다
2. 각자 본인의 브랜치를 만들어서 add → commit → push
3. main에 push하지 않도록 조심한다.
4. 다른 팀원이 해당 브랜치에서 내용을 수정한다
5. 여기서 본인도 다시 수정사항을 만들고 add → commit 하면 에러가 난다

이때, git pull origin 본인브랜치 하면 다른 팀원의 수정사항을 가져오고, 나의 수정사항을 push할 수 있다

💡git pull vs git fetch
git pull = git fetch + git merge
git fetch : 원격 저장소에 있는 커밋 중에 로컬에 없는 신규 커밋을 가져와라
git merge : 가져온 걸 병합해라

그래서 다른 팀원과 같은 파일을 건드리면 git pull 했을 때 merge conflict 날 수 있어요. 그럴 땐 그냥 충돌 해결하시고 add → commit 해주시면 됩니다.

제일 중요한 거) push 하기 전에 습관적으로 pull 해보자