git 활용 step 3rd-#2 / collaborator로 협업하기

Introduction

이번에는 collaborator로 협업하기 포스팅을 해보겠다.
협업하기 포스팅 fork에서는 각자의 깃허브 계정에 레포지토리를 fork로 복제해와서 pull request를 날리는 방식으로 협업을 했지만, collaborator는 한 레포지토리를 가지고 여러 팀원이 협업하는 방식이다.

때문에 fork보다 더욱더 직관적이고 이해하기는 더 쉬울듯?
암튼 할말 없어서 바로 시작해봄

---

이전 fork로 협업하기 포스팅처럼 이렇게 환경구성을 헀다.

모두 각자의 컴퓨터에서 협업을 하는 그림이기 때문에 무찌와 도리 모두 컴퓨터가 존재하다는 상황을 만들기위해 우분투 이미지로 VM을 팠고 각자의 github의 계정으로 로컬상에 로그인을 해둔 상태임

 

 

 

collaborator로 협업하기는 어떤 구조야?

보통은 팀장이 레포지토리를 하나 만든다.

그리고 각 멤버들은 해당 코드를 가지고 코딩을 한 후, push를 할 수 있다.

public레포지토리라도 본인 계정이 아니면 push권한은 없기때문에 push를 못하지만, collaborator로 멤버들을 초대하면, 멤버들은 해당 권한을 얻게된다.

이전 fork로 협업하기에서 private레포지토리를 fork해가기위해 강아지 개발자들을 collaborator로 초대한것도 같은맥락임..

 

 

 

 

 

해보자

나 팀장이다

프로젝트를 할 레포지토리를 colla-puppy-project라는 이름으로 만들었다.

이제 강아지 개발자들을 협력자로 초대하자.

 

setting탭을 누르고 collaborators라는 탭을 누른다. 그후 add people클릭

muzziworker를 검색해서 초대하자

무찌에게 초대장을 보냈다. 현제 초대가 pending상태라고 떠있음.

 

 

이제 무찌의 시점이다.

깃허브에 가니까 메세지가 와있다. 그럼 초대장이 와있는걸 확인가능하다.

팀장님이 초대를 줬다. 수락하자.

 

# 테스트를 해볼까?

무찌 컴퓨터에서 팀장님 레포지토리를 clone했다.

잘 받아온걸 확인함.

근데 clone은 퍼블릭 레포지토리면 누구나 가능하기때문에 이건 중요한게 아니다.

무찌는 직접 app.js파일을 수정했다. bowwow라는 코드를 추가하고 remote에 추가된 팀장님 레포지토리주소에 commit후 push했다.

push가 무사히 이뤄진걸 확인함.

실제로 팀장님의 레포지토리에 main브랜치로 직접적으로 push가 되었고 무찌가 커밋한 내용이 그대로 업데이트가 되었음.

원래 collaborator로 무찌가 초대가 안되었다면 상상도 못할일이다.

이렇게 한 레포지토리에 각 개발자가 접근권한이 생기고 코드를 업데이트할 수 있는게 바로 collaborator협업방식이다.

 

 

현재 코드 최신상태 업데이트하기

다시 팀장 nurd worker의 시점이다.

무찌가 이미 push를 한 상태이지만 팀장의 컴퓨터에서 해당 프로젝트 디렉토리는 무찌가 commit한 코드가 업데이트가 안된상태.

이럴때 업데이트를 하기 위해선 pull을 하면 된다

git pull <레포지토리주소> <브랜치>

이렇게 pull을 해오면 해당 레포지토리의 해당 브랜치상태가 업데이트 된다.

브랜치 자체가 전체적으로 공유되니까 사실 설명할게 별로 없는거같음.

 

 

무찌가 왜 main브랜치로 push하는데!

무찌는 아주 건방지기 때문에 팀장만이 다뤄야하는 main브랜치에 계속 push를 하고 있다. 이렇때 어떻게 제제를 할까?

레포지토리 admin을 제외한 나머지 collaborators들은 push를 할 수 없는 branch룰을 만들면 된다.

팀장은 해당 레포지토리의 setting을 들어가서 branches에서 add branch ruleset버튼을 클릭한다.

먼저 룰 이름을 정하자. 무찌를 막기위해 muzzi-stop이라는 이름으로 만들었다.

그리고 enforcement status를 active로 활성화해주자.

 

다음으로 add bypass버튼을 눌러서 repository admin을 선택한다. 그럼 role이 추가가 될거다.

아마 이 룰을 제한하지 않는 사용자? 방법같은 조건을 설정하는것같음.

repository admin을 선택한건 이 룰이 admin에게는 적용이 안된다는것이다.

main브랜치에 push할 수 있는건 이 레포지토리 주인인 nurd worker뿐이라는 뜻임.

 

