[git] Github 팀 개발 메뉴얼

※ 이 포스트는 일본의 한 블로그 글을 번역한 것입니다. 의역 및 오역, 직역이 있을 수 있으며 틀린 내용있으면 지적해주시면 감사하겠습니다.

 

 이 포스트는 누구라도 헤매지 않고 팀 개발에 참가할 수 있도록 팀 개발의 흐름을 매뉴얼로 만들기 위해 작성했다. 복잡한 사용법은 전혀 없다. 

 

개발의 흐름

---

 Github에서 관리하는 리포지토리에서는 아래의 흐름으로 코드를 갱신한다.

• 먼저 master 브랜치에서 시작하기
  • 로컬 리포지토리에 master 브랜치를 넣기
  • 리모트 리포지토리에 master 브랜치의 갱신이 있는지 확인하기
• feature 브랜치로 개발하기
  • feature 브랜치로 변경하기
  • 개발하기
  • 변경점을 로컬 리포지토리에 commit하기
• 리뷰
  • 리모트 리포지토리에 push하기
  • Pull Request 보내기
  • PR으로 리뷰하기, 리뷰받기
• 마지막으로 master 브랜치에 merge하기
  • PR 리뷰가 끝나면, master 브랜치에 merge하기

 아래에서 각 순서마다 설명하도록 하겠다.

 

 

master 브랜치에서 시작하기

---

 master 브랜치에는 신뢰할 수 있는 코드나 문서가 정리되어 있다. 무언가를 할 때도 master 브랜치가 기본이며, 신뢰할 수 없는 코드나 문서를 master에 넣으면 안 된다.

 

로컬 리포지토리에 master 브랜치를 넣기

git checkout master

 해야할 일은 이뿐이다. 단순하지만, 제대로 PR등록하거나 충돌을 피하기 위해 필수이다. 우선, 코드를 수정하게 됐다면, 반드시 한 번은 master에 돌아가서 브랜치를 만들어오는 습관을 만들어두자.

 이 한 행을 잊어버려 이상한 브랜치에서 개발을하면 커밋 이력이 복잡해진다. git pull도 git diff도 쓸 수 없게 된다. 충돌을 고치다가 하루가 저무는 슬픈 일이 발생할 수 있으므로, 잊어버리지 말기를 바란다.

 PR상의 Files changed가 많은 경우는 master에 돌아가는 것은 잊어버린 가능성이 크다. 그렇지 않은 경우는 하나의 브랜치에 작업을 너무 많이 했기 때문이다. 어쨌든, 커밋 이력이 복잡하면 코드를 읽는 쪽이 피곤해지므로 주의하자.

 한편으로 이상한 쪽으로 변경하여 master에 돌아갈 수 없는 경우도 있다. master에 돌아갈 수 없는 경우에는 git stash로 작업을 대피시킨 후 한 번 더 git checkout master하자.

 

리포지토리에 master 브랜치의 변경이 있는지 확인하지

git pull

 팀 개발을 하고 있다면 자기가 맡은 바가 아닌 곳에서 master 브랜치가 갱신되고 있는 경우가 있다. 그 때에는 이전의 master 브랜치에서 feature 브랜치를 만들면 충돌이 일어날 수 있으므로 갱신을 확인할 필요가 있다. git checkout master과 합쳐서 습관화해두길 바란다.

 한편, 브랜치를 만든 후에 master가 갱신된 경우가 있다. 그 때에는 git rebase하여 최신의 master와 feature브랜치를 일체화하자.

 

 

feature 브랜치로 개발

---

 master 브랜치에서는 어떠한 코드의 추가나 변경을 하지 않도록 하자. 1행이라도 어떠한 코드를 작성하고자 한다면, feature 브랜치이라는 개발용 브랜치에서 쓰자.

 

feature 브랜치 생성하기

git checkout -b feature/new-branch

이 커맨드로 아래의 두 가지 동작이 실행된다.

• feature/new-branch 브랜치를 생성
• feature/new-branch 브랜치로 이동

master 브랜치에서 자동적으로 이동시켜주므로, git branch를 실행하여 확인해보자. 또한 feature 브랜치를 만들 때에는 이름을 feature/XXX 으로 하자. 브랜치의 명명법에는 다른 해설이 있을지 모르겠지만, 팀내에서는 이 규약을 따르길 바란다.

 

