git 협업 가이드

git을 이용하여 여러 개발자들이 동시에 개발을 진행하고 버전을 관리할 수 있습니다.

오늘은 여러 사람들이 git을 이용하여 개발할 때 협업 시 이용하는 방법에 대해 말씀드리려고 합니다.

 

 

👉Feature branch

• 새로운 기능 개발을 위한 feature 브랜치 생성 시 마지막 develop 브랜치로부터 생성 됨
• 꼭 브랜치 생성 전에 develop 브랜치를 pull 받음

feature/{기능}

 

• feature 브랜치는 작은 기능 단위로 쪼개어 최대 10개 미만의 커밋으로 구성되도록 한다.
• feature 브랜치가 develop 브랜치에 성공적으로 병합되었다면 feature 브랜치는 로컬과 원격에서 삭제
• feature 브랜치 생성하기

git checkout -b feature/feature1

 

👉 Commit

• 기능, 타입 단위로 짧게 끊어서 커밋하고 한번에 작업한 내용이 많아도 커밋은 여러 번에 걸쳐 구분하여 커밋한다.
• 커밋 타입에 따라 구분하여 커밋하고 원격 저장소에서 push하여 다른 멤버가 자신의 작업 파일과 내용을 알 수 있도록 한다.
• commit 하기

git add Assets/someting.cs
git commit -m "feat : Change something"

 

• 원격 저장소에 작업 중인 브랜치 원격 저장소에 push 하기

git push --set-upstream origin feature/feature1

 

👉 Commit message

1. Commit Message Structure

→ 제목 / 본문/ 꼬리말로 구성

type : subject
body
footer

2. Commit Type

• feat : 새로운 기능 추가
• fix : 버그 수정, 기능 수정
• docs : 문서 수정
• refactor : 코드 리팩토링 (변수명 수정 등)
• test : 테스트 코드, 리팩토링 테스트 코드 추가
• style : 코드 스타일 변경, 코드 자체 변경이 없는 경우
• remove : 파일 또는 코드, 리소스 제거
• resource : 이미지 리소스, prefab 등의 코드와 상관없는 리소스 추가

3. Subject과거 시제보다는 명령어로 작성

→ 제목은 50자를 넘기지 않고 대문자로 작성하며 마침표 x, 과거 시제보다는 명령어로 작성

feat : Add translation to missing strings
feat : Disable publishing
feat : Sort list context menu
feat : Resize minmize/delete handle icons so they take up the entire topbar
fix : Fix typo in cleanup.sh file

 

4. Body

• 선택 사항이라 모든 커밋에 작성할 필요는 없음
• 부연설명이 필요하거나 커밋의 이유를 설명할 경우 작성하고 제목에서 한칸 띄워 작성
• 각 줄은 72자를 넘기지 않고 본문은 꼭 영어로 작성할 필요 없음

5. Footer

• 등록된 이슈 ID를 트래킹 할 때 주로 사용

6. Example Commit Message

feat: Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequenses of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

 

👉git stash

• 현재 작업 중인 브랜치에서 다른 브랜치로 checkout 해야 할 경우 커밋하지 않은 작업 때문에 checkout이 안될 수 있음. 이럴 경우 커밋하지 않은 작업을 stash 명령어를 통해 임시 보관하고 다른 브랜치로 checkout 가능
• 스택에 임시 보관한 작업들은 나중에 다시 꺼내와 마무리 가능

git stash
git checkout develop

# stash 목록 확인
git stash list

# stash 적용 (했던 작업 다시 가져오기)
## 가장 최근 stash 적용
git stash apply

## 원하는 stash 적용
git stash apply [stash 이름]

 

👉git rebase