스크롤을 내려서 target branch를 선택하자.

무찌가 main브랜치로 계속 push하므로 main브랜치에 이 룰을 적용한다는것.

include by pattern버튼을 클릭

main브랜치를 적어주고 add inclusion pattern버튼을 클릭.

참고로 패턴으로 했어서 조건식같이 적을수있다. 사진에 example이 나와있는데,

예를들어 dori라는 글자가 들어간 모든 브랜치에 push를 못하게 하려면 *dori*라는 패턴식을 입력해주면됨

그다음 룰을 정해주는데 push하지말라는거니까 update를 못하게 금지하면된다.

암튼 저거 하고  젤 아래 create 버튼 클릭하샘

 

# 테스트해보자

먼저 팀장이 test rule이라는 코드를 작성 한후, push를 했다.

잘 push 된걸 확인

 

그럼 무찌컴퓨터에서 push를 해보면?

무찌는 main브랜치로 push하는게 금지가 되어버렸다.

확인을 위해 muzzi-dev라는 브랜치를 만들어서 push를 해봤는데 이건 잘 되는걸 확인

 

이렇게 팀장은 제한을 할 수 있는거다.

 

 

pull request사용하기

난 fork로 협업할때만 pull request를 사용하는줄 알았는데 collaborator로 협업할때도 pull request를 사용할수 있더라?

해볼까?

위 상황에서 현재 muzzi-dev라는 브랜치에서 무찌가 코드를 업데이트 후, push를 해놨다.

브랜치룰을 또만들어보자~

 

팀장이 새로운 룰셋을 만들자. 이름은 걍 한글로 풀리퀘스트룰이라고 만들음

참고로 muzzi stop룰은 삭제해줬음.

타겟도 아까 룰이랑 똑같이하샘

룰은 저 require a pull request before merging을 체크하고

승인자수는 1, 코드 오너의 리뷰가 필요하다고 설정하자.

그리고 저장~

++ 추가해서 위에 무찌가 main브랜치로 push를 하는걸 금지하는 restrict update룰은 체크안하고 현재 pull request룰만 살려줘도 무찌는 main 브랜치에  push할 수 없다. 그냥 main브랜치가 변하려면 pull request가 있어야한다는 조건이라고 생각하면 댐

나도 몰랐던거라 테스트해봤는데 pull request로만 merge하는 브랜치라고 push자체가 안됐음.

두 조건 다 만들려면 지금 이 룰셋대로만 하면됨. restrict update도 같이하면 충돌나니까 걍 풀리퀘스트룰만 만드샘.

 

 

 

테스트 해보자~

 

일단 테스트를 위해서 걍 first commit으로 리셋했음.

 

무찌시점이다.

무찌가 muzzi-dev에 수정한 코드를 commit후, muzzi-dev 브랜치에 push 하였다.

muzzi-dev브랜치에 해당 커밋이 잘 올라왔다.

이제 무찌가 깃허브에서 pull request를 생성하자.

무찌는 main브랜치에 직접 push할 수 없으니 자기가 짠 코드가 있는 muzzi-dev브랜치 코드를 main에 merge해달라고 pull request를 보내는거다.

검토후 pull request ㄱㄱ

대충 적고 풀리퀘스트를 생성해주자

거부가 되었다. 리뷰어의 승인이 필요하다고 한다.

 

이제 팀장 시점이다. 해당 pull request를 확인해보자.

 

브랜치를 로컬에 가져와서 테스트는 해봤다고 가정하고.. 일단 코드가 맘에든다.

review를 추가해보자.

리뷰 내용을 적어주고 승인(approve)을 해주자

팀장님의 칭찬과함께 초록색체크표시가 빰빰하게 떴다.

팀장은 저 아래 merge pull request버튼을 눌러 최종적으로

이렇게 merge를 하자

 

 

 

무찌의 시점에서 무찌계정에 메세지가 와있었고 팀장님이 승인했다고 잘 떴다가

팀장님이 merge를 confirm하는순간

이렇게 된다.

 

암튼 이렇게 pull request로도 작업이 가능하다.

 

 

++ 추가해서 pr보내세요~ 막 이러는게 pull request라는걸 방금 코딩하다보니 알게되었다.. 소름 ㄷㄷ

 

 

 

collaborator에서 중요한건 뭘까?

fork에서 작업할때는 내가 내맘대로 설정한 협업방식에선 각각 개발자들이 본인 레포지토리 main브랜치를 기준으로 코딩을 하고  팀장 레포의 특정브랜치로 pull requet를  보낼 수 있었다.

때문에 초기 설정이 좀 복잡하고 코드 최신상태를 가져오는게 좀 짜쳤지만서도..

대신에 본인 레포에서 브랜치관리는 비교적 자유로운 느낌이었다.

