[Git] GitHub으로 협업하기 _ 실습

1. 실습 상황 

팀장, 팀원1, 팀원 2가 협업을 통해서 소스코드를 작성하는 상황! 

 

2. 실습에 필요한 것. 

팀장, 팀원1, 팀원 2는 컴퓨터에 git과 git flow가 설치되어있고, GitHub 아이디를 가지고 있어야 한다. 

(팀장과 팀원의 일이 섞여서 나올 수 있으므로 색을 구분하겠다!) 

 

3. 실습시작! 

1. 팀장은 GitHub에서 새로운 리포지토리를 판다.  

 

2. 팀장은 본인의 로컬 저장소에 새로운 리포지토리를 클론 해 온다 

$ git clone{깃 리포지토리URL}
$ cd {클론한 리포지토리 이름}

 

3. git flow를 시작한다.

( 링크를 참조하거나 이전 글을 보면 git flow를 더 자세하게 알 수 있다. )

$ git flow init
//엔터 엔터!! 

$ git branch //*develop

한 줄 한 줄 뜨는 것은 그냥 다 엔터를 쳐서 넘어가 준다. 그러면 자동으로 branch 가 develop으로 바뀌어 있다. 

 

4. develop 브런치에서 작업할 파일을 생성한다. 

// 작업할 파일 생성하기
$ touch fizzbuzz.py

// git에 add, commit하기 
$ git status
$ git add fizzbuzz.py
$ git commit // commit 메시지는 feat: Create fizzbuzz.py 정도로 작성한다.

 

5. 팀장은 자신의 원격 저장소(Github)에 fizzbuzz.py를 push 한다. 

$ git status // commit 상태 확인하기 
$ git push -u origin develop // 원격 저장소에 devolop 브런치가 없는 상태이므로 -u를 붙여서 push해준다!
// 원격저장소에 develop 브런치가 생성이 되고 fizzbuzz.py가 올라간다!

이후 팀원들에게 리포지토리를 fork 하라고 한다. 

 

6. 팀원1과 팀원 2는 팀장의 리포지토리를 Github에서 fork 받는다. 

팀장의 github 리포지토리에서 fork를 클릭한다.

이슈를 생성한 뒤 팀원은 팀장의 리포지토리에 가서 fork를 클릭한다. 

fork해온 팀원의 리포지토리!

그러면 다음 화면처럼 팀원 1과 팀원 2는 자신이 권한을 가진 자신의 리포지토리를 만들게 된다.

 

7. 팀원1과 팀원2는 먼저 팀장의 리포지토리에서 새로운 Issues를 생성한다.

팀장의 리포지토리에서 새로운 이슈 만들기!

 새로운 Issues에 자신이 어떤 일을 할 것인지 쓴다.  (우리는 연습이라서 간단하게 작성했기 때문에 자세한 작성방법은 구글에 'git issue 작성법'이라고 검색&참고하기 바란다.) 

팀원이 issue를 생성하는 모습

팀원은 Issue를 생성할 때 오른쪽에 Assignees(책임자)등을 설정할 수 있는 권한이 없지만 팀장은 이슈가 생성되면 설정할 수 있으니 설정한다. 

 

8. 팀장은 Issuse를 확인한 뒤 해당 이슈의 책임자와 이슈의 종류 등을 지정한다. 

우리는 issues의 Assingnees(이슈의 책임자)는 팀장으로 지정하고 Labels는 enhancement로 설정했다.

issue의 labels의 뜻은 다음과 같다. 

• bug 예기치 않은 문제 또는 의도하지 않은 동작(버그), 수정 시 close
• duplicate 해당이슈 또는 PR이 기존에 있음, 원본에 링크를 남기고 close.
• enhancement 새로운 기능 요청 구현 시 close.
• help wanted 관리자가 문제 또는 PR 요청에 대한 도움 요청 해결 시 close.
• invalid 이슈 또는 PR 요청이 더 이상 관련이 없음.(실현 불가능). 안 되는 이유를 쓰고 close.
• question 이슈 또는 풀 요청에 추가 정보가 필요함. 해결 or 납득 시 close.
• wontfix 문제 나 PR 요청에서 작업이 계속되지 않음. 이유를 쓰고 close.
• documentation 문서를 개선하거나 추가할 필요가 있음

 

9. 팀원 1과 팀원 2는 fork 된 리포지토리의 URL을 가져와서 로컬 저장소에 clone을 한다. 

$ git clone {팀장의 리포지토리를 fork한 자신의 리포지토리 URL}

$ cd {clone한 리포지토리}

//git flow를 시작한다!
$ git flow init
//계속 엔터! 기본 설정대로 넘어가면 된다

//자동으로 develop 브런치로 가있다. 
$ git branch 

//팀장의 리포에서 가져온 개발중인 파일이 있는지 확인한다. 
$ ls //fizzbuzz.py가 있다.

 

10. 팀원 1과 팀원 2는 feature브런치를 생성하고 각자 fizzbuzz.py에 자신이 맡은 부분을 개발한다. 

