목차

• Forking Workflow에 대해서
• Workflow를 어떻게 진행해야 하는가?
  1. 팀장이 하는 일
  2. 팀원이 하는 일
  3. 팀장의 피드백
  4. 팀원의 피드백
  5. 팀장의 확인
  6. 팀원의 확인
• 마치며

Forking Workflow

1. 팀장의 저장소를 Fork해서 팀원마다 각각 저장소를 가지고 프로젝트를 진행하는 방식이다.
2. 각자의 저장소에서 자유롭게 작업을 진행하고 최종적인 팀원의 작업 내용은 Pull requests를 통해 팀장의 확인이 난 후에 반영된다.
3. 팀장 저장소의 권한은 팀장만 가지고 있으면서 다른 사람의 commit을 프로젝트에 적용이 가능하다.
4. 오픈소스 프로젝트에서 많이 사용하는 방식이다.

Workflow를 어떻게 진행해야하는가?

한 회사의 팀장과 팀원이 있고, 그들의 프로젝트의 이름은 team project P라고 하자.

🌳 팀장이 하는 일

1. 먼저 팀장이 저장소를 만들고 프로젝트를 설정 후, 생성한다.

여기서 팀장은 project P의 repository의 이름을 project_p를 생성하게 된다. (어디까지나 프로젝트의 이름과 저장소의 이름은 예시다.)

2. 팀장은 본인의 로컬 저장소에 클론을 한다.

$ git clone [repository의 URL]
$ cd [디렉토리 이름]
$ git branch
>> *main

디렉토리의 이름은 repository의 이름과 동일하면 편하다.
$ git branch를 하는 이유는, 브랜치의 이름이 main 또는 master 일 수도 있으니 확인하는 것이 좋다.

3. git flow를 이용해서 작업을 시작한다.

📌 git-flow cheatsheet

$ git flow init
> 설치가 진행된다.
$ git branch
> *develop
> main
$ touch feat.py
$ git status
> Untracked files ~
$ git add feat.py
$ git commit
<< "feat: Create feat.py" (commit의 내용을 채운다.)
// commit의 창에서 나오려면 ESC를 눌러서 기본 상태로 바꿔준 후, :wq로 저장 후 나간다.

다시한번 $ git branch를 한 이유는, develop 브랜치가 잘 생성되었는지 확인하기 위해서다.
$ git status를 해서, Untracked files 내용이 뜨는걸 확인해서 아까 생성했던 feat.py가 있다는걸 알 수 있다.

4. git commit까지 했으면, 작업한 내용을 원격 저장소에 push

$ git push -u origin develop
// 입력한 후의 마지막 줄
>> *[new branch]   develpop -> develop
>> Branch 'develop' set up track remote branch 'develop' from 'origin'.

이렇게 해서 원격 저장소의 내용이 로컬 저장소에 최신화가 된다. 즉, 처음 push를 해주는 것이기 때문에 -u를 붙여서 입력해준다.
push를 해준 후에 다음과 같은 상태가 뜨면 성공적으로 마친 것이 된다. 위와 같이 develop 브랜치가 remote의 develop 브랜치를 origin에서 따라가도록 성정이 되었다면, github에서 만들었던 repository에 들어가서 develop 브랜치가 잘 생성이 되었는지 확인한다.

5. 이제 팀장은 팀원들에게 프로젝트를 시작하라는 메세지를 보내게 된다.

🌱 팀원이 해야하는 일

1. 팀원은 팀장의 해당 프로젝트의 github로 이동한다.

이때, 바로 $ git clone하지 않는다.

2. Fork를 통해 전체 저장소를 복제한다.

팀원은 팀장의 repo를 clone해서 바로 push할 수 없다. 팀장의 계정과 비밀번호, 설정까지 똑같지 않기 때문이다.

팀원은 팀장의 url을 타고 저장소로 이동했을 때, code 버튼을 바로 clone하는 것이 아니라, workflow 중에서도 Fork라는 방법을 이용한다. 이것은 전체 저장소를 복제하는 것이다.

왜냐하면, 이것은 내가 생성한 것이 아닌 팀장의 repository이기 때문이다. 팀장의 repo의 사본을 만들어서 그곳에 push를 해야하는 것이다.

그렇게 Fork를 하면 내가 작업할 수 있는 repository가 복제된다. 로딩이 있고 나서 팀원은 팀장의 repo로부터 복제가 된, 내 권한의 복제 repo가 생성된다.