개발하기

feature 브랜치의 변경 내용은 master 브랜치에 반영되지 않는다. 어떠한 버그가 있는 코드를 작성해도 master 브랜치에 있는 파일은 영향을 받지 않는다. 실수로 대규모의 코드나 파일을 삭제해버려 스크립트가 동작하지 않거나해도 master 브랜치에는 정상적으로 동작하는 파일이 남아있다.

 실수했다고 생각하면 한 번 master 브랜치에 돌아가서 feature 브랜치를 새로 만들면 된다. 따라서 아이디어를 마음껏 코드로 써라.

 

변경점을 로컬 리포지토리에 커밋하기

git add test
git commit -m "[add] #1 신규모델로submission"

 추가 혹은 변경한 파일을 git add로 지정하여, 그 후에 git commit으로 변경을 저장한다. 커밋 메시지의 포맷은 [커밋 종류] #대응할 PR 번호 개요로 하길 바란다. 커밋 종류는 아래와 같이 네 종류가 있다.

• fix
• add
• update
• remove

 그리고 __pycache__나 *.ipynb와 같은 git 관리를 방해하는 파일을 git add의 대상에 포함하지 않도록 하자. 그 방법은 gitignore을 쓰는 것인데 자세한 내용은 다음에 다루도록 하겠다.

 

 

리뷰

---

 팀 개발에 중요한 것이 멤버 서로 리뷰하는 것이다. 어느정도 상세하게 리뷰할지는 경우에 따라 다르지만, 제대로 리뷰하고 리뷰를 거친 코드만 master 브랜치에 merge 되도록 하자.

 

리모트 리포지토리에 push하기

git push origin feature/new-branch

 Github의 리모트 리포지토리에 로컬 리포지토리의 변경을 반영시킨다. 이것으로 PR을 내거나, 다른 사람이 당신이 갱신한 코드를 볼 수 있게 된다.

 master 브랜치에 push하지 않도록 주의하자. git push -f origin master은 절대로 사용하지 않도록하자.

 

Pull Request 보내기

 Github상의 리포지토리 페이지로 이동한다. 그러면 push한 브랜치의 Pull Request(PR)을 낼 수 있게 된다. 화면 오른쪽의 [Compare & pull request]를 누르자.

 그러면 PR를 작성하는 화면으로 이동한다. 아래의 순서로 편집, 작성하자.

1) Reviewer 지정하기

2) 타이틀을 [브랜치] 개요로 하기

3) 최소한의 개요와 merge를 받을 조건 쓰기

4) [Create pull request]를 누르기

 

Pull Request로 리뷰하기, 리뷰받기

Pull request 태그를 열면, 아까 적었던 PR이 등록되어 있다.

 PR에서는 [Files changed]를 누르면, 파일의 변경점을 볼 수 있는 화면으로 이동하게 된다. 각 행에 마우스 커서를 올리면 "+" 버튼이 나오므로 리뷰하고 싶은 곳을 클릭한다.

 리뷰를 쓰고, [Start a review] 를 클릭한다. 이 상태에서는 리뷰는 아직 보류상태이다. 보류되어 있는 동안 다른 행도 리뷰하고 싶은 곳이 있다면 동일한 방법으로 리뷰를 한다.

 [Finish your review] 를 누르면, 보류중의 리뷰를 해결하는 화면이 나온다. 여기에 총괄적인 코멘트를 작성하면, RP의 [Conversation] 태그 쪽에 반영되므로 필요에 따라 작성하자. 특히 그냥 merge 해도 좋다고 판단될 경우는 "+1"를 코멘트에 작성해 라디오 버튼에서 [Approve]를 선택하면 된다. 

 마지막으로 [Submit review]를 누르면, 지금까지 작성한 리뷰가 등록된다.

 

 

 

마지막으로 master 브랜치에 merge하기

---

 PR의 [Conversation] 태그를 열어 가장 맨 아래의 [Squash and merge] 를 클릭하라. [Squash and merge]가 없는 경우는 아래쪽으로 향한 화살표 아이콘을 눌러 풀 다운 메뉴에서 선택하면 된다.

 이것으로 master브랜치에 당신이 작성한 코드가 반영된다.

---

참고자료

https://qiita.com/siida36/items/880d92559af9bd245c34