나는 지금까지 개인 프로젝트를 깃에 올리지 않았다. 수정할 때마다 새로 커밋하는 것도, 잘못된 명령어 하나로 로컬이 원격과 연동되어버리면 다시 복구하느라 시간 쏟는 과정이 아까웠다. 하지만 이제는 협업을 위해 배워야 한다.

개인 브랜치 사용: 로컬 코드를 원격 저장소에 올리는 코드

1. git status

2. git add .

3. git commit -m "설명 추가: 현재 변경 내용 요약"

4. git checkout -b <브랜치명>

5. git push origin <현재 브랜치명>

• git branch
• git push --set-upstream origin <브랜치명> // git push 만으로 자동으로 원격과 연결

개인 프로젝트면 커밋 후 푸시했을 때 충돌이 거의 안난다. 로컬 리포과 원격 리포에 차이가 없기 때문이다.

협업을 위해 git flow 를 배워보자. 용어가 왜 이리 많은지 정말 헷갈린다.

일단, 원격 상황을 내가 먼저 확인해야 내 개발 코드를 원격에 push할 수 있다. 

원격 상황을 pull / fetch - merge 로 확인할 수 있다. 

나는 개인 브런치로 사용 중이었다면 pull로 한 번에 받아서 사용했다.

• pull은 원격 저장소 최신 변경 사항을 가져오고 바로 로컬 브랜치에 합친다. 내부적으로 fetch + merge가 한 번에 수행된다. 

fetch는 원격 저장소의 모든 최신 커밋을 내 로컬에 복사해 놓기만 한다. 그래서 실제 내 로컬 브런치는 변화가 없다. 

• fetch 후에 git diff 를 이용하면develop 브랜치와 내 로컬 develop의 차이점을 확인해 충돌 가능성을 미리 볼 수 있다.
• fetch 후에 rebase하면 내 커밋을 가장 최신 커밋 뒤로 재정렬하여 내 작업이 가장 나중에 이루어진 것처럼 정리가 된다. 이 과정을 잘 해야 나중에 전체 코드와 병합할 때 내 커밋이 밀려서 이전 단계와 Merge 하는 등의 실수를 막을 수 있다. 
  • 그리고 커밋 그래프도 단순해진다.

원격 develop:
A --- B --- C   (최신 커밋들)

내 로컬 브랜치 (rebase 전):
A --- B --- C
             \
              D --- E

rebase 후:
A --- B --- C --- D' --- E'

merge 는 로컬 브랜치에 원격 커밋이 합쳐지는 과정으로, 발생하는 confilct는 수동 해결할 수 있다.

• 수동으로 conflict 수정 후 원하는 시점에 merge가 가능하다.

무지성 pull은 위험하다. 혹시 내가 기존 개발 흐름과 다른 새로운 기능을 개발 중이었다면 정말 위험하다.

pull은 원격에서 최신 커밋을 받고 즉시 로컬 병합하기 때문에 내가 수정한 부분이 사라지거나, 잘 돌아가던 로컬 코드가 갑자기 에러가 날 수 있다. 

때문에 내 코드를 원격 push 했다면, pull request를 통해 다른 개발자들로 부터 코드 리뷰를 받고, 안전하게 반영할 수 있도록 한다. 

요약

상황명령어

• fast-forward 병합은 다른 커밋이 없을 때 브랜치를 별도의 merge 없이 앞으로 쭉 민다.

main:     A -- B -- C
                \
feature/login:   D -- E

// fast-forward 후
main:     A -- B -- C -- D -- E
                         ↑
               feature/login

+ git log --oneline --graph --all 을 사용하면 지금 브랜치 상황을 그래프로 확인할 수 있다.

https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html

https://techblog.woowahan.com/2553/

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo