【Git/GitHub 공동 개발】 알아두고 싶은 컨플릭트 해소와 코드 리뷰의 기본

개요

현재 소속 중인 온라인 살롱 '전직 퀘스트'에서 Rails 앱 공동 개발을 하고 있습니다.

두려워하면서 퍼시리테이터를 맡게 하고 있습니다만, 개발을 진행하는데 있어서 전원의 넥이 되어 있었던 적이 있었습니다.
Git/GitHubの共同開発的な使い方がわからない。。。
그래서 개발을 진행하는 퍼시리테이터로서 Git/GitHubをこうやって使おうぜ！ 이라는 매뉴얼을 준비해 두려고 했습니다.

이 기사에서는 共同開発 初心者さんたちに向けたGit/GitHubのフロー에 대해 소개합니다!

가정 독자

1. アプリの個人開発のためにGit/GitHubを使ったことはある
2. コンフリクト解消のやり方を知りたい！
3. コードレビューのやり方を知りたい！

원래, 어디를 모르겠어요?

Git/GitHubを使って共同開発をする上で、ネックになる部分はどこか。생각하기 위해 지금까지 해온 Git/GitHub의 사용법을 되돌아 보겠습니다.

개인 개발에서 Git/GitHub 사용 방법

1. ローカルのmasterでブランチ切る
2. ブランチで作業しコミット
3. リモートにブランチをプッシュして、プルリク作成
4. GitHub上でひとりLGTMを出して、ブランチをmasterにマージ
5. リモートのmasterをローカルのmasterにプル
6. 1~5を繰り返す

음, このフローでしか開発をしてこなかった人が、共同開発でGit/GitHubを使う際に、初めて経験するのはどんなことでしょうか？
나는 다음과 같이 생각했다.

처음으로 공동 개발을하는 사람이 한 적이 없다는 것

1. 他の人のプルリクに対するコードレビュー
2. リモートのmasterの変更分を、ローカルの作業中ブランチにマージ
3. その際に起きるコンフリクト解消

특히 2, 3에 대해서는, 最新に更新されたmasterからしかブランチを切ったことがない 라고 하는 것이 불안의 이유로서 들 수 있습니다.共同開発では、ブランチのマージによって常にmasterが更新されていきますので、その更新分を自分の作業中ブランチに反映する必要があります。
여기에 초점을 맞추고, 共同開発でのコンフリクト解消、コードレビューの手順を紹介していきます！

충돌 해결의 예

장면 설정

설정

masterから同じタイミングで2つのブランチを切る
  user1.branch1 : git checkout -b new,createアクションを実装
  user2.branch2 : git checkout -b edit,updateアクションを実装

그건 그렇고, 이번에는 「ルーティングの設定」のみを取り扱っていきます 때문에 죄송합니다.

1. [user1] branch1에서 new,create 라우팅 설정

branch1→routes.rb

+ resources :tweets, only: [:new, :create]

2. [user1] 로컬에서 커밋 → 원격으로 브랜치를 푸시

branch1 (new, create 액션 구현)

% git add .
% git commit -m "ルーティングにnew,createを追加"
% git push origin new,createアクションを実装

3. [user1] GitHub에서 풀릭 생성 → LGTM → 병합

여기는 생략합니다.

4. [user2] branch2에서 edit,update 라우팅 설정

branch2→routes.rb

+ resources :tweets, only: [:edit, :update]

5. [user2] branch2에서 커밋

branch2 (edit, update 액션 정의)

% git add .
% git commit -m "ルーティングにedit,updateを追加"

※次にmasterブランチに切り替えますが、その前に必ずここでコミットをしてください！

6. [user2] 리모트 master(branch1 merged)→로컬 master로 끌어오기

# masterブランチに移動
% git checkout master

# リモートのmasterをローカルのmasterに反映
% git pull origin master

【지금은 이런 상태】

master → new, create액션

branch2 → edit, update액션