하지만 collaborator로 협업할때는 한 레포지토리를 여러 개발자가 접근하니까 브랜치 작명, 및 운영이 굉장히 중요할것 같다는 느낌이 든다..

때문에 브랜치 네이밍 규칙 등을 만들어서 puppy world프로젝트를 진행해볼까?

 

 

 

 

시작하기에 앞서, 브랜치 종류 소개

1. main : 가장 중심이 되는 브랜치로 배포버전을 여기에 push merge함
2. develop : 개발할때 중심이 되는 브랜치
3. feature : 특정 기능을 개발할떄 만드는 브랜치
4. release : develop브랜치를 최종적으로 테스트하고 main 브랜치에 push하는 브랜치
5. hotfix : 중간에 버그가생긴걸 고치려고 만드는 브랜치. 버그고치고 develop과 main브랜치에 merge

이렇게 브랜치들을 만들건데 이건 git flow전략에서 브랜치 종류를 정리한거다.

대충 내가 이해한대로 짧게 적었는데, 여기서 주저리주저리 안적고 아래에 직접 해보면서 차근차근 해보면서 이해해보자.

 

 

 

# 환경셋팅

팀장인 nurd worker는 새로운 레포지토리를 팠다. puppy-project

위에 방법대로 collaborator들로 muzzi, dori개발자분들을 초대했고, main브랜치에 pull request룰을 만들어놨다.

그리고 각 개발자들이 로컬 디렉토리에 해당 프로젝트를 가져왔다.

 

 

 

main브랜치와 develop브랜치

현재 팀장인 nurd worker는 main브랜치가 있는 상태에서 develop브랜치를 만들었다.

구성도는 이렇다. 팀장을 포함한 모든 개발자는 모두 개발을 한 코드들을 develop브랜치에 merge한다. 

develop브랜치의 커밋이 잘 동작되는지 확인 후(이건 release 브랜치를 하는데, 좀따설명)

잘 동작된다면 팀장은 최종적으로 develop브랜치의 커밋이 main브랜치에 merge한다.

 

화살표 끝에 aws가 있는건, 인프라단에 cicd가 구성되어있으면 develop브랜치는 테스트용 인프라, main브랜치는 현재 배포된 인프라에 배포되는걸 표현하는거임. 브랜치에다가 각 인프라 cicd를 붙여주면됨

 

암튼 현재 app.js파일에 welcome코드가 있는 상태로 first commit이 복사되었다.

 

 

 

기능개발을 해볼까? feature브랜치

팀장님이 무찌에게 user기능을 만들라고 시켰다.

무찌는 user.js라는 파일을 만들고, 거기에 코드를 적어넣었다.

그리고 commit후에 push를 하였다.

레포지토리의 feature/user이라는 브랜치가 잘 push되었고, user.js라는 파일이 생겼다.

현재 이런 상태이다. 무찌가 feature/user이라는 브랜치를 만들었고, user.js라는 파일을 추가했다. 

그리고 user feature finish라는 커밋을 헀다.

이제 팀장님이 이 기능을 로컬에서 테스트해보자

테스트를 해보니 맘에드셨다. 따라서 무찌의 feature/user 브랜치를 develop 브랜치에 merge하였다.

그리고 레포지토리의 develop브랜치에 push했다.

레포지토리를 확인하니 user.js파일이 제대로 올라왔다.

무찌의 user feature finish라는 커밋이 develop브랜치에 merge되었다.

때문에 현재 develop브랜치의 최종커밋은 user.js파일이 있는 상태이다.

 

 

도리가 코드를 더 수정하고싶대! feature

 

팀장님은 무찌의 user기능이 맘에들어서 develop브랜치에 merge했다. 근데 도리는 무찌의 코드가 맘에 안든다. 때문에 무찌가 개발한 feature/user브랜치를 부모브랜치로 새로운 브랜치를 생성한다.

도리가 최신 업데이트 내용을 fetch하고 feature/user브랜치로 switch했다.

다시 새로운 기능을 개발할것이므로 feature/user_strong이라는 브랜치를 새로만든다.

기존 user기능이 단순하게 hello dog user라고하니까 너무 약해보여서 도리는 느낌표 두개를 더 붙여서 격히 환영하는 느낌의 코드로 수정을 헀다.

그리고 finish strong feature라는 커밋으로 레포지토리에 해당 브랜치 내용을 push하였다.

레포지토리도 이렇게 잘 push된걸 확인 가능.

현재는 이런상태이다. 도리가 feature/user_strong이라는 브랜치를 만들고

기존 feature/user브랜치 코드를 수정하였다.

이제 팀장님의 선택이 남았다.

팀장님은 도리의 코드도 맘에 들어서 develop브랜치에 merge후에 push하였다.

팀장님이 develop branch에 도리의 코드를 merge했으므로 최종적으로 도리의 최종커밋인 finish strong feature 커밋상태가 develop브랜치의 최종커밋이 된다.

 

 