//feature 개발 시작하기 
$ git flow feature start {fizzbuzz: 기능이름}

$ vi fizzbuzz // vim으로 파일 편집 
// i를 눌러 편집을 하고 작업이 끝나면 'esc' + ':wq'를 입력해서 저장 및 종료를 한다.

 

11. 팀원 1과 팀원 2는 개발이 끝나면 기능 개발을 닫고 개인의 원격 저장소에 push 한다 

$ git status // 파일의 상태를 확인한다 
$ git add fizzbuzz.py
$ git commit  // commit 메시지는 feat: Add fizz  등 자신이 개발한 내용을 적는다.

// 기능 개발을 완료한다. 
$ git flow feature finish fizzbuzz//기능 개발 브런치를 닫고 develop 브런치에 merge를 하는 과정이다!
$ git push -u origin develop // 자신의 원격 저장소에 push를 해준다.

 

12. 먼저 개발을 끝낸 팀원 1은 이제 compare& pull request를 한다.  

팀원 1의 원격 저장소에 생긴 compare& pull request 버튼!

팀원 1이 먼저 일을 완료하여 push를 한 상황이라고 친다. 팀원1이 push를 하고 자신의 원격 저장소에 가면 compare& pull request 버튼이 생긴 것을 볼 수 있다. 

12-1. compare& pull request 버튼을 클릭한다. 

팀원 1이 pull request를 생성하는 모습

12-2. 팀원1 리포지토리의 develop 브런치에서 팀장 리포지토리의 develop 브런치로 pull 하는지 확인한다. 

12-3. 이후 빨간색으로 표시된 부분을 눌러서 해결한 이슈를 참조하거나 '-#'을 입력해서 이슈를 자동 완성시켜 참조한 뒤 pull request 메시지를 작성한다. 

12-4. Create pull request를 눌러 pull request를 생성한다. 

팀원 1은 이제 팀장의 결정을 기다린다.

 

13. 팀장은 pull request를 받으면 상황에 따라 pull request를 다음과 같이 처리한다. 

• Conversation
  • Reviewers: 본인
  • Assingees: 본인 + 팀원
  • Lable: enhancement

• Files changed
  • +버튼을 눌러 코멘트 달기
    ex) It's not pythonic. Do fizzbuzz with 1 if statements
• Finish your review를 클릭
  • Write 작성
    ex) Do tihs RIGHT AWAY!!!!
  • 해당하는 라벨 클릭
    
    • comment: 단순한 조언
    • Approve: 승인
    • Request Changes: 요청사항이 있는 경우 
  • Submit

 

 

14. 만약 팀원 1이 요청사항을 받았다면 다음과 같이 처리한다. 

14-1 코멘트에 대한 답글을 작성한다. 기술적인 소통은 github에서 진행하는 것이 좋다. 

14-2. 현재 팀원 1의 qull request가 열려있는 상태이면 팀원 1이 파일 변경한 뒤 자신의 develop 브런치에 push를 하면 해당 pull request에 바로바로 반영이 된다.

쌓이는 pull

따라서 팀장은 해당 qull request가 해결되었다면 open을 close로 바로바로 닫아주는 것이 좋다.

팀장이 pull request 닫기

pull request가 닫힌 모습!

14-3. 팀원 1은 요청사항이 n개인 경우 n개를 각각 따로 commit 한 뒤 develop에 push 한다. 

14-4. 팀장은 팀원 1의 수정사항을 확인한 뒤 Merge pull request를 클릭하여 자신의 리포지토리에 팀원 1의 수정사항을 반영한다. 

 

15. 로컬 저장소에 변경된 파일을 반영한다. 

15-1. 팀장의 경우 자신의 저장소이므로 바로 pull 받는다. 

$ git pull origin develop

15-2. 팀원 2는 자신의 저장소가 아닌 팀장의 저장소의 변경사항을 pull 받아야 한다. (팀원 1도 지금은 자신의 수정사항을 반영했기 때문에 필요 없지만, 팀원 2가 파일을 수정한 경우 같은 작업이 필요하다.)

$ git remote -v // remote의 현재 상황을 확인한다. 

//팀원은 자신의 로컬 저장소에 팀장의 원격 저장소를 연결한다.
$ git remote add upstream {팀장의 리포지토리 github URL}
$ git remote -v // origin 과 upstream이 뜨는 것을 확인!!

15-3. 팀원 2가 팀장의 원격 저장소 변경사항을 pull 받는 방법은 2개이다!! 

// 1. pull : 그냥 다 반영하는 방법!!
$ git pull upstream develop

// 2. fetch & merge : FETCH_HEAD라는 임시 저장소에 받고 원하는 부분을 골라 받을 수 있다
$ git fetch upstream develop
$ git merge FETCH_HEAD

 

 

참고 

• 강사님 영상
• https://velog.io/@0seo8/Git-GitHbub%EB%A1%9C-%ED%98%91%EC%97%85%ED%95%98%EA%B8%B0