❗️ 나중에 기능을 추가하기 위해 팀원들이 서로 최적화를 해야하기 때문에, 팀장에게 작업한 내용을 pull request 해달라고 이때 요청한다.

❓ Fork를 떠온 당시에는 브랜치가 동일하지만, 이후에는 싱크로나이즈를 맞춰가야하는 것이다. 즉, 상시 연동 개념이 아니다.

3. Fork한 개인 원격 저장소에 개인 로컬 저장소를 생성한다.

// git clone할 디렉토리의 위치를 정한 후
$ git clone [복사된 저장소 url]
$ cd [디렉토리]
$ ls
>> README.md // faet.py가 없는 것을 확인.
$ git branch
>> *main // 확인해보면 main 브랜치 밖에 없다는 걸 확인할 수 있다.

$ ls로 해당 디렉토리를 살펴보면 feat.py가 없다. 그 이유는 main 브랜치의 상태만 복제한 것이기 때문에, 팀원 또한 $ git flow init을 해서 환경을 설정해주어야 develop 브랜치에 feat.py를 확인 할 수 있다. 하지만 $ git flow init을 하기 전에, issues를 작성해야한다.

4. Issues 작성한다.

• 팀장의 원격 저장소의 issues를 작성한다.
• 내가 어떤 기능을 구현할지 또는 기능 제안(suggest), 프로그램의 버그 리포트 등을 작성할 수 있다.

// ex
title : I added new feat.
write : # Task list
		- [ ] add feat1
        - [ ] add feat2
        - [ ] checked feat

issues를 작성하고 나면, 해당 issue에 대한 번호가 붙는다. issue가 처음 발생했다면 #1 으로 뜨는걸 확인할 수 있다.

5. $ git flow init을 통해 초기화 한다.

$ git flow init
$ ls
>> README.md   feat.py
// 이제 feat.py가 생긴 것을 확인할 수 있다.

📌 팀원은 팀장의 main 브랜치의 상태만 복제한 것이기 때문에, $ git flow init 통해 팀장과 똑같은 환경을 만들어야지 파일이 당겨오게 되는 것을 잊지 말자.

6. 기능 개발 시작

$ git flow feature start [FEATUER 브랜치의 이름]
// FEATURE의 브랜치 이름을 지을때는, 알기 쉽게 짓도록 하자.
// 작업 시작
$ vi feat.py 
// 작업 종료
 $ git status
>> modified: faet.py
$ git add faet.py
$ git commit
<< "feat: Complete featuer"

7. 기능 개발 종료 후 개인 원격 저장소에 push한다.

이제 내용이 끝났다는 가정 하에(기능 개발이 끝났다는 가정), FEATURE 브랜치를 닫는다.

$ git flow feature finish [아까 정한 FEATURE 브랜치의 이름]
$ git push -u origin develop

• $ git flow feature finish을 함으로, develop 브랜치에서도 FEATURE 브랜치에서 했던 내역이 동작하게 되는 것이다.
• $ git push -u origin develop 첫 push일 수 있으니까, upstream set을 해준 것이다.

팀원은 팀장의 저장소에서 복제를 뜬, 개인 저장소 project_p에서 작업을 한 내역이 생겼고 사이트를 확인해보면 작업한 내역이 들어온 것을 확인할 수 있다.

8. 팀장에게 작업 내용을 전달해서 컨펌을 받는다.

팀원은 자신의 원격 저장소에서 compare & pull request를 누르거나, contribute라는 버튼을 눌러서 뜬 창의 open pull request를 눌러서 진행할 수 있다.

버튼을 누르면, 팀장의 repo로 이동하게 되고 open a pull request를 할 수 있다.

❗️팀장의 repo base: develop ← 팀원의 repo compare: develop 이 뜬다. 이때 화살표 방향과 브랜치 확인을 잘 해야한다.

Issues

• 개발이 끝날 때마다 해당하는 issues에 대한 해결 사항을 Open a pull request에 작성해야한다.
• solve # 하면 아까 만든 issue가 자동 완성되는데, 그것을 선택해주면 자동 완성이 된다. 또는 -#를 눌러 해당 이슈를 자동 완성 시킬 수 있다.

✅ 팀장의 피드백

1. Issues를 체크한다.

