[BlockCar][형상관리] Git

1570636062583

위 내용에 대해 정리해보겠습니다.

1. Rebase

형상관리에 대해 리서치를 하던 도중 배달의 민족 기술블로그를 통해 rebase에 대해서 알게 되었고, Rebase 방식을 사용할 경우 Git Grphq가 깔끔해지는 것을 보고 도입하기로 결정했습니다.

rebase는 말그대로 re + base 베이스를 다시 바꾼다는 의미입니다.
Merge는 병합을 하는 것인데, 병합을 하면서 새로운 Merge Commit을 만들기 때문에 그래프에 커밋 개수가 많아지게 되고 보기 어려운 형태의 그래프를 나타내게 됩니다.

아래 예시를 통해 설명하겠습니다.

위와 같이 master branch와 3개의 commit객체가 있는 상황에서

git checkout -b dev

위 명령어를 통해서 새로운 dev branch를 만들고 dev branch로 checkout을 하고, 커밋 명령어를 통해서 2번 commit을 했다고 가정해보겠습니다. 그러면 아래와 같은 그래프를 가질 것입니다.

위 상황에서 dev branch를 master branch로 병합하는 명령어를 실행해봅니다.

git checkout master
git merge dev

1567163201108

commit2를 가르키고 있던 master branch가 merge를 통해서 fast-forward되어서 dev와 같은 branch를 가리킵니다.

이렇게 보면 merge만 사용해도 이상적인 commit graph를 나타낸다고 생각할 수 도 있습니다. 하지만 제가 branch를 만들어서 작업을 하는 도중 팀원이 커밋을 진행했을 경우 아래와 같은 그래프를 나타납니다.

위 상황에서 master로 checkout을 해서 merge를 해주게 되면 그래프가 복잡해지는 상황이 나옵니다.

git checkout master
git merge dev

1567163388599

이렇게 하게되면 fast-forward가 아닌 새로운 merge commit을 남기게 됩니다.

그렇다면 rebase를 사용하면 어떻게 되는지 확인해보겠습니다.

1567163406817

글의 처음에서 얘기했듯이 rebase란 base를 다시 지정하다라는 의미입니다. 현재 dev branch의 root는 commit2로서 master가 가르키고 있는 commit보다 뒤에 위치합니다.

여기서 아래와 같은 명령어를 사용해봅니다.

git checkout dev
git rebase master

위 명령어는 dev branch의 base를 master로 사용하겠다는 의미입니다.

1567163420191

그러면 위와 같은 형태의 그래프가 나타나게 됩니다.

작업 후 commit 하기

git add .
git commit -m "수정 :  작업명"

현재 브랜치의 base를 origin develop으로 변경하기
```
git pull --rebase origin develop
```
원격 feature branch에 push 하기
```
git push origin feature/작업명
```
github으로 가서 feature/작업명 에서 develop branch로 pullRequest를 보내주고 받아줍니다.
dev branch 에 checkout 하기
```
git checkout develop
```
내가 rebase 해서 갱신된 develop을 local develop에 pull하기
```
git pull origin develop
```
작업했던 feature branch 삭제하기
```
git branch -D feature/작업명
```

삭제했다는 것을 원격에 알리기

git push origin --delete feature/작업명