-
기본 (이것을 하나하나 그림으로 표현하면 익히기 좋을 것 같음)
- git fetch (git 원격의 변경정보들을 가져오기, 소스에 반영되지는 않음. 확인용?)
- git pull (현재 브런치의 원격 브런치 수정정보들을 로컬 브런치로 가져오기)
- git commit -m ‘message content’ (현재 브런치에서 작업 내용을 커밋으로 로컬 브런치에 반영)
- git push (현재 로컬 브런치에 커밋된 내용들을 원격 브런치로 밀어넣기)
- git merge [source branch] (현재 브런치에 소스 브런치의 내용을 병합하기, 충돌 시 충돌해결-심화)
- git branch [branch name] (브런치 생성하기)
- git checkout [target branch] (해당 타켓 브런치로 체크아웃, 단 현재 브런치에 변경 건이 있으면 타켓으로 안감.. try!)
-
심화
- git conflict (충돌 시 해결) a를 b로 머지 할 지, b를 a로 머지 할 지, 각각 수동 반영 할 지 선택
- git revert
- git reset
- git cherry-pick
- git rebase
- git 커밋 수정 및 지우기 특정버전으로 돌아가기 등..
-
업무환경에서 git branch 전략
- 최초 브런치는 master 브런치
- 개발용 develop 브런치를 master 브런치에서 가지침.
- 개발자들은 각 업무별 feature branch를 develop에서 가지 쳐서 생성
- 로컬의 feature branch에서 개발을 진행
- 개발이 완료된 경우 feature branch 에서 develop 브런치로 merge(병합) 요청
- merge 요청은 MR(Merge Request) 이라고 하기도 하고, PR(Pull Request) 라고도 한다.
- 저번에 업무중 누가 계속 PR PR 이러길래 무슨소린지 몰랐다. 내가 MR MR 이라고 하니 거기서도 MR이 무슨말인 줄 몰랐다. 나는 PR을 몰랐고, 상대방은 MR을 몰라서 ㅋㅋㅋㅋ 동일한 작업을 다른 작업인 줄 알았던 이야기!
- 개발자들은 merge 요청을 코드 리뷰 및 코멘트 작성
- 리뷰가 완료되면 승인자가 승인하고, 코드를 머지
- develop 브런치에서 베타 테스트를 진행한다.
- 배포 시점에는 develop 브런치를 release 브런치로 생성한다.
- release 브런치에 이상이 없다면! (이때도 테스트) master로 merge 한다.
- CI/CD 가 master 를 감지하고 있다면, 자동으로 소스가 반영되고 운영환경에 적용된다. (devops 영역?)
- 이런, 운영환경에 배포 했는데 긴급한 이슈가 발생했다.
- 이때 master 브런치에서 hotfixes 브런치를 생성하고, 수정을 진행한다. 긴급하니 즉시 master로 배포 한다.
- 이후에 hotfixes 브런치를 develop 브런치로 머지 한다.
