개요
이번에는 소규모 협업시 사용하는 팀프로젝트를 진행할 때, Git사용법에 대해서 간단히 정리해보겠습니다.
이번에는 팀장의 역할, 팀원의 역할 두가지로 나누어서 Git을 사용해보겠습니다.
프로젝트 시작시 팀장의 역할
프로젝트 생성 및 환경구축
팀프로젝트를 시작합니다.
팀장은 팀원을 위해서 repository를 생성해줍니다. 저는 위처럼 "git_practice_team_develope" 라는 repository를 연습용으로 생성해주었습니다.
git clone {클론할 저장소 주소}
git touch 환경설정.txt
git add .
git commit -m "환경설정 완료"
git checkout -b dev
git push --all
이후 팀장은 자신의 git 로컬 저장소에 해당 repository를 clone 해줍니다.
프로젝트를 시작하면 팀원들이 사용할 환경설정을 해줍니다. 예를들어 springboot라면 dependency, apllication.yml 등등 라이브러리 버전 등등의 환경설정 등을 해주어야합니다. 저는 간단하게 환경설정.txt라는 텍스트파일을 추가해주는 것으로 대체했습니다.
이후 add, commit을 하고, main 브렌치에는 완성된 제품이, 나머지 기능추가들은 dev에서 merge해서 합칠 것 이므로 dev 브렌치를 생성해줍니다. 프로젝트 생성 최초에는 push --all을 해줍니다. 이 옵션을 사용하면 모든 브렌치에 push가 되는데, dev에도 main에서 생성한 환경설정 파일이 적용됩니다.
위처럼 환경 설정파일과 dev브렌치가 잘 생성되었습니다.
팀원 초대 및 권한제어
팀장은 이후에 프로젝트에 참여할 인원을 초대합니다.
repository의 설정 > Collaborators > Add people에서 원하는 팀원의 github닉네임을 적어서 추가합니다. 저는 팀원입장에서도 진행해보기위해서 MiniCorder라는 계정을 새로 만들었습니다.
팀원 입장에서는 이렇게 github에서 설정된 이메일에 초대메일이 올 것입니다. 해당 메일을 통해서 프로젝트에 참가할 수 있습니다.
추가적으로 repository의 설정에서 Branch설정을 해야합니다.
왜냐하면, 너도나도 main이나 dev같은 모두가 사용하는 브렌치에 머지를 실행할 수 있는 권한이 생기면, 코드가 꼬이고 누가 뭘 했는지, 한마디로 개판이 될 수도 있습니다. 그러므로 팀원이 코드를 짜면, 다수의 인원이 허락해야 merge를 할 수 있다거나 팀장이 확인 후 merge를 하도록 보호받아야합니다.
repository의 설정 > Branches > main브렌치에 Require a Pull request before merging, Require approvals라는 옵션에 체크를 해주고 add로 추가해줍니다. 이렇게하면 main브렌치에 대해서 아무나 merge를 못하고 승인받은 사람만이 merge를 할 수 있게 됩니다. 이로서 보호받는 브렌치가 됩니다.
dev 브렌치 또한 같은 설정을 해줍니다.
팀원의 작업
팀원의 작업 시작전 설정
git config --global user.email "이메일"
git config --global user.name "이름"
git clone "repository 주소"팀원인 MiniCorder의 입장에서 작업을 하도록 하겠습니다. 따로 폴더를 파서 사용자의 config를 바꿔줍니다. 설정을 해준 후 프로젝트를 clone해줍니다.
클론 후 git log을 통해서 로그를 확인해보면, mian, dev라는 브렌치가 존재하고 "환경설정 완료"라는 커밋을 발견할 수 있습니다.
git branch
git checkout -b dev origin/dev
git branchgit branch로 확인해보면, main 브렌치 밖에 없는 것을 확인할 수 있습니다. 당연히 팀원의 로컬에서는 dev를 생성한 적이 없기 때문입니다. 그러므로 dev 브렌치를 생성하면서 origin/dev 즉, github의 dev내용을 뽑아와서 만들어줍니다. 이렇게 하면 데이터를 동기화할 수 있습니다.
팀원 작업 시작
git checkout -b join_topic
git touch 회원가입.txt
git add .
git commit -m "2. 회원가입 완료"
git push origin join_topic팀원은 배당받은 코드 작업을 시작합니다. 예를들어 회원가입 기능을 만들어야 한다고 지시를 받았습니다.
여기서 팀원은 dev브렌치에서 작업하면 안됩니다. dev는 여러명의 작업이 merge되어 합쳐지는 구간이므로 여기서 작업을 하면 계속 충돌이 날 수 있습니다. 그러므로 따로 topic이라는 브렌치를 만들어서 작업해줍니다.
join_topic이라는 회원가입 기능을 만들 브렌치를 추가합니다. 간단하게 회원가입.txt를 추가해서 작업을 했다고 하겠습니다. add, commit을 해줍니다. 이후 다른 팀원들도 확인할 수 있도록 github에 push해줍니다.
그럼 이렇게 MiniCorder라는 팀원이 join_topic이라는 브렌치를 만들고, 회원가입이라는 파일을 추가한 것을 github에서 확인할 수 있습니다.
이제 팀원이 작업한 내용에 문제가 없으면, dev라는 브렌치에 기능을 합쳐줘야합니다. 하지만 아까 팀장이 설정했듯이 일반적인 팀원은 dev, mian 브렌치에 merge를 할 수 없습니다. 그러므로 팀원은 pull request 라는 요청을 보내야합니다. 상단의 pull request란에 들어옵니다.
- 상단에 Able to merge라는 곳에서는 join_topic을 dev로 합치고 싶다는 것을 명시해줍니다.
- 제목과 내용을 적습니다. 여기서는 간단하게 적었지만 요청내용과, 수행한 내용을 상세히 적어줍니다.
- 우측하단의 버튼으로 request를 생성합니다. 여기에 두가지 메뉴가 있는데, Create pull request는 말그대로 request를 생성하고, Create draft pull request는 아직 작업을 완료하지는 않았지만, 나의 작업을 한번 보여줄 때 사용합니다.(중간보고 느낌)
pull request를 날리게되면, 위처럼 request가 생기고, 하단처럼 일반적인 팀원은 merge를 못하도록 block되어 있는 것을 확인해볼 수 있습니다.
추가적으로, repository의 setting에 이메일을 추가해두면, pull request가 생성시 해당 이메일들에게 메일을 쏴줍니다.
팀장의 작업 승인
팀장은 repsitory에서 해당 내용을 확인합니다.
어? MiniCorder라는 팀원이 회원가입 기능을 완료했고, merge하고 싶어하는구나. 코드를 확인하고 이상이 없다면, review changes라는 좌측상단의 버튼을 클릭해서 결과를 알려줍니다.
- Comment는 draft와 같은 중간보고에 대해서 코멘트를 달아주는 용도입니다.
- Approve는 해당 작업이 문제가 없으니 승인할때 사용하는 용도입니다.
- Request changes는 해당 작업에 문제가 있을 시 입니다. 승인을 거절하는 용도입니다.
이번에는 Approve로 승인을 해주어보겠습니다.
그럼 위처럼 comment가 달리면서 Merge pull request라는 버튼이 활성화 됩니다. 해당 버튼을 누르면 join_topic과 dev가 merge되면서 하나로 합쳐질겁니다. 해당 버튼은 웬만하면 팀장이 누르는 것이 좋습니다.
해당 버튼에도 3가지 기능이 있습니다.
- Create a merge commint은 말그대로 merge하면서 커밋을 남깁니다.
- Squash and merge는 join_topic(합쳐질 브렌치)의 쓸데없는 커밋들을 하나의 커밋으로 합쳐서 merge합니다.
- Rebase and merge도 비슷하게 rebase를 해서 커밋을 날립니다.
하지만 Squeash의 경우는, 해당 작업을 수행한 커밋은 남겨져 있는 것이 좋습니다. 그러므로 그대로 merge하는 것이 좋습니다. 또한 Rebase의 경우, 잘못된 커밋을 지우고 합치는 과정인데, 이것은 팀장이 아니라 팀원이 자신의 로컬에서 rebase해서 다시 올리는 것이 좋습니다. 그러므로 웬만하면 Create a merge commit을 사용합니다.
merge를 실행하면 위처럼 dev브렌치의 commit에 join_topic이 merge된 것을 확인할 수 있습니다.
승인 이후 팀원의 작업
git push --delete origin join_topic해당 팀원은 github에서 해당 작업 브렌치를 삭제해줍니다. 이렇게 하지 않으면, 여러 팀원의 작업용 브렌치가 계속 쌓여서 매우 지저분한 repository가 될 것이기 때문이다. 하지만 만약을 대비해서 해당 팀원은 로컬에서는 삭제하지 않는 것이 좋을 수도 있습니다.
git checkout dev
git pull origin dev또한, 현재 팀원의 dev브렌치는 join_topic이 dev와 merge된 사실을 모릅니닺. 그러므로 dev 브렌치로가서 github의 dev 브렌치와 동기화해주기 위해서 pull을 진행합니다. 그러면 동기화 완료입니다.
거절 시나리오
git checkout -b login_topic
touch 로그인.txt
git add .
git commit -m "로그인 만들다가 퇴근"
// 다음날 작업 완료
git add .
git commit -m "3. 로그인 완료"
git push origin login_topic
승인을 거절시 작업에 대해서 해봅니다.
이번에는 로그인 작업을 받은 팀원이 로그인 작업을 하다가, 다 못만들어서 "로그인 만들다가 퇴근"이라는 커밋을 로컬 브렌치에 남기고 퇴근을 했습니다. 그리고 다음날 출근해서 로그인 작업을 마치고 해당 내용을 push해버렸습니다.
쓸게없는 "로그인 만들다가 퇴근"이라는 커밋은 rebase를 통해서 없애주고 push를 했어야 되는데, 실수해버린 상황입니다.
이후 pull request를 보냅니다.
실제로는 코드 테스트도 해보고, 주석도 달고, 세세하게 적어야합니다.
그러면 위처럼 쓸데없는 커밋까지 같이 날아간 모습을 확인해볼 수 있습니다.
팀장이 pull request가 왔으니 확인해봅니다. 여기서 이상한 커밋이 있는 것을 확인했습니다.
해당 커밋에 대해서 review changes에서 Request changes옵션을 통해서 다시 올려달라고 요청합니다. 아까 말했다싶이 이런 commit관련 실수는 내용은 팀장이 처리해도 되지만 팀원이 하는것이 좋습니다.
그러면, 위처럼 merge가 막히면서 해당 커멘트가 pull request에 남습니다.
git rebase -i HEAD~2
git log
팀원은 해당 메세지를 보고 수정을 합니다. 로컬 git에서 rebase를 통해서 "3. 로그인 완료"라는 하나의 커밋으로 통일해주었습니다.
하지만 이대로 push하면 에러가 발생합니다.
왜나하면 현재 팀원의 로컬 git에는 "3. 로그인 완료"라는 커밋만 있지만, push할 github에는 "로그인 만들다가 퇴근"이라는 커밋도 존재하므로 형상이 맞지않아 거부당합니다. 그래서 push 전에 origin에 있는 내용을 pull해서 동기화 해보라는 도움말이 뜹니다.
하지만, pull을 하면 이전 상태로 돌아가 쓸데없는 커밋이 그대로 다시 생깁니다. 그러므로 pull을 하지말고, 강제로 push를 해주어야 합니다.
git push -f origin login_topic-f 옵션을 통해서 강제로 push해줍니다. 이번에는 에러가 뜨지않습니다.
다시 github의 pull request로 가보면 아까와 달리 "로그인 만들다가 퇴근"이라는 커밋이 사라져있습니다.
그럼 팀원은 수정사항에 대해서 재승인을 요청하도록 메세지를 하단에 남겨줍니다.
팀장은 수정사항을 확인하고, Review changes를 통해서 Approve로 merge 승인을 하게됩니다. 이제 merge해서 dev 브렌치와 합치면 됩니다.
프로젝트 완성후 팀장의 역할
git checkout dev
git pull origin dev
git checkout main
git merge --no-ff dev
git log개발이 끝나면, 팀장은 dev를 main으로 머지해주어야 합니다. 일단 팀원들의 작업이 추가된 dev를 동기화한 후 merge해줍니다.
git tag blog1.0.0
git push --tags origin main완성된 제품이므로, 추가적으로 tag를 달아 같이 origin으로 push해줍니다.
repository에서 위처럼 버전이 추가된 것을 확인할 수 있다.
이후에 할일
이후에는 해당 완성된 코드를 통해서 CI도구를 통해서 코드를 자동으로 넘겨서 배포를 해주게 됩니다.
CI도구에서 테스트를하고, AWS,Azu..등등을 이용해서 프로젝트를 배포해줍니다. 이 때, AWS로 배포하기위해 jar파일로 변환해서 배포가 되는데, CI도구가 이를 감지하기위해(main의 코드를 request요청해서 알아보기 = 풀링) jenkins, travis등을 이용해서 풀링을 합니다.
최근에는 github action을 통해 CI도구를 사용하지 않고 배포를 할 수도 있습니다. 하지만 이런 최신 기술들은 어떻게 내부가 돌아가는지 알고 사용해야 할 것입니다.
'협업을 위한 공부 > Git' 카테고리의 다른 글
| Git - 2. 개인 프로젝트를 위한 Git 사용법 (0) | 2024.01.16 |
|---|---|
| Git - 1. Git 간단한 실습으로 기능 파악하기 (1) | 2024.01.16 |
