git 협업하기

Github 로 협업하기

1. github collaborator (협업자) 로 등록하기

repo > Settings > Collaborators > add people

이름 또는 이메일 입력 후 초대하기

초대받은 사람이 이메일에서 초대를 수락 해야 협업자가 됨

해당 repo 에서 push, pull 등 가능

 

2. git clone 으로 프로젝트 시작하기

git clone [repo 주소]

git clone

• epo 를 그대로 내 컴퓨터로 가져오고 싶을 때 사용하는 명령어
• 단순한 다운로드와는 다르게 commit 기록, history 를 모두 가져옴
• git reset 명령어를 통해 이전 기록으로 돌아갈 수 있음
• pull, push 등을 통해 실제 repo 에 수정 사항을 반영하거나 내려받을 수 있음

 

clone 을 통한 협업 방법

• 팀장이 repo 를 생성함
• 팀원들을 해당 repo 의 collaborator 로 등록함
• 팀원들은 팀장의 repo 를 clone 받아서 사용함
  • collaborator 로 등록되면 push, pull 권한이 있기 때문에 repo 를 함께 관리할 수 있음

 

git fetch 를 통해 수정사항 확인하기

git fetch

깃허브 상의 수정사항을 바로 내 컴퓨터에 반영하는 것이 아니라

우선 내 컴퓨터의 다른 branch 로 수정사항을 가져오고,

원할 경우 해당 branch 로 checkout 해서 수정사항을 받아오는 명령어 (브랜치 형태로 받아옴)

 

존재하는 브랜치 확인

git branch -r

 

브랜치 변경 (수정사항 반영)

git checkout [수정사항을 가져올 브랜치]

 

3. fork 로 원격 저장소 복제하기

fork

• 다른 사람의 repo 를 복제해서 내 repo 를 새로 만드는 기능
• clone 과 마찬가지로 파일 뿐만 아니라 commit 기록까지 모두 복제함
• fork 한 repo 는 내 소유이기 때문에 자유롭게 clone, push, pull 가능

 

clone vs fork

• clone : 다른 사람이 만든 repo 그 자체를 내 컴퓨터에 받아오는 기능
• fork : 다른 사람이 만든 repo 를 복제해서 새롭게 내 repo 를 만들고, 내 repo 를 내 컴퓨터로 받아오는 기능

 

연결되어 있는 repo 확인

git remote -v

// origin https://github....

 

원본 repo 를 upstream 이름으로 추가

git remote add upstream [원본 repo 주소]

 

원본 repo 수정사항을 내 컴퓨터에 반영

git pull upstream [브랜치 이름]

 

내 컴퓨터 수정사항을 내 repo 에 반영

git push origin [브랜치 이름]

 

pull request

• 내 컴퓨터 수정사항을 원본 repo 에 반영
• 해당 repo 의 관리자에게 내가 수정한 코드를 원본 repo 에 반영하는 것을 부탁하는 기능
• 보통 관리자가 코드 리뷰 진행 후, 반영 여부를 결정하고 실제로 반영함

수정사항 push > github repo 페이지 > Ctrate pull request 버튼클릭

1. 무엇을 수정했는지 요약해서 작성함
2. 작성한 pull request 에 대해서 사람들이 코드 리뷰를 comment 형태로 작성함
3. 관리자가 해당 코드를 현재 프로젝트에 merge 함

 

fork 를 통한 협업 방법

큰 단위의 프로젝트일 경우 바로 원본 repo 에 대해서 clone 을 사용하지 않고

하나의 큰 repo 를 생성한 후, 팀/사람 별로 fork 를 해서

각자 팀마다 하나의 repo 를 관리하는 방식으로 협업이 이루어짐

 

팀 repo 에서 수정사항이 있다면

pull request 를 작성하여 원본 repo 에 해당 수정사항을 반영해 달라고 요청하게 됨

 

그 후 최종 관리자 / 코드 리뷰어가 해당 코드를 보고

합쳐도 된다고 판단이 될 경우 해당 코드를 원본 repo 에 반영시킴

