# 더 나은 Git 워크플로우를 향해서

> Clean Markdown view of GeekNews topic #9110. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=9110](https://news.hada.io/topic?id=9110)
- GeekNews Markdown: [https://news.hada.io/topic/9110.md](https://news.hada.io/topic/9110.md)
- Type: news
- Author: [alstjr7375](https://news.hada.io/@alstjr7375)
- Published: 2023-05-04T17:32:55+09:00
- Updated: 2023-05-04T17:32:55+09:00
- Original source: [black7375.tistory.com](https://black7375.tistory.com/92)
- Points: 29
- Comments: 0

## Topic Body

깃을 보다 효율적으로 활용하기 위한 방법을 모아보았습니다.  
  
0. 레포구조  
   - Git은 분산 버전 관리 시스템이라 중앙집중형, 깃허브/깃랩 방식, 계층형등 다양한 방식으로 구성 가능  
1. 브랜치 구조  
   - 깃허브 플로우: Main을 두고 기능이나 버그 브랜치를 생성 후, 피드백을 받아 병합하는 형태  
   - 깃 플로우: 잦은 배포보다는 전통적인 개발에 유리  
     - Feature 브랜치를 만들어 Develop 브랜치에 병합  
     - 충분히 성숙한 Develop 브랜치는 Release(Stage) 브랜치를 만들며, 버그 수정만 하며 추후 Develp과 Master에 합침  
     - Release 준비가 되면 Master 브랜치에 병합하고, 핫픽스만  
   - 깃랩 플로우: 복잡한 깃 플로우와 너무 단순한 깃허브 플로우의 중간형태  
     - 깃 플로우에서 잠시 유지하는 Relseae 브랜치 대신, 쭉 유지하는 Stage 브랜치 사용  
     - 핫픽스는 Production과 Stage에, 버그 수정은 Stage와 Devlop에 반영  
   - Perforce Stream: 여러 릴리즈를 관리해야 할 때 유리  
     - Release에서 버그를 고치면 Main-Develop으로 전파  
     - Develop에서 기능을 만들면 충돌을 없애고 Main에 반영  
   - Trunk 기반: Main(Master)를 보다 효율적으로 쓰려는 시도로 빅테크들이 주로 사용  
     - Main을 오래 유지하며, 릴리즈 브랜치에서는 따로 버그 수정을 하지 않음  
     - 기능은 플래그를 사용해 Off 상태로 병합해 항상 최신 코드 유지  
2. 커밋  
   - 컨벤션: 보통 Angluar 컨벤션을 많이 사용하나 협의를 통해 이모지 등을 사용할 수도 있음  
   - 단위: 최소 단위별로 해야 하지만 역시, 팀별로 최소단위에 대한 협의가 필요  
     - Hunk로 변경사항을 세분화해 스테이징 가능  
     - Delta단위로 변경 사항을 비교할 수 있다면 편함  
   - 투기적 커밋과 선형적 기록: 커밋을 자주해 컨텍스트는 유지하면서도 커밋기록을 선형적으로 유지하는 방법  
     - Stash나 프로토 타입 시도등 작업 저장이 필요할 때마다 저장  
     - Checkout이 필요한 곳마다 Checkout하고 계속 커밋 후 rebase를 통해 선형적으로 유지함  
     - [git-branchless](https://news.hada.io/topic?id=6970)라는 툴을 사용하면 편함  
     - `git sl`: 익명 분기를 추적하여 커밋기록을 잘 시각화 해줌  
     - `git prev`와 `git next`: 전/후 단위로 체크아웃하기 쉬움  
     - `git sync`: Main으로 리베이스  
     - `git move`: 원하는 곳으로 커밋을 옮길 수 있음  
     - `git restack`: `rebase`나 `commit --amend`등으로 커밋 기록 순서가 깨지면 복원  
     - `git undo`: 취소 가능  
3. 병합  
   - 패치 스택(Patch Stack): 기능[1/3], 기능[2/3], 기능[3/3]과 같이 쪼개서 리뷰하는 방식  
   - 일급 충돌: 깃과 호환되는 [Jujutsu](https://news.hada.io/topic?id=6018)는 충돌을 커밋에 기록하여 한번 해결된 충돌이 나중에 일어나는 일이 적음  
   - 3 Way Diff: Jujusu의 경우 충돌이 발생시 Base-Ours를 Diff로, Theirs는 스냅샷으로 보여줘 직관적. 그러나 IDE/에디터 문법강조나 Base-Their Diff를 보고 싶은 니즈가 있을 수 있음  
   - 바이너리 충돌: 깃은 바이너리 파일이 충돌 발생하면 알아서 하라고 방치하지만, 개인적으로 간단한 툴을 만들어 Base와 Their의 파일을 생성하도록 함  
   - 패치와 메일: 보다 전통적인(?) 병합 방식에 대한 소개  
     - `git request-pull`은 풀리퀘스트를 생성하는 명령어  
     - `git send-mail`로 패치를 메일로 전송, `git am`으로 패치 적용이 가능  
4. 기타 관리 방법  
   - Worktree: Git history는 공유된채로 SVN 브랜치처럼 작업파일만 여러곳에 체크아웃하여 작업들을 통시에 진행가능  
   - Git LFS: 대용량 파일을 관리하는 방법  
   - 부분 복제와 부분 체크아웃: 부분적으로 clone하여 다운로드 시간을 줄이고, 부분적으로 checkout하여 원하는 디렉토리만 작업 가능  
   - 스칼라: 마이크로소프트의 노력으로 거대한 레포지토리를 쉽게 관리하도록 만들어줌

## Comments



_No public comments on this page._