Git 협업 방법

하나의 Repository 통해 협업 하기

• Repository를 만든 곳에 가서 fork 해서 내 Repository로 보내기
  

• fork 한 내 Repository를 로컬에 clone 한다.

• 본인이 사용할 branch를 만든다.

• clone 된 저장소에 프로젝트를 생성한다.

• 생성 후 본인이 만든 branch로 checkout 한다.

• 작업 후 본인 branch로 add -> commit -> push를 한다.

• push 후 해당 branch에서 main branch로 pull request(PR) 를 보낸다.

기능을 만들 때 branch를 생성해서 만드는 경우

• 기능을 만들기 전 branch를 생성 후 생성 된 branch 로 checkout 을 한다.

• 작업을 완료 후 checkout 된 branch 로 add -> commit -> push를 한다.

• push 후 본인 branch로 pull request(PR) 를 보낸 후 merge 한 후 main branch로 pull request(PR) 를 보낸다.

❗주의 사항

만약 기능 branch를 작업한 후 commmit만 한 상태(push 를 하지 않은 상태) 에서 다른 작업을 위해 다시 branch 를 생성할 경우 commit이 중복 될 수 있다. 그러므로 새로운 branch를 생성할 경우에는 rebase 나 pull로 본인 브랜치를 연결 후 작업해야 한다.

Pull Request (PR) 을 만드는 기준 ?

• 한 눈에 파악하기 좋은 / 리뷰 하기 좋은 기준을 정해서 PR을 만든다

• PR이 추가헀다 = 기능이 완료됐다 = 리뷰를 시작하면 된다

rebase 와 merge 차이

: Merge는 branch를 통합하는 것이고, Rebase는 branch의 base를 옮긴다는 개념의 차이가 있다.

rebase 와 merge 장단점

Merge

• 장점

1. 이해하기 쉽다.
2. 원래 브랜치의 컨텍스트를 유지한다.
3. 브랜치 별로 커밋을 분리해서 유지해준다.
4. 원래 브랜치의 커밋들은 변경되지 않고 계속 유지되어 다른 개발자들의 작업과 공유대는 것에 대해 신경 쓸 필요가 없다.

• 단점

모든 사람들이 같은 브랜치에서 작업하기 때문에 머지해야 할 때는 merge가 커밋 히스토리상으로 전혀 유용하지 않고 어지럽기만 하다.

rebase

• 장점

1. 단순한 히스토리
2. 여러 개발자들이 같은 브랜치를 공유할 때 커밋을 합치는 가장 직관적이고 깔끔한 방법

• 단점

1. 충돌상황에서 다소 복잡하다. 커밋 순서대로 rebase를 하는데, 각 커밋마다 충돌해소를 순서대로 해주어야 한다. SourceTree가 가이드하기는 하지만, 역시 복잡한 것은 사실이다.
2. 해당 커밋들을 다른 곳에 푸시한 적이 있다면 히스토리를 다시 쓰는 것에 부작용이 발생한다. Mercurial에서는 간단히 푸시를 할 수 없다. git에서는 push할 수 있으나 나 혼자 쓰는 리모트 브랜치에서만 가능하다. 만약 다른 사람이 그 브랜치를 체크아웃 받은 후 내가 리베이스 한다면 꽤 혼란스럽게 될 것이다.

rebase 와 merge 대한 자세한 내용

commit message 작성 꿀팁 !