팀장은 issues의 버튼을 눌러, issues를 체크한다. issues에 들어가면 오른쪽에 Assignees와 Labels등을 확인할 수 있다.

• Assignees: 본인
• Labels: 해당하는 tag 선택. 이때는 enhancement를 선택해준다.

2. Pull requests

팀장이 팀원에게 요청사항을 요구해야하는 상황이라고 가정하자.

Conversation

• Reviewers : 작성하는 본인
• Assignees: 본인 + 팀원
• Label: enhancement

Files changed

• 먼저, 코멘트를 적을 해당 코드에 마우스오버를 하면 + 버튼이 나타난다. 그 버튼을 눌러서 해당 코드의 코멘트를 단다.

Fisish your review

1. 오른쪽을 보면 초록색으로 된 버튼 Fisish your review을 클릭해서, Write에 코멘트를 작성한다.
2. 해당하는 라벨을 클릭한다.
   • Comment: 단순한 조언
   • Approve: 승인
   • Requset changes: 요청사항이 있는 경우
3. Submit을 클릭해서 제출한다.

💬 팀원의 피드백

위와 같이 팀장의 요청사항이 있다는 상황을 가정한다.

1. 요청사항을 확인한다.

• technical issue에 대한 커뮤니케이션을 진행한다. issues에 가서 코멘트에 대한 답을 단다.

• 팀장의 develop 브랜치가 Open 되어 있는 상태라는 것은, 팀원이 무언가를 변경 및 추가를 하면 아래의 타임라인 pull request 아래에 반영된다.

• 추가 요구 사항이 생겼을 때, develop에서 작성을 해서 바로 push하게 되면 pull request에 반영된다.

• 팀장은 Open이 되었을 때, 바로 Close 상태로 바꿔주어야 팀원들이 원할하게 작업할 수 있게 된다.

2. 피드백을 받은 것을 수정한다.

이제 수정사항이 생긴 것을 반영한다. 만약 수정사항이 2개라면 commit은 두 번 해야한다.

// 수정된 파일이 있는걸 확인
$ git status
// 1번의 요청 사항 수정
$ vi feat.py
$ git add feat.py
$ git commit
// 2번의 요청사항 수정
$ vi feat.py
$ git add feat.py
$ git commit

3. push 한다.

$ git push origin develop

전체 push를 했으면, github로 가서 맨 밑에 push한 내역이 보인다. 이제 수정 사항대로 했으니 각각 달렸던 코멘트에 resolve converation을 클릭해준다.

✅ 팀장의 확인

1. Feiles changed

파일을 확인하고 수정사항이 잘 반영되고 작동한다는 가정을 했을 때.

• viewed 체크를 하면 파란색으로 바뀐다.
• Reviewe changed를 클릭해서 내용을 적고, submit review를 클릭해서 피드백을 보낸다.

2. 확인 후 Merge pull request

📌 이것은 팀장급의 사람이 해야한다. 절대 팀원이 하지 말 것.

✅ 팀원의 확인

수정에 기여한 팀원 외 다른 팀원들은 develop이 바뀐 사항들에 대해 pull을 해야한다.

팀원은 remote를 확인해야한다.

// 확인
$ git remote
$ git remote -v

// 팀장의 repo의 url 등록
$ git remote add upstream 
$ git remote -v

// upstream 당겨오기
$ git fetch upstream develop  
$ git merge FETCH_HEAD

❗️ upstream의 경우는 관습적으로 사용하는 alias다.

📌 팀장은 본인 것이기 때문에 바로 pull을 받으면 된다.

$ git pull origin develop

upstream 당겨오는 방법
1. pull
2. fetch

• 당겨서 해당 브랜치에 반영을 바로 하는 것이 아니다.
• 당겨서 FETCH_HEAD라는 임시 브랜치에 담아 둘 수 있다.
• FETCH_HEAD에 담긴 후에는 원하는 부분만 당겨올수도 있고 전체를 당겨올 수도 있다. (이 때 바로 당기게 되면 pull과 동일하게 동작한 것과 같다.)

이렇게 한 사이클을 돌린 것이다. 여기서 feature 브랜치를 가져와서 작업을 하면 다른 사이클이 시작이 되는 것이다.

$ git flow feature start new-feat

마치며

최우영 강사님의 강의와 다른 스터티 팀원들과 함께 작업하면서 문제점을 찾으면서 공부했습니다.

📌 참고 사이트 1