1. Project, Issue, Branch, PR을 통한 협업
이 방법이 항상 정답이 아닐 수도 있습니다. 더 가벼운 프로젝트에서는 main, dev에 직접 push할 수도 있고, 더 무거운 프로젝트에서는 release repo를 하나 더 만들고, PR도 fork를 만들어서 진행하며, read only로 할 수도 있습니다.
개인repo > githubflow repo 생성 컴퓨터에 폴더 생성 후 아래 명령어 입력 $ echo "# githubflow" >> README.md $ git init $ git add README.md $ git commit -m "first commit" $ git branch -M main $ git remote add origin https://github.com/paullabkorea/githubflow.git $ git push -u origin main project > board 형태로 하나 제작 필요할 경우 title 명 변경 이슈 > new 이슈 // 이슈는 프로젝트에서 1개의 block을 선택 후 Convert to issue로 바꿀 수 있습니다. 필요할 경우 label 변경 및 추가 wiki 제작
- (선택) 아래와 같이 project status를 바꿀 수 있습니다.
- (선택) 이곳에서 직접 branch를 생성하여 그곳에서 작업할 수 있습니다.
project에서 이슈들이 No status에 배치되어 있는 것을 확인하고 필요에 따라 옮김 $ git branch $ git branch dev $ git push --set-upstream origin dev settings > general > default branch > dev branch로 업데이트 $ git branch $ git checkout dev $ git branch Feat/one $ git branch Feat/two $ git branch Feat/three $ git checkout Feat/one $ echo 'hello world one' >> one.txt // $ touch one.txt 후에 텍스트 편집하셔도 됩니다. $ git add . $ git commit -m 'convension에 따른 one' $ git push --set-upstream origin Feat/one // 잘 모르면 tap 눌러가시며 자동완성 GitHub에 Feat/one만 올라간 것을 확인 (two와 three가 올라가지 않은 것이 핵심)
GitHub에서
git push --set-upstream origin Feat/one 명령어를 사용할 때, --set-upstream (또는 -u로 축약될 수 있음) 옵션은 Git에 현재 브랜치와 원격 레포지토리 사이의 연결을 설정하는 명령어입니다. 이렇게 설정하면, 이후에 같은 브랜치에서 git push 또는 git pull 명령을 사용할 때 원격 브랜치를 명시적으로 지정하지 않아도 됩니다.git push: 현재 로컬 브랜치의 변경 사항을 원격 레포지토리로 보내는 명령입니다.
-set-upstream: 이 옵션은 현재 브랜치와 원격 브랜치 사이의 추적 연결을 설정합니다.
origin: 보통 기본 원격 레포지토리의 별칭입니다.
Feat/one: 원격 레포지토리에 푸시할 브랜치의 이름입니다.
- GitHub에 접속 후 확인합니다.
(선택) 아래 그림에서 Protect this branch를 클릭해서 main 브랜치는 Require a pull request before merging을 선택해주세요. 프로젝트 규모에 따라 Lock branch(push block)를 하는 경우도 있습니다.
(선택) 꼭 메인 페이지에서 PR을 할 필요는 없고 메뉴에 pull request클릭하셔서 하셔도 됩니다. pull request에 알람으로 올라온 것이 없다면 new pull request 클릭하셔서 새로운 PR을 만드셔도 됩니다.
(선택) 하나의 repo에서 PR을 생성하는 경우가 있고 좀 더 중요한 프로젝트나 오픈소스 프로젝트의 경우 fork를 떠서 PR을 생성하는 경우도 있습니다. 실습은 하나의 repo로만 진행합니다.
PR 날리실 때에는 꼭 상대방의 입장에서 상세히 적어주세요. 리뷰하는 사람은 자신의 업무와 더불어 리뷰도 해야 합니다. 리뷰어를 지정하셨을 때 리뷰어가 해당 코드도 이해가 안되고, 설명도 이해가 안되면 리젝하는 것이 맞습니다.
PR이 dev 브랜치로 날아가고 있는지 확인해주세요.
- Create pull request를 눌렀을 때 나오는 화면에서 files changed를 눌렀을 경우
- Approve를 통해 승인할 수 있습니다. 제가 push한 것이기 때문에 현재 Approve는 되지 않습니다. 팀이 작을 때에는 1명, 팀이 클 때에는 2명 등 몇 개의 approve가 있어야 merge를 할지 정할 수 있습니다.
- 다시 Conversation으로 돌아와서 merge를 하기 전 development로 issue를 선택한 다음 merge를 합니다. 이 기능은 PR 날리는 코멘트에
closes #이슈번호를 입력하면 해당 이슈가 닫히게 할 수 있습니다. PR 후에 연결할 수도 있지만 이렇게 하면 project에 연결된 이슈가 하나 더 생기게 됩니다.
- 여기까지 완료가 되었다면 해당 브랜치를 삭제할 수 있습니다.
- 삭제 한 다음 GitHub Project로 들어가 Project에 Done으로 ‘one’이 반영이 잘 되었는지 확인해주세요.
- 이 절차를 정리하자면 아래 그림과 같습니다.
- 여기까지 진행을 잘 하셨다면 브랜치는 2개여야 합니다.
$ git branch // 아직도 5개? $ git checkout dev $ git pull $ git branch -D Feat/one $ git branch
2. 충돌 발생했을 경우
- 시나리오: conf1, conf2에서 각각 readme에 #1, #2로 수정하여 차례대로 PR을 날리는 경우
$ git branch $ git branch dev $ git branch $ git checkout dev $ git branch conf1 $ git branch conf2 $ git checkout conf1 // readme를 `#1` 으로 수정 $ git add . $ git commit -m 'conf1' $ git push --set-upstream origin conf1 // 기존대로 홈페이지에서 PR생성후 merge
- 2번째에서 PR을 생성할 때 아래와 같은 오류가 나게 됩니다.
- PR 생성해주세요. 그러면 web editor나 command line을 통해 수정할 수 있다고 나옵니다. 실습은 web editor로 하도록 하겠습니다.
// 다음과 같이 command line에서도 해결할 수 있습니다. (충돌 발생 확인후 PR 생성, command line을 클릭하면 명령어가 나오긴하는데 조금 다릅니다.) paullab@DESKTOP-41F12GK MINGW64 ~/Desktop/test (conf2) $ git pull origin dev From https://github.com/paullabkorea/gitflowtest * branch dev -> FETCH_HEAD Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result. // 수정창이 뜨면서 기존에 conflict 해결했던 것처럼 선택을 해야 합니다. paullab@DESKTOP-41F12GK MINGW64 ~/Desktop/test (conf2|MERGING) $ git add . paullab@DESKTOP-41F12GK MINGW64 ~/Desktop/test (conf2|MERGING) $ git commit -m 'merge2' [conf2 887e14f] merge2 paullab@DESKTOP-41F12GK MINGW64 ~/Desktop/test (conf4) $ git push (서비스에서 새로고침을 누르면 자동으로 머지가 가능한 상태가 되어 있습니다.)