7. [user2] ⚠ 컨플릭트 로컬 master→branch2에 병합 # 작업 중 브랜치로 이동 % git checkout edit,update 액션 정의 # 로컬 마스터를 작업하는 지점에 병합 % git merge master 【콘플릭트 발생의 모습】 헤드 : 현재 작업중인 분기 (branch2) master : 병합된 로컬 master 브랜치 8-1. [user2] 충돌 해결 master를 기준으로 수정하고, 컨플릭트 해소하면 커밋 # 편집 후 % git add. % git commit (기본 이름 : Merge branch 'master' into edit,update 액션 정의) 기본적으로, master와 작업중 브랜치의 로그를 모두 남겨, 필요한 형태로 바꾸면 그것으로 OK입니다. 커밋하면 디폴트로 이 브랜치가 병합되었어! 라는 커밋 이름입니다. 【※ 컨플릭트 해소 후의 GitHub Desktop의 화면】 ▶commit Merge를 누르면 기본 커밋 이름으로 커밋됩니다. 8-2. [user2] 모르기 때문에 우선 merge를 취소하고 싶다! 만약 「콘플릭트 혼란! 일단 되돌리고 싶다!」라고 하는 분에게는 이쪽. merge 취소 방법 % git merge --abort 【merge 취소의 모습】 ▶ 충돌 상태가 재설정됩니다. 9. [user2] branch2를 원격으로 푸시 → 풀릭 % git push origin edit,update 액션 정의 소괄 : 충돌 해결 로컬 작업 브랜치에서 최신 변경 사항 커밋 누군가가 지점을 병합 한 원격 마스터를 로컬 마스터로 가져옵니다. 브랜치를 전환하고 master를 병합 침착하고 충돌 해결 → 수정하면 커밋 이어서, 코드 리뷰 방법에 대해입니다. branch2 "edit, update 액션 정의"의 풀릭에 대한 코드 리뷰를합시다! 코드 리뷰의 예 1. [리뷰어] 풀릭 URL→File changed 탭 이제 파일의 변경 차이를 확인합니다. 2. [뷰어] 변경 희망 부분을 클릭 (복수 행을 선택도 가능) 고치고 싶은 부분을 선택하고 코멘트를 합니다. 3. [리뷰어] 댓글을 달기→Start a review 선택한 부분에 대한 의견을 기재하십시오. 4. [뷰어] 복수 파일에 코멘트→Finish your review 그 풀릭으로 신경이 쓰인 부분에 코멘트를 남겨두면, Finish your review를 눌러 주세요. conversations로 돌아가면 리뷰가 반영됩니다.

이에 따라 풀릭 요청자는 로컬에서 편집 → push → 재검토 요청

▶이번, 레뷰어 측으로서 「show 액션을 추가해 주세요」라고 코멘트를 해 보았습니다. 이것에 따라 「풀릭 의뢰자 측」에서의 대응을 해 봅시다. 5. [의뢰자측] 로컬에서 편집하여 push routes.rb #show 추가 + resources :tweets, only: [:new, :create, :show, :edit, :update] local-branch2 % git add. % git commit -m "show 액션 추가" % git push origin edit,update 액션 정의 6.[의뢰자측] 수정보고 리뷰에 "show 액션을 추가했습니다!"라고 댓글을 달자. 7. [리뷰어] LGTM→Resolve conversation(리뷰 완료) 파일 변경 확인

OK라면 (댓글을 달고 나면) Resolve conversation

8. 전부 LGTM라면 병합 이상의 흐름을 반복하고 LGTM을 받으면 병합합시다! 9. 로컬 마스터로 끌어 오기 % git checkout master % git pull origin master master의 변경분(merge한 부분)이 다음과 같이 반영됩니다. 소괄 : 코드 리뷰 풀릭의 File Changed에서 변경 차이를 확인 필요에 따라 댓글 댓글에 로컬 브랜치로 작업하고 다시 검토 LGTM이라면 병합 이상이 GitHub flow에 의한 코드 리뷰의 기본 순서입니다. 요약 Git/GitHub를 공동 개발로 사용할 때는 최신 master를 작업 중 브랜치에 병합하는 장면이 온다 변한 부분을 냉정하게 판단하여 충돌을 해소 풀릭의 경우 파일 변경 차이를 확인하고 검토 개인과는 다른 부분이 많아 예를 내고 설명하는데 고생했습니다. 그러나, 이 기회에 배워 보면 Git는 대단하다! 라고 다시 생각했습니다. 계속해서 공동 개발이 원활하게 진행되도록 학습을 진행해 나가고 싶습니다! 참고

Udemy | Git : 더 이상 무서운 Git! 팀 개발에 필요한 Git을 완전 마스터

Qiita | GitHub에서 공동 개발을 위한 자습서

Qiita | Git에서하고 싶은 일, 여기에서 찾을 수 있습니다.