github 협업시 설정
- 협업을할때 해당 레포를 관리하는사람이 해줘야할 설정
해당 ref->settings->Branches->
위설정을 해주면 그 레포를 관리하는 사람이 아닌 계정에서는 절때 main(master)에 push나 merge를 할 수 없게 막아놓는 설정입니다.
그럼 위 룰을 비단 main브랜치에만 적용하는 것이 아닌
보호받아야 하는 브랜치가 생기면 그 브랜치에도 저 옵션을 달아주면
혹시 실수로 merge되는 실수가 생기더라도 github에서 그렇게 되지 않도록 관리 해 준다.
PR요청
- 위 설정 덕분에 main은 해당 ref를 관리하는 사람에게 안전하게 관리를 받을 수 있게 됐다.
그럼 협업을 위해서 다른사람들이 내 ref에 push를 하기위해선 브랜치를 따서 작업을 하는것이 강제 되는데 이때 그 브랜치에서 작업이 끝나고 작업 ref를 관리하는 사람에게 merge요청을 해야한다.
이게 바로 PR(pull Request)라고 합니다)
그럼 이 ref를 관리하는 사람이 보고 내 브랜치에 넣어도 될 것 같으면 merge를 해주고 안될것 같으면 거부할 수 있게 되는것입니다.
PR요청 하는 방법
해당 ref에 가서 pullRequest탭에 가면 다음과같은 버튼이있다.
들어가보면
다음과같은 화면이 나오는데 이때! 내가 내 브랜치를 어떤브렌치에 merge요청을 할것인지 선택을 해야한다.
당연히 팀원이 main에 merge요청 하면 겁나 혼날각오 해야한다.
위 사진에서는 main과 dev와 join_topic이렇게 새게의 브랜치가 있고 내가 작업한 브랜치가 join_topic이라면 dev에 merge요청을 하는 것이다.
- create pull request 클릭
위와같이 merge요청을 하는것이니까 main ref를 관리하는 사람이 알기쉽게 어떤 코드를 작성했는지 자세히 명세하고 Create pull request를 누르면 되는데 밑에 옵션에 Create draft pull request가 있다.
Create draft pull request 는 중간보고 같은 느낌 인 것이다.
아직 완료하지 않았지만 어떤지 리뷰를 받아보는 다음 옵션입니다.
main관리하는 계정에서 누군가가 push하면 자동으로 메일이 오도록 설정
PR 받아주기
그럼 팀원이 pr한걸 팀장이 다음과같이 코드와 변경사항을 쭉 둘러보고 위 Review changes버튼을 눌러서 위 사진에서의 세가지 옵션중에 하나를 선택할것이다.
- comment : deft로 리뷰요청이 왔다면 해당 코드에 대한 리뷰를 해주는옵션
- Approve : 팀원이 코드를 잘 작성해서 브랜치에 병합시켜주려고할때
- Requestchanges : 마! 코드를 이따구로 쓰냥! 병합 하지마!
그렇게 팀장이 Approve로 merge를 허락해 주면 팀장이 바로 merge를 해 줄 수 있지만 그렇게하면 팀장이 너무 힘들어 지기때문에 PR을 요청한 계정에서 직접 merge를 할 수도 있다.
하지만 소규모일때는 그렇게 책임을넘기기보단 팀장으로써 직접 merge를 하는것이 좋지않을까?....
요청 승인 시나리오 정리
팀원들아 잘 들어!
- topic 브랜치 생성
- 개발다 하고
- 로그 지저분하면 rebase해서
- topic을 푸시해
- 그리고 pr요청해
- 내가 승인을 하고 merge를 해줄게
- merge가 완료되면 github branch삭제해!
- git push --delete origin [브랜치명]
- 그리고 dev브랜치 pull해!!
거절 시나리오 정리
팀원이 위 3번 rebase를 안하고 commit로그를 지저분하게 남긴상태로 pr요청이 왔다 이럴때 팀장은 웬만하면 스쿼시 머지를 하지 않고 Requestchanges를 날려서 merge요청을 캔슬내면서 코맨트로 "마! rebase해서 다시 요청해 임마!!"이런거 날리고 팀원이 다음에 똑같은 실수를 하지 않도록 하는것도 방법이 될것 같다.
그럼 팀원이 팀장의 거절메시지를 보고 시무룩해져서 rebase로 로그를 깔끔하게 하고 다시 push를 하면 거절당한다.
왜냐하면 형상이 맞지 않기 때문이다.
그렇다고 pull을 먼저 하게 되면 내가 rebase로 로그 수정한게 다시 물거품이 되기 때문에 강제로 push한다.
- git push -f origin [branch]
rebase는 자신의 토픽(자신의 작업브랜치)내에서만 해야한다.
main에 merge 할때
ex)
1. git pull origin dev (개발브렌치 동기화)
2. git checkout main
3. git merge --no-ff dev(개발브랜치 merge)
- 프로그램이 완성됐다고 가정했을때
배포단계
4. git tag (프로그램명)(버전명)
5. git push --tags origin main
이후 배워야 할 지식
- aws
- 네트워크 개념
- 리눅스
- 직접 해보기
- 노가다 한계느끼기
- 배포 자동화(젠킨스,트레비스)
- 도커
위와같이 점진적으로 공부를 해 나가면 된다고 합니다..
그럼 이제 CI도구(젠킨스,트레비스,등등~)들을 이용해서 main에 푸시를 하게되면 바로 CI도구쪽으로 push돼서 test를 한 후에 배포를 하게된다.
자바로 치면 ci도구에서 테스트를하고 .Jar파일로 변경한후 배포 스크립트를 통해서 자동으로 클라우드에서 실행하도록 하는 등 여러가지 전략이 있다.