• 여러 멤버가 동시의 각자 feature 브랜치에서 기능 개발을 하며 커밋을 하고 develop 브랜치에서 merge로 만들어진 히스토리는 브랜치가 꼬여 프로젝트의 히스토리를 확인하는데 복잡하고 이해하기 어려우므로 다른 멤버에게 잘 보여지도록 git rebase를 통해 원격 저장소에 Pull Request하기 전 프로젝트의 히스토리를 다듬어 준다.
• rebase 시행하기 전 원격 저장소에서 develop 브랜치를 pull 받아 원격 저장소에 그동안 반영된 커밋을 가져온다.

git checkout develop
git pull

• 현재 작업 중인 feature 브랜치의 커밋을 develop에 rebase 하기

git rebase develop feature/feature1

*주의! 이미 원격저장소에 push한 커밋은 rebase 안됨.

→ rebase 경우 기존의 커밋을 그대로 사용하는 게 아니라 다른 커밋을 새로 생성하는 것임

 

👉Pull Request

• feature 브랜치에서 기능 개발을 완료하면 develop 브랜치에 merge하여 원격 develop 브랜치에 push하지 않고 작업 중이먼 브랜치를 push 한 후 원격 develop 브랜치에 Pull Request 요청
• 만약 Pull Request 전에 rebase를 진행하면 push force 명령어로 원격 저장소를 강제로 갱신

<Pull Request>
origin/feature/feature1 -> origin/develop
Title: Add feature1 to somthing
body: 부연 설명 및 참고사항

• 원활하게 피드백을 진행하기 위해서는 PR단위가 크지 않도록 주의
• PR이 승인되어 merge commit 되었으면 merge된 feature 브랜치는 로컬, 원격 저장소에서 삭제
• 로컬 변경사항 무시한 채 업데이트

git reset --hard
git pull

 

👉git squash (git rebase -i)

• 여러 개의 커밋을 하나의 커밋으로 합치는 옵션
• 놓치고 같이 커밋하지 않은 파일이 있거나, 같은 커밋에 해당하는 작업이지만 커밋 이후에 작업을 했거나, 커밋 로그가 지저분하여 정리할 경우 사용
• 최근 커밋을 변경하고 싶을 때

git rebase -i HEAD~3

→ vi 에디터로 화면이 뜬다

pick 7c65355 Task 1/3
pick 2639543 Task 2/3
pick d442427 Task 3/3

# Rebase 2260a88..d442427 onto 2260a88
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell

→ 가장 위의 3줄을 원하는 옵션으로 변경하고 저장

pick 7c65355 Task 1/3
squash 2639543 Task 2/3
squash d442427 Task 3/3

→ 3개의 커밋을 하나로 합쳐 하나의 커밋으로 된다

Task 1/3 ~ 3/3

• git rebase 도중 conflict 발생하면 rebase가 멈춤. 이 때, conflict를 해결 후 git rebase —continue 명령어로 진행중이던 rebase 작업을 이어나갈 수 있음

 

👉git commit —amend

• git commit 메시지 변경할 경우 사용되는 명령어

 

👉git push —force

• 원격 저장소에 올린 커밋을 로컬에서 커밋을 되돌리거나 변경한 것을 원격 저장소에 강제로 반영할 때 사용되는 명령어
• 주로 PR을 수정하고 업데이트할 때 사용하거나 작업 중인 feature 브랜치에서 이미 원격 저장소에 push한 이후 로컬에서 커밋을 변경했을 경우 사용
• PR 수정 요청 사항 수정 후 commit > rebase > squash > push 할 때

git push -f origin feature/feature1

 

👉git cherry-pick

• 다른 브랜치에 있는 커밋을 선택적으로 혹은 전부 현재 작업 중인 브랜치에 적용시킬 때 사용하는 명령어
• 특정 커밋을 현재 작업 중인 브랜치로 가져올 때

git cherry-pick [커밋해시]

• 여러 개의 연속된 커밋을 현재 작업 중인 브랜치로 가져올 때

git cherry-pick [시작커밋해시] [끝커밋해시]

→ git cherry-pick 도중 conflict 발생하면 conflict 해결 후 git cherry-pick —continue로 진행 가능