1차 프로젝트 Git 사용기 및 Rebase

Minji Jeong·2021년 10월 21일
0

Git

목록 보기
3/3

1차 프로젝트를 시작하면서 Git의 전체적인 사용법을 익히게 되었다.
원래 commit, push밖에 할 줄 몰랐고 Git에 대한 두려움도 있었는데,
브랜치에서 작업하고, PR도 해보고, master에 있는 내용을 merge도 해보면서 많이 익숙해진 것 같다.
지금부터 1차 프로젝트 때, Git을 사용하면서 경험한 일들에 대해서 정리해보자!

Branch 속 Branch...

각 레이아웃/기능 마다 브랜치를 생성하여 작업한다.
그래서 정말 아무 생각 없이 새로운 작업에 들어갈 때 마다
git branch 브랜치명을 치며 브랜치를 생성했다.
분명 장바구니 기능을 구현하는 브랜치인데, 전에 작업했었던 Product Category 커밋들이 그대로 다 따라와져 있었다. Master로 가서 새로운 브랜치를 생성했어야 하는데, Product Category 브랜치 안에서 장바구니 브랜치를 생성해서 발생한 일이었다 😂

해결 방법

해결 방법은 master로 가서 새로운 브랜치를 만들고, 브랜치 속 브랜치에서 작업한 내용들을 가져오는 것이었다.
이 때, 다른 브랜치에 있는 폴더나 파일을 복사해오는 명령어
git checkout 가져올 브랜치 -- 파일 경로를 사용하였다.

Pull Request

GitHub는 단순히 버전 관리를 위해 코드를 저장하기 위해서만 사용하는게 아니었다.
Repository 내에서 팀원들 간에 커밋한 코드에 대한 리뷰를 남기는 등 프로젝트 진행 시 소통의 수단으로서도 적극적으로 활용할 수 있었다.

Git에서의 다양한 소통 과정 중, 가장 큰 역할을 하는 것이 바로 Pull Request가 아닐까 생각한다.
내가 작성했던 PR이다. 브랜치를 merge 하기 위해서 팀원들이 나의 작업 내용을 한 눈에 확인할 수 있게 어떤 부분을 구현했는지, 어떤 어려움이 있었는지 등을 정리하는 과정이다.
PR을 최대한 깔끔하고 성의있게 적으려고 노력했다.
그런데 프로젝트 마감일이 되면 될수록 merge 하기 바빠서 PR을 점점 대충 올리게 되었던 것 같다. 이 부분이 너무 아쉬워서 2차 프로젝트 때는 하나 하나 더 신중하게 적을 계획이다 ✍

merge

Merge는 '합치다' 라는 뜻이다. Git에서는 브랜치와 브랜치를 합친다는 뜻이다.

브랜치에서 작업한 내용이 마무리 되었을 때, 작업한 내용을 정리하여
Pull Request를 생성한다. Pull Request를 통해 conflict나 고쳐야할 코드들이 최종적으로 수정되면, 그 브랜치를 master에 merge하게 된다.

그러면 master는 브랜치의 내용이 합쳐진 내용으로 새롭게 갱신된다.
새롭게 갱신된 Repository의 Master를 내 Local에 있는 Master로 가져오기 위해
git pull origin master 라는 명령어를 통해 pull을 하게 된다.

내가 작업하고 있는 또 다른 브랜치에 master에 있는 새롭게 갱신된 내용을 가져오고 싶다면, 해당 브랜치로 checkout 한 뒤 git merge origin master 명령어를 입력하면 된다.

2차 프로젝트 때는 Rebase!

2차 프로젝트 때는 merge 대신 rebase를 사용하기로 했다.
Merge와 Rebase는 둘 다 브랜치와 브랜치를 합칠 때 사용하는 명령어인데, 합치는 방법이 다르다.

Merge

브랜치와 브랜치를 merge하게 되면, 커밋한 내역들이 시간순으로 그대로 합쳐진다. Merge를 하게 되면, 그 때마다 merge commit이 남는다.
Commit history를 보고 작업을 파악할 때도 많은데, history가 복잡해질 가능성이 높다.

Rebase

Rebase를 사용하게 되면 커밋 내역들이 시간순이 아니라,
commit의 base를 변경하여 commit history를 일렬로 정리해준다.
합치는 과정에서 merge 처럼 따로 커밋 메시지가 생성되지 않고,
같은 브랜치의 커밋 메시지들을 한군데로 모아주기 때문에 history도 훨씬 깔끔해지게 된다.

1.git rebase -i "브랜치명"

2. Interactive 모드에서 커밋들 중,
시간상 가장 오래된 커밋을 base로, 나머지는 base 커밋과 함께 squash 해주기 위해 base commit을 제외한 나머지 커밋의 앞을 s로 변경한다.수정하고 나면 esc:wq!를 입력하고 빠져나온다.

3. 합쳐진 git log를 본다. 원래 각각 뜨던 로그들이 한번에 뜨는 것을 확인할 수 있다.
4. push 한다. Commit History가 달라졌기 때문에 그냥 push를 할 수는 없다. 따라서 git push origin 브랜치명 -f 명령어로 강제 푸쉬한다.

5. Push 하던 중, Conflict가 발생하면 rebase 진행 도중 멈추게 된다.
그러면 충돌을 해결한 후, 다음 명령어를 입력한다.
git add .
git rebase --continue 멈춘 rebase 다시 진행
git push origin 브랜치명 -f

6. 혹시 rebase가 잘 해결되지 않는다면, git rebase --abort 명령어를 이용해 rebase 전으로 돌아간다.

Rebase를 사용했더니, commit history 들을 훨씬 깔끔하게 관리할 수 있었다.
한 PR당 한 커밋으로 정리할 수 있었고, 그 결과는 다음과 같다!
Rebase를 이번에 처음 써봐서 conflict가 발생했을 때 괜히 심장이 쪼그라들었었다... 😐
별거 아니라고 생각하고 싶지만 왠지 모르게 자꾸 conflict 뜰때마다 긴장이된다.
Rebase 하면서 conflict가 발생했었는데, 해결하고 나서의 그 안도감!
계속 쓰다 보니 점점 두려움이 없어지는 것 같긴 하다.

마지막으로 Conflict 해결하고 나서의 기분좋은 초록불 사진 투척~

profile
쿼카를 사랑하는 프론트엔드 개발자입니다 :)

0개의 댓글