고급 Git과 브랜치 전략 그리고 히스토리 최적화라는 거창한 제목을 가졌지만 그냥저냥 대충 알고 있는 Git과 브랜치 전략에 대해 공유하는 슬라이드입니다.

1. 고급 Git과 브랜치 전략,
그리고 히스토리 최적화
2020.04.25
Speaker :김주석 (@ggaengma)
Sub : 원기태
Follow : 전고은

2. Topic
열심히 개발자로 살아왔지만 귀찮아서 대충 알고 쓰거나 그냥 넘어갔던 "중요한 것"들에 대한 스터디
- Topic : 정규식
Title "언제까지 복사해서 붙여넣을거에요?"
(Speaker:원기태 / Sub:전고은 / Follow:윤명환)
- Topic : SQL
Title "Query plan"
(Speaker:윤명환 / Sub:서승재 / Follow:원기태)
- Topic : AWS
Title "AWS에는 EC2만 있는게 아니라니까"
(Speaker:서승재 / Sub:윤명환 / Follow:김주석)
- Topic : Git
Title "고급 Git과 브랜치 전략, 그리고 히스토리 최적화"
(Speaker:김주석 / Sub:원기태 / Follow:전고은)
- Topic : Shell
Title "효율적인 Shell script와 텍스트 에디팅"
(Speaker:전고은 / Sub:김주석 / Follow:서승재)
오늘 우리는...

3. 아는 것 vs 잘 아는 것 vs 잘 활용하는 것
운전을 하는 방법(technical)을 아는 것 vs 운전을 잘 하는 것(knowhow)
- 보통의 개발자는…
- init, clone, commit, pull, push, merge, add, branch, checkout,...
- ------------------------------------------------------------------------------------------------------
- 좀 더 잘하고 싶은 개발자는…
- fetch, log, revert, cherry-pick, diff, rebase, tag, …
- ------------------------------------------------------------------------------------------------------
- 제대로 활용하는 개발자는…
- git branch 모델

4. 뭣이 중한디?
- 좀 더 고급지게 알면, 그 자체로 의미는 OK
-> 다양한 상황이나 환경에서 문제를 해결할 수 있으니까!
- 근데 운전을 하는 법 <<< 운전을 잘 하는법
- Git을 사용하는 법 <<< Git을 잘 활용 하는 것

5. 필요한 건 시간, 그리고 습관
- branch의 사전적 의미 = (나무 등의)가지
- 가지를 뻗어나가자!
- … 근데 그러다보면 가지가 산만해서 가지치기(rebase)가 필요!
- 어떤 줄기의 기원은 A줄기이고, A줄기의 원래 줄기는 B이고… 결국 뿌리 (root)
는 하나인데..?
- 개발 언어에 framework가 있다면, Git에는 Branch전략(model)!
- 공통 규약이자 신뢰의 약속
- 개발과 배포의 효율성, 그리고 자동화
- 코드리뷰(Online and Offline)가 없다면, 전략도 자동화도 쓸모 아리마생

6. 다짜고짜 고급진 두 가지 전략 - 첫번째
- 첫번째, 배포할 것을 merge (병합해서)해서 배포하기
- 배포 담당자의 역할 감소
- 상대적으로 단순한 모델
- 오랜 전통(?)을 지닌 Branch 전략
- “제외시키고 나가기”에 어려움
- REF. http://hundredin.net/2014/04/06/a-successful-git-branching-model/

7. 다짜고짜 고급진 두 가지 전략 - 첫번째

8. 다짜고짜 고급진 두 가지 전략 - 두번째
- 두번째, 배포할 것을 cherry-pick(당겨다가) 배포하기
- 배포 담당자가 바쁨(배포날은 이것만 한다!…)
- 첫번째 전략보다 상대적으로 복잡
- 현재(아직까지는) Google의 Branch 전략 (그럼 묻따않 채택?!?!?)
- 확실히 배포될 것들로만 이루어지기에 제외시키고 나갈 필요 없음

9. 다짜고짜 고급진 두 가지 전략 - 두번째

10. 코드 리뷰는 어떻게…?
- 아, 개발하기도 바빠 죽겠는데...
- 코드리뷰 = 운동
- 시간이 나면 하는 게 아니라, 시간을 내서 해야하는 것
- 기본은 Online으로 Merge Request, Pull Request
- 너무나도 복잡하거나 너무나도 중요해서 설명이 필요하면, Offline 코드 리뷰
- 공통적인 코딩 컨벤션이 반드시 필요 (시간 낭비 이슈 최소화)
- (걱정마...구글이 있어) https://google.github.io/styleguide/javaguide.html
- 글로벌, 그리고 국내 Top IT기업에서 코드 리뷰를 하지 않는 개발조직은, 단 한
곳도 없음! (찾으면 500원)

11. Github, Bitbucket, Gitlab
- git 그 자체가 아니고 대한 저장소에 대한 서비스
- 대표주자 삼총사. github VS bitbutcket VS gitlab
- 비싸지만 좋고 그 자체가 표준에 가까워(교과서) VS 더 비싸고 더 좋고 사용자
친화적이고 편리하고 연동하기 좋아(전과) VS 싸고 괜찮고 어지간한건 다 있
어(제본)
- 시작은? Gitlab
- 무료 CI/CD 경험! 무료 Hook 경험! Snippet까지! Issue! 무료! 무료! 무료!...
- 근데... 느려… 뻗어…
- 그런 상황이 왔을 때, 유료를 고민해도 늦지 않다!
- Bitbucket의 Lock-in을 감당하기 어려울수도… (feat. JIRA)

12. Gitlab에서의 코드 리뷰

13. Gitlab에서의 코드 리뷰

14. 역사를 잊은 민족에게 미래는 없다
- 역사(history)를 잊은(관리하지 않은) 민족(개발조직)에게 미래(보다 나은 개발
환경)는 없다! 형상관리의 당위성
- Commit은 반드시 기능 단위로! 왜? 그래야 알아보니까
- burning 하다가 commit을 잊었다면?
- 선택(add)하여 commit! (git add -p === git status + git diff + git add)
- 일하는데 갑자기 이거 먼저 해달라는 군주의 부탁?
- 빼뒀다가(stash) commit하고, 꺼내오기(pop)
- 기능까지는 아닌데 commit이 필요하다면?
- 의미가 필요하지 않은 commit history를 정제(rebase)
- 다중 remote 가 필요한 시점? -> 폐쇄된 저장소에서 사용

15. Git stash, pop
- 임시 저장
- 저장은 stash
- 꺼내올 땐 pop

16. merge VS rebase
- 원래 git은 3-way-merge 방식 (나, 너, 그리고 조상)
- 코드가 합쳐지는 과정은 merge이거나 rebase 두 가지
- 정답은 없지만 모든 히스토리 우선? merge. 최적화? rebase
- remote에 push된 commit은 rebase를 하지 않는 것이 관례

17. Git rebase : 과정을 알아야 고오급
git checkout feature git rebase master
head가 master로 변경

18. 백문이 불여일타
- 글씨로 쓰기 힘드니까 말과 노트북으로 떼워보는 시간