Define the problem first
Gerrit을 이해하는데 필요한 내용을 Github 사용자들에게 알기 쉽게 설명해보자.
Git 전략 - Flow, Branch, Commit 관리 - 는 다 다를 수 있음을 유의할 것.
Github을 이용하는 흔한 Workflow를 생각해보자. Local Machine에서 새로운 작업 브랜치를 만들고 해당 브랜치에서 작업을 한다. 그리고 의미 단위로 보통 commit을 한다. 그리고나서 push하고 Pull Request를 생성해서 리뷰를 받고 master branch에 Merge가 된다. 제일 많은 상황에서의 워크플로우이다. 즉, Github에서는 Branch의 변경사항 전체를 ChangeList라고 고려해서 Review를 한다.
Branch 생성 및 Checkout
git branch <branch-name>
git checkout <branch-name>
Unstage -> Stage Files
git add .
Commit
git commit -m "commit message"
Remote 저장소로 Push
git push
위처럼 작업하면 대부분의 상황에서는 물 흐르듯이 흘러갈 것이다. Conflicts나 rebase/pull 하는 것도 종종 발생하니 이것은 뒷부분에 부록으로 다루어보자.
Gerrit과 Github에서의 Workflow의 가장 큰 차이는 ChangeList, 즉 Review의 Unit(단위)가 Pull Request가 아니라 Commit이라는 점이다. 즉, Commit 단위로 리뷰를 한다는 것이다! 이렇게 되면 commit 메시지나 commit 단위를 잘 쪼개는게 중요하다. 그러다보니 git commit --amend를 자주 사용하게 된다.
하나의 브랜치에 리뷰 단위가 Commit 단위로 쪼개지면서 리뷰를 받을 수 있는 것이다. 이는 ChangeList가 작아지게 되고 그에 따른 이득은 구글 코드 리뷰에서 많이 나오니 생략한다.
Commit 전까지의 플로우는 거의 같다.
amend tag를 더 자주 사용하게 된다.
git commit --amend
Review 요청
git rewiew
구글 코드 리뷰 문서를 보면서 ChangeList에 대한 내용이 아주 상세히 다루어질 때마다 Pull Request를 매번 작게 만드는게 중요하지만 번거로운 일이라고 생각을 했었는데, 더 작은 단위로 할 수 있는 도구들을 구글에서는 사용하고 있다보니 이번에 더 잘 이해하게 된 것 같다.
Discuss this post here.
Published: 2023-04-08