소규모 스타트업에서는 fork 까지 사용하지 않고, 대부분 clone 으로 처리함

 

1. 원본 repo 를 안전하게 관리할 수 있음
2. 팀/사람 단위로 작업 사항을 관리할 수 있음

---

Github 에서 Branch 활용하기 (Pull Request)

1. Pull Request 의 개념과 목적

나의 담당 브랜치에서 작업이 완료되었으니

이 브랜치의 코드를 가져가서 병합해 달라고 요청을 보내는 것

 

현업의 git 관리 방식

1. main 브랜치

사용자가 이용할 서비스의 코드가 담기는 브랜치

 

2. develop 브랜치

사용자에게 서비스를 배포하기 이전에 모든 기능들이 통합되어서 테스트를 진행하는 브랜치

테스트 완료 시 main 브랜치에 코드를 통합해서 실제로 사용자가 이용하는 서비스에 코드가 반영됨

(보통 테스트용 브랜치가 따로 존재함)

 

3. feature ~ 브랜치

서비스의 기능을 분할해서 기능 하나를 구현하는 브랜치

하나의 기능 구현이 완료되면 develop 브랜치로 내 코드를 통합해달라고 요청을 보냄

 

Pull Request 를 하는 이유

1. 내가 작성한 코드가 바로 merge 될 경우 발생할 수 있는 문제 미리 방지
2. 현재 코드에 대한 코드 리뷰 진행
3. 프로젝트에 대한 진행 상황 관리

 

2. Pull request 사용해보기

git add + commit + push 후

github repo 에서 Compare & pull request 버튼 클릭 후 내용 작성

 

Pull Request 작성 내용

• 현재 PR 요약
• 코드 변경 이유
• 관련 스크린샷
• 테스트 내용
• 리뷰 관련 요청사항

 

3. Pull Request 에서 코드 리뷰 작성 후 병합하기

add single comment: 바로 해당 코드 부분에 대해 코멘트를 달 수 있음

start a review: 코드의 여러 부분에 대해서 코멘트를 작성한 후 finish your review

• 바꿀 것이 없을 경우: approve (승인) 체크 후 submit review
• 바꿀 것이 있을 경우: request changes (수정 요청) 체크 후 submit review

 

코멘트 단 부분이 잘 수정되었으면 resolve conversation

리뷰 사항에 대한 수정이 모두 이루어졌을 경우 관리자가 merge 진행

 

Delete branch 버튼을 클릭하여 해당 브랜치 삭제 가능

이미 해당 브랜치에서 할 작업이 끝났기 때문에 작업중인 브랜치만 남기고 모두 삭제

 

pull request > closed 클릭 시 지금까지 진행된 작업 확인 가능

 

4. pull request 완료 후 로컬에 반영하기 (git fetch --prune)

git pull origin main

로컬 main 브랜치의 파일이 github 와 동일해짐

 

git fetch --prune

컴퓨터가 pull request 이후 github 상에서 삭제된 브랜치들을 인식함

git pull 과정에서 발생할 수 있는 오류 방지

 

git branch -D [삭제된 브랜치 이름]

pull request 가 merge 된 이후 로컬 브랜치 삭제

 

4. Pull request 시의 merge conflict 해결해보기

PR을 보낸 후 this branch has conflicts that must be resolved 라는 경고문이 뜸

바로 merge 할 수 없고 conflict 를 해결해야 한다는 뜻

 

여기서 resolve conflicts 버튼을 누르고 conflict 를해결하기 보다는  

아래처럼 vscode 상에서 해결하는 것이 좋음

git switch [merge 하려는 브랜치]
git pull origin [merge 하려는 브랜치]
git switch [conflict 브랜치]
git merge [merge 하려는 브랜치]

// 충돌 해결

git add .
git commit -m "Etc: Merge ...."
git push origin [conflict 브랜치]

커밋 이력이 충돌나지 않게 정리된 상태로 github 에 올라감

이미 pull request 를 생성한 상황에서 해당 브랜치 내부 파일을 수정한 후에 push 하면