드디어  강아지 개발자들과의 puppy 프로젝트가 완성되었다! 배포ㄱㄱ release브랜치

최종 도리의 commit인 finish strong feature을 가지고 만들거다.

팀장은 develop브랜치를 부모 브랜치로 해서 release/1.0.0브랜치를 만들자.

팀장은 releqse/1.0.0 브랜치로 switch한 후, 버전을 주석으로 입력하고 커밋한다.

release version 1.0.0 confirm이라는 커밋을 하였다.

그리고 레포지토리에 push하였다.

 

현재 이런 상태이다. 팀장은 release/1.0.0브랜치에서 최종 커밋을 하였다.

 

 

# 이제 배포를 위해 main브랜치에 pull request를 보내자~

잘 들어왔다. 이제 pull request를 만들자

깃허브 페이지에서 release/1.0.0브랜치를 main브랜치에 pull request하는걸 만들자.

잘 확인후 create pull request

엑스 뜨는건 룰셋 만들어놔서그럼.. 

강아지 개발자 muzzi가 승인.. 원래 이러면 안되는데..? pull request를 만든 사람은 리뷰를 작성 못하나보다. 무찌한테 시킬걸..

처음암. 암튼 중요한게 아니니 일단 mergeㄱㄱ

잘 됐다!

최종적으로 이렇게 깃 flow전략으로 1.0.0버전이 잘 배포가 되었다.

 

 

배포가 된 1.0.0버전에서 버그가 발견? / hotfix브랜치

배포되서 잘 굴러가던 우리 puppy project가 갑자기 버그가 발견되었따.

그래서 이걸 급하게 고쳐봐야한다.

이렇게 main브랜치의 1.0.0버전기준으로 hotfix/1.0.1브랜치를 만든다.

 

//main브랜치에서  자식브랜치 hot fix생성
git branch hotfix/1.0.1
git switch hotfix/1.0.1

코드를 fix bug라는 주석을 추가하여 버그를 고쳤다 ㅋㅋㅋ

이제 fix bug / 1.0.1이라는 커밋을 해준다.

참고로 hot fix로 버그를 고치면 버전이 약간 상승된다.

hotfix브랜치 상태를 레포지토리에 push

잘 업데이트가 됐다.

 

현재 fix bug /1.0.1이라는 커밋을 만들어준상태임

 

 

 

# 이제 pull request를 날리자!

hotfix 브랜치에서 중요한건, main브랜치에서 hotfix브랜치를 만든다는 점과

버그수정 후, 단순히 main브랜치에 merge를 하는게 아니라, develop브랜치에도 merge해줘야 한다는게 중요하다!

 

이번엔 무찌계정으로 pull request를 해보자

먼저 main브랜치로 hotfix브랜치를 merge해달라는 pull request

그다음 develop브랜치로 merge해달라는 pull request

 

두개의 pull request를 만드는거

nurdworker시점으로 두개의 pull request가 와있다.

둘다 받아주자.

 

develop브랜치는 뭐 룰셋 안만든 브랜치라 처음부터 초록불

main브랜치는 룰셋 만든 브랜치라 빨간박스로 리뷰쓰라고 나옴

(사실 충돌났는데 당연히 한 파일에 주석추가해서 수정된거니..암튼 대충 해결하고 계속 진행 ㄱㄱ)

 

둘다 머지 잘해줬음

최종적으로 이렇게 급한불을 끄는 hotfix브랜치를 만들어서 버그를 수정할 수 있다.

 

 

 

최종 git flow 아키텍쳐

 

 

이런식으로 puppy project 1.0.1버전이 완성되었따..

 

 

 

 

---

Conclusion

깃 포스팅 시리즈는 참 설정할게 많았다..
뭔가 단순한거 같으면서도 협업이 필요하니까 막상 그림이 잘 안그려저서 직접 해보자고
vm파고.. 각자 계정 따로만들고.. 솔까 개고생이었음..
같은 전화번호로 계정 여러개만든다고 블럭먹기도 했음 ㅠㅠ
그림작업도 많아야하니까..참

암튼 fork와 collaborator로 협업하는 시나리오로 포스팅을 했는데,
딱 어떤 방법만 써야한다 이런게 아니라, 두가지 기능을 적제적소에 갖다넣어서 혼용하는게 중요할것같다.
팀장이 이런 협업설계를 하는것이 중요할것같음. 팀원이 알아먹는것보다도..

사실 뭐 내가 쓴 포스팅이 틀린점도 많을거다. 실제로 깃으로 제대로된 개발 협업을 해본경험이 없으니까말이다.
실제로 취업후에 직접 맞닥뜨리고 배우는게 가장 최선일것같음.
암튼 ㅅㄱ