[Github] Not possible to fast-forward, aborting

[Github] Not possible to fast-forward, aborting

 

 

 

첫 번째 프로젝트를 얼렁뚱땅 끝내 놓고 무엇을 했는가, 부족한 부분이 무엇이었나, 얻은 것은 무엇인가, 어떤 방향으로 나가 봐야 하나 생각하고 있는 중이다. 그 가운데 깃을 가지고 협업을 할 때, 무엇인가 꼬이고 자꾸 원격 레포에서 내 푸시를 안 받아주고, pull을 당겨오니 내 것이 사라져 있어서 복구를 또 하고 해야 했던 기억이 떠올랐다.

 

많은 삽질이 있었지만, 깃은 협업 도구이다. 내 코드를 더 양산해주지는 않기 때문에 "어 됐다!" 하면 넘어갔었어서 더욱 기억과 기록이 남지 않았던 부분이기도 하다. 희미하게나마 존재하던 에러들을 끌어모아 모아 문제를 해결할 수 있는 방법을 기록해보고자 한다.

 

세 가지 부분 모두 깃에 대한 이해도가 부족했기 때문에 그런 것이다. 더불어 관련된 개념들을 보충적으로 살펴보고 기록할 것이다.

 

 

 

1. push을 할 때, 나타나는 오류(Not possible to fast-forward, aborting)

 

 

1) 문제와 해결책

 

Fatal: Not possible to fast-forward, aborting.

fast-forward가 아니므로 push를 중지한다는 메시지이다.

 

일단 해결 법은 간단한데,

git pull --rebase

를 하고 나서 push를 하면 잘 된다.

 

 

2) 발생 이유 - 기본 개념

 

왜 이런 일이 발생할까?

 

일단 merge와 관련된 지식이 없었기 때문에 그를 보충하고 갈 필요가 있다.

 

깃에서는 브랜치를 다른 브랜치로 합치는 과정을 merge라고 한다. merge의 기본 단위는 브랜치이고, git merge 명령어로는 커밋 단위로 합치기가 불가능하다.

 

(1) Fast Forward

 

가장 기본적인 merge 전략이 Fast Forward Merge이다. 이것은 현재 브랜치의 HEAD를 대상 브랜치의 HEAD까지 옮기는 merge이다.

 

 

 

만약 메인 브랜치에서 git merge feature-view 명령어를 실행하면, main 브랜치의 HEAD가 feature-view 브랜치로 옮겨진다. 

 

 

(2) Fast Forward 주의 사항

 

Fast Forward Merge는 중간에 변경이 없을 때만 동작한다. 만약 중간에 다른 커밋이 있거나 새로운 커밋이 같은 부분을 수정했다면 충돌이 일어나 제대로 동작하지 않는다.

CONFLICT(content): Merge conflict in (commit)
Automatic merge failed; fix conflicts and then commit the result

이럴 경우, 충돌하는 커밋들을 수동으로 병합을 해주고 새로운 커밋을 만든 후 브랜치 merge를 시도하면 해결이 된다.

 

 

3) 전략 선택 방법

 

둘 중에 하나의 방법을 택한다.

rebase 로 커밋들을 다루거나, merge 전략으로 커밋을 다룬다.

 

(1) fast-forward only 옵션을 끈다.

 

git config --unset pull.ff

이것을 깃 협업 사전에 하고, 진행을 해야 한다. 

 

 

(2) rebase false 명령을 내린다.

 

git config pull.rebase false

 

 

4) 이 문제에서 얻은 깨달음

 

: merge or rebase 전략을 제대로 알고 근본적인 해결을 해야 한다. 아무것도 모르고 어떤 명령어 뚝딱 치다가는 소중한 작업물이 날아갈 수도 있다. 어떤 커밋이 충돌을 일으키고 있는지, 브랜치가 어디에 있는지, 로컬 브랜치와 원격 브랜치가 얼마나 떨어져 있는지 등을 상세하게 살피고, 문제를 해결해야 한다는 것.

 

: 더불어 rebase의 경우, 나의 브랜치 안에서만 해야 한다. 다른 협업자들의 브랜치를 건드릴 수 있는 rebase를 하면 안 된다. 깃 히스토리가 꼬일 수도 있기 때문이다...

 

: 이 merge 전략으로 인해 automerging이 되고 하는데,,, 아직 더 깊이 이해하지는 못했다.

 

warning: Pulling without specifying how to reconcile divergent branches is
discouraged. You can squelch this message by running one of the following
commands sometime before your next pull:

  git config pull.rebase false  # merge (the default strategy)
  git config pull.rebase true   # rebase
  git config pull.ff only       # fast-forward only

You can replace "git config" with "git config --global" to set a default
preference for all repositories. You can also pass --rebase, --no-rebase,
or --ff-only on the command line to override the configured default per
invocation.

 

이 부분을 제대로 이해할 수 있을 정도로 git 이해도를 좀 더 높여야 할 듯 싶다...

 

 

 

2.  pull 할 때 에러 메시지

 

추가적으로 pull 할 때 자주 보는 메시지의 해결 방법은 아래와 같다.

 

Please commit your changes or stash them before you merge.
Aborting

merge: commit - not something we can merge

원격 레포지토리에서 소스를 pull 할 때 에러 메시지가 위와 같이 나올 때가 있다.

 

내가 수정한 파일을 다른 사람이 push 한 경우, 해당 파일에 충돌이 발생한다. 협업으로 인해 나올 수 있는 문제이다.

 

이에 대한 수정 방법은 오류문에 잘 나와있다. 커밋을 하거나 stash 명령으로 내가 작업한 것들을 임시 저장소에 저장하고 pull을 받아오면 된다.

 

 

 

3. 정리

 

모두 깃 정책을 제대로 세워놓고 초기 설정을 잘해두었고 팀이 그 규칙을 잘 지키면 일어나지 않을 것들이긴 하다.

첫 프로젝트는 깃... 을 정말 늦게부터 활용하기 시작했다.

조금 아쉽기도 한 부분인데, 다음에는 기본적인 정책과 작업 전후 규칙, 작업 중 규칙, 커밋 메시지 규칙 등 모든 것들을 사전에 잘 마련해 두고 프로젝트를 진행해봐야겠다.

 

아 그리고, 깃 문제는 언제나 '같이' 하거나 '과거로 돌아갔다 올 때' 생긴다는 것을 알았다. 어떤 커밋을 하였는지, 누가 파일을 삭제하거나 추가하지는 않았는지를 제대로 살펴보고 협업을 진행해야 합을 알았다.

(파일 누락 문제가 발생할 수도 있으니까...)