새롭게 pull request 를 생성하지 않아도 자동으로 해당 pull request 에 수정사항이 반영됨

---

Github 자체 기능 활용하기 (issue, milestone 등)

1. issue, label, milestone 의 개념

issue

앞으로 구현할 기능 / 버그 fix 등의 할 일을 정리해놓는 용도로 사용

오픈 소스 프로젝트에서는 버그를 제보하기 위한 용도로 사용하기도 함

issue 상세 페이지에서 close 시 milstone 진행 상황에 반영됨

 

label

특정한 issue 가 어떤 카테고리에 해당하는지 알려주는 역할

 

milestone

issue 의 집합

작업이 완료된 issue 가 얼마나 있는지에 따라 진행 상황을 %로 표시해 줌

 

순서

1. milestone 생성
2. label 생성
3. issue 생성 + milestone, label, assignee (담당자) 선택

 

2. issue 와 pull requert 함께 사용하기

Pull request 작성 시 Close [이슈 번호] 를 넣어주면 해당 PR 과 Issue 가 연결됨

해당 PR 이 완료되면 자동으로 해당 Issue 가 close 되면서 완료 처리됨 (마일스톤에도 반영됨)

close 가 아니더라도 다음과 같은 단어 사용 가능

• close
• closes
• closed
• fix
• fixes
• fixed
• resolve
• resolves
• resolved

---

Git 관리 전략

1. git commit convention 정하기

// 제목
Feat: "로그인 함수 추가"

// 본문
로그인 요청을 위한 함수 구현

// 꼬리말
Closes: #123

 

커밋 메시지 작성 규칙

1. 제목과 본문은 한 줄을 띄워서 작성
2. 제목은 영문 기준 50자 이내로 작성
3. 제목 첫글자는 무조건 대문자로 작성
4. 제목 끝에 마침표는 찍지 않음
5. 제폼은 개조식으로 작성 (ex. Update code, Fix bug ...)
6. 본문은 영문 기준 72자마다 줄바꿈
7. 본문은 무엇을, 왜에 맞추어 작성

 

커밋 제목 작성 규칙

1. 50자 이내
2. 대문자로 시작
3. 마침표 없이 작성
4. 개조식으로 작성
5. "타입: 내용" 형식으로 작성

 

커밋 타입

• Feat : 새로운 기능 추가
• Fix : 버그 수정
• Env : 개발 환경 관련 설정
• Style : 코드 스타일 수정 (세미 콜론, 인덴트 등의 스타일적인 부분만)
• Refactor : 코드 리팩토링 (더 효율적인 코드로 변경 등)
• Design : CSS 등 디자인 추가/수정
• Comment : 주석 추가/수정
• Docs : 내부 문서 추가/수정
• Test : 테스트 추가/수정
• Chore : 빌드 관련 코드 수정
• Rename : 파일 및 폴더명 수정
• Remove : 파일 삭제

 

커밋 본문 작성 규칙

1. 한 줄당 72자 이내
2. 최대한 상세히 작성
3. 무엇을, 왜 변경했는지 작성

 

꼬리말 작성 규칙

• 선택 사항임
• "유형: 이슈번호" 형식으로 작성
• 이슈를 닫는 메시지는 본문에 작성하기도 함
• 유형은 "Close, Fix, Resolve" 등을 활용
  • Close: 일반 개발 이슈를 닫을 때
  • Fix: 버그 이슈를 닫을 때
  • Resolve: 문의/요청사항에 대한 이슈를 닫을 때

 

커밋 메시지 줄글 형태로 작성하기 (vim 편집기 실행)

git commit

 

2. issue, pull request template 만들어보기

issue, pull request 를 작성하기 위한 틀을 만들 수 있음

시간 단축 + 팀원 간 작성 양식 통일 가능

 

.github/pull_request_template.md

## 작업 개요 (이슈 번호)


## 작업 내용 (변경 사항)


## 스크린샷


## 테스트 결과


## 리뷰 요청 사항

 

.github/issue_template.md

