위와 같은 에러가 떴을 경우, 힌트로 제공된 세가지 옵션 중 하나로 상황을 해결한 적이 있을 것이다.
종종 마주치게 되는 에러인데 이번 기회에 정확히 알고 넘어가야겠다!
우선 먼저 위의 상황은 local과 remote의 싱크가 맞지 않아 브랜치가 갈라졌다는 것이다.
1. git config pull.rebase false #merge (the default strategy)
기존의 git pull 방식과 동일하다. pull을 받으면 불필요한 merge commit 이 생성된다. 3-way merge로 새로운 커밋을 만들어낸다.
2. git pull.rebase true # rebase
* rebase란?
로컬에서 변경된 사항을 patch로 만들고 이를 다시 remote에 적용시키는 것을 말한다. rebase 명령으로 한 브랜치에서 변경된 사항을 다른 브랜치에 적용할 수 있다.
local의 시작점을 remote의 마지막 commit으로 옮기는 개념으로 볼 수 있다. 그 과정에서 생기는 Conflict는 알아서 잘 해결해주면 될 듯 하다.
git history가 깔끔해진다는 장점이 있으나, 부주의하게 사용할 경우 별도의 알림 없이 git history를 영구적으로 변경할 수 있기 때문에 ff-only 방식을 더 권장한다고 한다.
3. git config pull.ff only #fast-forward
pull 하려는 원격 저장소의 브랜치와 로컬 저장소의 브랜치가 fast-forward 관계일 때만 pull을 허용한다.
두 브랜치가 fast-forward 관계라는 것은 갈라진 commit을 기준으로 아래의 둘 중 하나를 의미한다.
- 로컬 저장소에만 새로운 commit이 있고, 원격 저장소에는 없다.
- 원격 저장소에만 새로운 commit이 있고, 로컬 저장소에는 없다.
첫번째의 상황이라면 pull을 받아올 필요가 없으므로 두번째 상황일 때에만 pull이 가능하다.
이 말은 원격 저장소의 새로운 commit이 존재하는데 git pull을 하지 않은 상태에서 로컬 저장소에 새로운 commit을 했다면, git은 pull을 허용하지 않는다는 말이다.
간단히 생각하면 ff 방식을 권장하지만 상황에 따라 옵션을 잘 골라서 적용하면 되지 않을까 싶다.
또한, 이런 에러가 생기는 이유가 pull 당시 브랜치가 갈라졌기 때문이니, 수정 사항을 잠시 stash 해뒀다가 원격 저장소에 있는 수정사항을 pull하는 것도 하나의 방법일 듯 하다.
[references]
- https://blog.sffc.xyz/post/185195398930/why-you-should-use-git-pull-ff-only
- https://wikidocs.net/153693
'error' 카테고리의 다른 글
rbenv - BUILD FAILED (macOS 12.5 using ruby-build 20220725) (0) | 2022.07.26 |
---|---|
[git] ![rejected]master ->master(non-fast-forward) 해결 (0) | 2022.01.27 |