[Java 문법 종합반] 깃 2차 특강, 깃으로 협업하기

깃으로 협업하기

브랜치 활용하기

브랜치 생성 방법

• git branch 브랜치이름

브랜치 이동 방법

• git switch 브랜치이름 -> 권장함
• git checkout 브랜치이름 -> 현업에서 많이 사용

신규 브랜치를 생성하면서 이동

• git switch -c 브랜치이름
• git checkout -b 브랜치이름

브랜치 삭제 방법

• git branch -d 브랜치이름

브랜치 합치기

• git merge 대상브랜치
• 명령을 실행한 브랜치에 대상 브랜치가 합쳐짐
• 하지만 협업 시 PR(Pull Request)를 하기 때문에 협업시 활용하지 않음

원격 저장소의 브랜치 당기기

• git pull origin 브랜치명
• local 브랜치에서 원격 브랜치의 데이터를 당겨서 최신화 함(fetch + merge)

원격 저장소의 브랜치를 복제하기

• git clone 깃허브리포지토리주소 . : 현재 디렉토리에 깃허브 리포지토리의 데이터를 가져와서 해당 디렉토리 자체가 원격 저장소와 연결됨
• 만약 마지막에 .을 빼고 명령을 하면 현재 위치에 깃허브 리포지토리를 디렉토리로 가져옴 
• 즉, 내가 디렉토리를 생성 후 해당 위치에서 clone할경우 마지막에 .을 입력하고, 깃 허브 리포지토리를 디렉토리로 가져와서 그대로 사용할 것이라면 .을 제외하고 명령어를 입력하면됨

** 참고

• 다양한 git 명령어에 --force 옵션을 사용하면 강제로 모든 위험 사항을 무시하고 명령이 진행되니 정말 제대로 알고 사용하거나 가급적 사용하지 않는 것을 권장함

PullRequest(PR)

깃허브내에 코드 리뷰를 할 수 있는 장치

개발한 기능을 바로 merge하는 것이 아니라 PR을 올려서 코드리뷰를 하고 승인 후에 Merge를 해야함

 

push 후 깃허브에서 PR을하라는 창이 뜸

 

Compare & pull request 버튼을 누르면 이렇게 PR을 작성할 수 있는 공간이 나옴

만약 PR 템플릿이 있다면 거기에 맞춰서 글을 작성하면 됨

 

글을 작성할 때에는 최대한 자세하게 무엇이 변경되었고 어떤 부분을 개발하였는지 자세하게 작성하는 것이 좋음

 

글을 작성하면 이런 화면이 나오고 여기에 Files changed 탭을 누르면 변경 내용을 확인할 수 있음

Files Changed 탭에서 수정된 라인을 클릭하면 변경된 건에 대해 코멘트를 달수 있음

 

우측 상단의 Review changes 버튼을 누르면 Comment, Approve, Request changes을 선택하여 코멘트를 남길 수 있음

• Comment: 위에서 설명한 코멘트와 동일하지만 특정 구역이 아니라 PR 문서 하단에 코멘트를 남김
• Approve: 승인을 뜻함, 승인이 몇개 이상되어야 Merge를 할 수 있는 등의 규칙을 정할 수 있음
• Request changes: 코멘트로 남긴 내역을 수정할 때까지 Merge를 할 수 없도록 제한함

 

모든 문제가 없어서 merge를 하기 위해 Merge pull request 버튼을 누르면 아래의 창이 뜨게 되고, Confirm merge를 누르게되면 PR을 올렸던 브랜치가 merge가 됨

 

merge가 완료 되면 Delete branch를 눌러서 해당 브랜치를 삭제 해주는 것이 좋은데, 어차피 commit 내역으로 과거의 이력을 볼 수 있고 브랜치가 너무 많으면 오히려 히스토리를 파악하기가 너무 어려움

 

이렇게 merge가 완료 되면 local에서 merge가 실시된 최신 브랜치를 pull이나 clone으로 가져와서 새로운 추가 기능을 개발하면 됨

실전 가이드

브랜치 종류

• main 브랜치: 배포용(프로덕션용), 실제 사용자가 사용하는 서비스
• develop 브랜치(dev): 개발용, 개발 단계에서의 최신 코드 관리
• feature 브랜치(feat): 기능 개발용, 기능 개발할 때마다 추가
• 즉, 기능 개발을 한 feature(teat)브랜치는 바로 main에 머지하는 것이 아니라, develop(dev) 브랜치로 머지해야 함

기능 개발 후 PR 전에는 항상 최신 dev 브랜치를 pull을 해서 충돌을 방지하는 것을 권장함

• 기능 개발 후 바로 PR 올리는 것이 아니라 dev 브랜치를 기능 개발한 곳으로 pull을 먼저 진행하여 충돌이 없는지 확인한 후, dev 브랜치로 PR을 올려야 함
• 그냥 올릴 경우 충돌이 발생하면 어차피 해결해야 하는데 github 환경에서는 불편하기도 하고, 일정라인 이상 충돌이 발생하면 어차피 local에서 해결하라고 안내문구가 뜨기 때문에 애초에 local 환경에서 IDE의 도움을 받아 하는것을 권장함

프로젝트 시 깃, 깃허브 세팅 순서 정리

1. 초기 세팅

• 프로젝트 생성 및 git init, add, commit 진행
• github repository 생성 후 프로젝트의 디렉토리와 remote, push 진행
• 이 과정에서 필요한 gitignore, gitconfig, readme, PR 템플릿이 있다면 함께 push 진행
• dev 브랜치 생성 후 push

2. defulat 브랜치를 생성한 dev 브랜치로 변경

• main 브랜치에 PR을 실수로 올리는 것을 방지하기 위해 기본 브랜치를 변경
• repository setting -> General -> Default branch 이동
• switch to another branch 클릭 후 dev 브렌치로 변경 및 Update 진행
• I understand, update the default branch 클릭

 

3. 팀원 초대

• repository setting -> Collaborators -> Add people 눌러서 함께 작업할 팀원을 선택

위의 초기 세팅이 끝나면 이후 팀원들은 해당 브랜치를 clone한 뒤 각자 개발할 feature 브랜치들을 만들어서 개발을 시작하고 기능 개발 수 PR을 할 때에는 최신 dev 브랜치를 먼저 당겨서 충돌을 해결한 후에 PR을 하는 방식으로 진행하면 됨

 

룰 적용

• repository setting -> Branches 에서 강제로 push를 못하게 하거나, PR에서 승인 개수를 지정하는등의 룰을 정할 수 있음
• Add branch ruleset은 좀 더 디테일한 작업이 필요한 경우 사용하며, 대부분의 소규모 프로젝트의 경우 Add classic branch protection rule에서 Branch name pattern에 브랜치 이름을 작성하고 옵션을 적용해 주면 됨 
• Require a pull request before merging
  • 해당 옵션에서 병합 전에 필요한 Approve의 수를 지정할 수 있음
  • 일반적인 프로젝트에서는 너무 많이 지정하면 오히려 병목이 생기기 때문에 적당한 수로 지정하는 것을 권장함
• Allow force pushes: 강제 푸시를 할 수 있는 권한을 설정할 수 있음
• Allow deletions: 푸시 엑세스 권한이 있는 사용자가 일치하는 브랜치를 삭제할 수 있도록 허용할 수 있음

 

깃  전략에 대한 부분은 인터넷에 많이 나와있지만, 아래의 두 블로그의 글만으로도 충분히 잘 나와있으니 참고하면 됨

• https://devocean.sk.com/blog/techBoardDetail.do?ID=165571&boardType=techBlog
• https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5