## 목적


## 세부 내용

 

repo > Settings > General > Issue 에서 Get organized with issue templates 버튼 클릭 시 여러가지 템플릿 추가 가능

 

3. branch protection 을 통해 branch 보호하기

repo > Settings > Branches > add Branch protection rule 버튼 클릭 

Branch name pattern 에 브랜치 이름 또는 패턴 작성 (main, feature* ...)

필요한 보호 옵션 선택 가능, 주로 아래 옵션들 사용

 

Require a pull request before meging

- merge 이전에 pull request 가 필요 (pull request 를 통해서만 해당 브랜치로 merge 가능)

 

Require conversation resolution before merging

- 코드 리뷰에 달린 conversation 이 모두 해결 (resolve) 된 경우에만 merge 가능

 

Do not allow bypassing the above settings

- 그 누구도 위 보호 옵션을 우회할 수 없음 (repo 관리자도 불가능)

 

4. git pull 시 발생하는 에러 해결하기

hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint:  git config pull.rebase false # marge (the default strategy)
hint:  git config pull.rebase true  # rebase
hint:  git config pull.ff only.     # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rabase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.

해당 에러는 현재 로컬 브랜치의 커밋 이력과, 리모트 브랜치의 커밋 이력이 충돌하는 경우 발생함

git pull 의 원리는 리모트 브랜치와 로컬 브랜치를 merge/rebase 를 통해 합치는 것으로 이루어짐

이 에러는 git pull 을 할 때 merge/rebase/fast-forward merge 중에 무엇을 선택할 지 지정하라는 에러임

 

git pull origin main --no-ff

git config pull.rebase false 명령어로 git 설정 자체를 바꾸는 것 보다는

정확히 내가 원하는 pull 형태를 지정하는 것이 좋음 (--no-ff: no fast forward merge 방식으로 pull 진행)

이후 confilct 부분을 수정한 후 commit 하면 해결 완료

---

Github 를 활용한 협업

1. 우리 팀만의 git flow, commit convention, issue/pr template, issue label 을 정함
2. 팀장은 해당 template 등을 적용한 github repo 생성 / 팀원 등록
3. 앞으로 구현할 작업을 기능 단위로 세분화
4. 기능 단위의 작업에 대해 각자 담당을 정함
   • 각 담당자는 github 에 해당 기능에 대한 issue 생성
   • 팀장은 작업기한을 정해서 milestone 생성
5. 팀장은 github repo 에 최초 commit/push 진행
   • 이후 branch protection 설정
   • 구현할 기능에 대한 파일들/폴더 트리까지 모두 생성한 상태로 최초의 push 진행
6. 팀원은 해당 repo 를 clone 받음
   • 각자 기능에 대한 branch 생성 후 작업 진행
   • 작업 완료 시 main 브랜치로 pull request 를 보냄
   • 팀원들은 pull request 된 코드를 보고 코드 리뷰를 남김
   • 수정사항이 모두 해결이 되면 approval 코드 리뷰를 남김
7. 팀장은 approval 코드 리뷰가 있는 pull request 에 대해 merge 진행
   • merge 완료 후 관련 issue 가 닫히고, milestone 에 진행 상황이 업데이트 됨

 

주의사항

• 팀원 간에 브랜치 명 통일 (feature / ) 필요
• 이슈 활용 시에는 이슈번호를 브랜치에 같이 작성해줘도 좋음
• close 와 관련해서, 커밋 메세지에 작성을 해도 되고, pr 안에 작성을 해도 됨
• 라벨 관련해서, 커밋 메세지 타입에 맞춰서 직접 라벨을 만드는 것을 추천
• issue, pr 의 경우에도 접두사를 만드는 것을 추천
• wiki / readme.md 에다가 우리팀만의 convention 을 정리
  • (커밋 메세지에 쓸 타입들을 전부 readme.md 에다가 정리해놓고 거기 맞춰서 진행)
• 팀장이 하는 첫번째 커밋에도 Env: 등의 commit type을 붙이는 것을 추천