팀원들끼리 협업하는 것을 알아보기 전에 팀 프로젝트를 세팅해줘야하기 때문에
초기 설정하는 것을 알고 싶다면 아래 링크를 참고하길 바란다.
https://myvelop.tistory.com/112
현재 팀장이 브랜치 룰을 정하고 팀원들을 초대해 초기설정을 마쳤다. 이제 프로젝트 협업에 대해 알아보자.
협업을 시작하기 전에 팀원들끼리 원격저장소 사용 프로토콜을 미리 정해놓고, 그 규칙에 따라 프로젝트를 관리하는 것이 좋을 것이다. 규칙을 정했다면 시작하자!
1. 레포지터리 복제하고 작업하기(팀원)
이제 팀원들은 초대받은 원격저장소의 내용을 자신의 로컬에 복제하기 위해 git clone을 사용할 것이다.
git log 명령을 사용하면 팀장이 설정해놓은 내용을 확인할 수 있다.
$ git clone 원격저장소_주소
$ git log
commit 9f6adff27f9bd3bf6261a79fabd5a6971ee84a80 (HEAD -> main, origin/main, origin/dev, origin/HEAD)
Author: BigBell <pythonstrup@gmail.com>
Date: Wed Feb 16 17:21:07 2022 +0900
1.세팅 완료
commit 5c86971758f49f844db2372586ec37f927e43915
Author: BigBell <90585081+pythonstrup@users.noreply.github.com>
Date: Wed Feb 16 17:13:24 2022 +0900
Initial commit
브랜치를 확인해보면 main 브랜치밖에 없다. 왜 그럴까?
현재 remote 브랜치에만 모든 브랜치들이 저장되어 있고, 아직 작업 영역으로 가져오지 않았기 때문이다.
git checkout 명령어를 통해 dev브랜치를 만들고 동기화해주자. 아래 진행내용을 확인해보면, dev라는 새로운 브랜치를 만들고, remote브랜치에 있는 dev 브랜치를 가져왔다는 것을 알 수 있다.
$ git branch
* main
$ git checkout -b dev origin/dev
Switched to a new branch 'dev'
Branch 'dev' set up to track remote branch 'dev' from 'origin'
$ git branch
* dev
main
팀원은 dev 브랜치에서 바로 작업을 진행하면 안 된다.(어차피 막혀있겠지만...)
dev 브랜치는 단위 개발이 완료된 merge할 수 있기 때문에 Feature 브랜치를 따로 만들어 개발을 시작하자.
아래 작업을 완료하고 log를 확인하면 home_feat 브랜치로 커밋된 것을 확인할 수 있다.
$ git checkout -b home_feat
$ touch 홈페이지.txt
$ git add .
$ git commit -m "2.홈페이지 완료"
$ git log
commit 127c48eed4e6c2c218921bb324b9e7c9c810332d (HEAD -> home_feat)
Author: BigBell <pythonstrup@gmail.com>
Date: Wed Feb 16 18:20:27 2022 +0900
2.홈페이지 완료
commit 9f6adff27f9bd3bf6261a79fabd5a6971ee84a80 (origin/main, origin/dev, origin/HEAD, main, dev)
Author: BigBell <pythonstrup@gmail.com>
Date: Wed Feb 16 17:21:07 2022 +0900
1.세팅 완료
home_feat 브랜치로 push를 진행하자.
$ git push origin home_feat
2-1. 단위 모듈 merge 요청하기(팀원)
이제 merge 요청을 하기위해 원격저장소의 Pull requests에 들어가 New pull request 버튼을 클릭하자.
이제 home_feat 브랜치를 dev 브랜치에 합치기 위해 브랜치 설정을 해준다. (첫 번째를 dev, 두 번째는 home_feat)
그리고 Create pull request를 누르면 요청 메시지를 적을 수 있는데 여기서 2가지 선택을 할 수 있다.
① Create pull request
② Create dreft pull request
첫 번째 Create pull request는 단위 개발이 아예 완료되어 merge 요청을 위해 보낼 때 사용한다.
두 번째 Create dreft pull request는 주로 코드 리뷰를 부탁하기 위해서 보내는 요청이다.
merge요청을 보내면 아래와 같은 화면이 나올 것이다. 이제 팀장이 요청을 받아줄 때까지 기다리자.
2-2. merge 요청에 응답하기(팀장)
Pull requests에 들어가면 팀원이 작성한 요청서가 있을 것이다. 클릭해서 들어가보자.
Commits의 Review changes를 클릭해보자. 선택지는 3가지다.
① Comment
승인요청을 받아주는 것이 아니라, 코멘트만 남기고 싶을 때 사용하는 것으로
팀원이 draft요청을 하거나 중간보고서를 보냈을 때 코드 리뷰 코멘트를 남겨주는 용도이다.
② Approve
승인할 때 사용한다. 코멘트도 남길 수 있다.
③ Request changes
팀원이 개발 완료된 브랜치와 코드 내용을 커밋하여 merge 요청을 했는데, 완성도가 부족해 거절할 때 쓴다.
승인하기 위해 2번인 Approve를 체크하고 Submit 버튼을 클릭해보겠다.
이제 아래와 같은 창이 뜨는데 Merge pull request 버튼의 오른쪽 화살표를 클릭해주면 3가지 방법이 있다.
① create a merge commit
그냥 merge를 하는 것이다. 대체로 많이 사용한다.
② squash and merge
squash를 통해 merge를 하는 방식으로, 요청에 여러 개의 커밋이 있을 경우 하나의 커밋으로 압축해 merge한다.. (압축방식)
③ rebase and merge
rebase를 통해 merge를 하는 방식이다.
1번 create a merge commit 으로 진행하도록 하겠다.
여기서 Confirm merge 버튼을 클릭하면 합병이 완료된다.
이제 dev 브랜치를 확인해주면 home_feat 브랜치의 내용이 들어와 있는 것을 확인할 수 있다.
3-1. merge 수락 시 - Feature 브랜치(또는 Topic 브랜치) 삭제하기 (팀원)
이제 팀원은 합병된 것을 확인하고 원격 저장소에 있는 home_feat을 삭제해주면 된다. feature 브랜치가 계속 쌓이다보면 브랜치 관리하는 것이 복잡해지기 때문이다.
아래 명령어를 사용하면 원격저장소의 브랜치가 삭제된 것을 확인할 수 있을 것이다. 반면 로컬저장소에 feat 브랜치는 남아있는데 일정 기간동안 가지고 있는 것이 좋다. 갑자기 수정작업을 해야할 수도 있기 때문이다.
$ git push --delete origin home_feat
To https://github.com/pythonstrup/team-project.git
- [deleted] home_feat
$ git branch
dev
* home_feat
main
이제 dev를 동기화 해줘야한다. 왜냐하면 팀원은 로컬에서 dev 브랜치와 feat 브랜치를 합치지 않았다.
feat만 push했고, 원격저장소에서 승인을 받아 병합했기때문이다.
$ git checkout dev
$ git pull origin dev
3-2. merge 거절 시 - Feature 브랜치 내용 수정해서 다시 요청하기(팀원)
만약 팀장이 2-2에서 merge 요청을 거절했다고 해보자.
코멘트가 남아있지만 Merge pull request 버튼이 비활성화되어 있을 것이다.
팀원은 작업을 수정해서 커밋을 완료했다. rebase나 합병을 하지 않았고 원래 가지고 있는 파일을 삭제하지 않고 진행했다면 딱히 문제가 없을 것이다. 하지만 만약 rebase를 진행해서 로컬과 원격저장소의 커밋에 괴리가 생기면, 아래와 같이 거절 문구가 뜨면서 push 명령이 수행되지 않을 것이다.
$ git push origin home_feat
To https://github.com/pythonstrup/team-project.git
! [rejected] home_feat -> home_feat (non-fast-forward)
error: failed to push some refs to 'https://github.com/pythonstrup/team-project.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
여기서 설명하는 것처럼 git pull을 하면 로컬저장소에서 만들어놓은 수정본이 날라갈 수 있기 때문에
강제로 push해야한다. 명령어는 아래와 같다.
$ git push -f origin home_feat
만약 dev나 main에 강제로 커밋을 진행하게 되면 실수로 인해 오류가 발생할 가능성도 굉장히 크니,
Feature 브랜치에서만 rebase명령을 사용하고 강제커밋을 하자.
이제 깃허브 원격저장소로 들어가보자. 아직 merge가 끝나지 않았기 때문에 Pull requests에 기록이 남아있을 것이다.
2. 홈페이지 완료를 클릭하자. 이제 들어가서 위에서 했던 것처럼 코멘트를 다시 남기면 팀장이 처리해줄 것이다.
만약 수정본이 승인되어 merge과 완료되었다면 3-1을 참고해서 원격저장소에 있는 Feature 브랜치인 home_feat을 삭제하고 Develop 브랜치를 git pull 명령을 통해 가져오자.
4. Develop 브랜치에서 개발이 완료된 배포본을 main으로 가져오기(팀장)
이제 팀원들과 함께 배포본을 완성했다. Develop 브랜치에 있는 완성된 배포본을 main에 합병해야 한다. 일단 dev 브랜치로 체크아웃하고 그 내용을 원격저장소에서 가져온다. 그리고 git log로 정상적으로 들어왔는지 확인한다.
$ git checkout dev
$ git pull origin dev
$ git log
이제 main 브랜치에서 merge를 수행하면 된다. merge할 때 합병 로그를 남기기 위해 --no-ff 를 꼭 붙여주자.
git log를 통해 확인해보면 dev 브랜치가 합병된 것을 확인할 수 있다.
알아서 merge 로그가 생기기 때문에 따로 커밋을 해줄 필요는 없다.
# 브랜치 main으로 변경하기
$ git checkout main
$ git merge --no-ff dev
$git log
Merge: 9f6adff 80705c3
Author: BigBell <pythonstrup@gmail.com>
Date: Thu Feb 17 18:44:20 2022 +0900
Merge branch 'dev'
이제 태그를 붙여 원격저장소에 push하자. --tags를 붙여주지 않으면 태그가 원격저장소에 push되지 않으니 주의하자.
# project 버전이 1.0.0 이라는 태그 붙이기
$ git tag project1.0.0
# tag와 함께 push
$ git push --tags origin main
