[Git] 협업 처음 해보는 사람이 느낀 실무 협업 프로세스(merge 말고 rebase)

---

최근, 입사 후 첫 PR을 보냈다🎉

매번 master 브랜치나 깃헙 기준 main 브랜치에서 add, push 만 할 줄 알았지

깃을 알지 못했다고 봐도 무방하다.

 

실제 협업은 어떻게 이루어지는지 흐름을 정리해보려고 한다.

 

---

1. 자신이 수정 한 사항은 master 브랜치가 아닌 다른 브랜치를 따서 작업한다.

• master 브랜치 등 원본이 있는 브랜치는(통합 master라고 부르겠다) 절대 직접적으로 건드려서는 안된다.
• master 브랜치는 언제나 배포 가능한 상태, 안정적인 상태여야 한다.
• 브랜치를 딴다는 말은 브랜치를 새로 생성한다는 말이다.
• 기본적으로 작업 할 브랜치의 이름은 기능에 따라 feature, bugfix등으로 정한다. 아마 회사마다의 컨벤션이 있을 것이다.

// 브랜치 생성
git branch <branch-name>

// 브랜치 이동
git checkout <branch-name>

// 브랜치 생성 후 바로 이동
git checkout -b <branch-name>

// 브랜치 목록 보기
git branch

// 브랜치 삭제
git branch -d <branch-name>

---

2. 작업 후 master 브랜치에 병합하는 방법은 merge와 rebase가 있다.

 

커밋을 한 후 바로 push 하는 경우가 있는데 이는 잘못 된 방법이다.

원하는 만큼 커밋을 한 후 마지막에 push를 하면 커밋 이력이 나타난다.

 

merge는 그냥 git push origin master처럼 현재까지의 커밋 이력을 하나하나 살려 자세하게 병합을 시키는 것.

rebase의 squash는 말 그대로 커밋 이력들을 하나로 압축하여 병합시키는 것 이다.

 

커밋의 기록을 소중히 하는 사람이면 merge를 사용 할 것이고,

협업중이라면 필요한 기록만을 남기는 rebase가 적절하지 않을까?

예를 들어 5명이 협업하는 프로젝트라고 했을 때, 한 사람당 10개의 커밋을 했다고 쳐도 한 번의 merge에 50개의 기록이 생겨 이후에 커밋을 추적할 때 어려움이 생길 수 있다.

 

때문에, 10개의 커밋을 1개로 squash 시키는 방법이 rebase이다.

 

우선 커밋을 아래와 같이 세 번을 반복해 진행했다.

git log를 통해 기록을 확인하면 아래처럼 나온다.

이 로그에서 빠져나오려면 q를 누른다. 윈도우 git bash를 사용하면 q를 누르지 않아도 빠져나오는 것 같다. 맥은 그렇지 않음.

이제 이 세 개의 커밋을 하나로 rebase 할 것이다.

 

// 가장 최근에 진행한 커밋을 포함 3개의 커밋을 rebase
git rebase -i HEAD~3	

 

 

rebase 명령어를 입력하면 위의 화면이 나온다. 여기서 꽤나 애를 먹었는데, 아래의 과정으로 진행하면 된다.

 

1. i를 누르면 수정 가능 상태가 된다. 맨 아래 INSERT라고 뜬다.

2. 맨 위 커밋을 제외한 나머지 커밋을 pick 대신 s로 변경한다.

3. esc를 누르면 저장 가능 상태가 된다. INSERT가 사라진다.

4. :wq를 눌러 창을 빠져나온다.

엔터를 누르면 아래와 같이 squash 한 커밋들 중 삭제하고 남기고 수정할 수 있는 창이 뜬다.

이도 똑같이 i를 누르고 수정하면 된다.

삭제하고 싶은 커밋은 맨 앞에 #를 붙이고 수정하고싶은 커밋은 수정하거나 남겨두면 된다.

1 커밋을 새로 수정하고 나머지를 해쉬처리했다.

그리고 엔터를 누르면 성공적으로 리베이스 됐다는 말과 함께 수정했던 커밋만 남는다.

1, 2, 3으로 커밋했던 기록들이 사라지고 하나로 합쳐진 모습.

이대로 push 하면 된다.

---

3. pull request(a.k.a PR)

 

이후 최종적으로 push를 하면(작업 브랜치에 push 해야한다.), pull request를 만들 수 있다.

push를 하면 push 한 원격 저장소에 위와 같은 알림이 뜬다.

Compare & pull request를 누른다.

이런식으로 코드를 체크해달라는 pr을 보낸다(물론 저딴식으로 쓰면 안된다).

Create pull request를 누르면 아래의 창으로 이동한다.

동료들은 File changed 창에서 어떤 코드가 추가되고 수정됐는지를 확인하고 master 브랜치에 적용시키기 적합하다면 merge pull request 버튼을 누른다.

 

보라색으로 머지됐다는 알림이 뜨고 작업했던 브랜치는 삭제해야한다.

그리고 새 작업을 진행할 때 다시 브랜치를 따서 작업하는식으로 반복하면 된다!

 

---

깃의 명령어는 상당히 많고 방대하다.

오늘의 포스팅 목적은, 한번도 협업을 해보지 못한 사람으로서,

협업을 위한 깃 과정의 감을 잡고 훑기 위함이다.

중간중간 발생할 수 있는 돌발상황은 ... 화내면서 성장하면 된다...!😢