📢 어렵고 정석적인 개념 설명보다는 저같은 초보자도 이해하기 쉽게 정리하는 것을 원칙으로 포스팅하고 있습니다. 😄
개념
전 글에서 Git으로 관리하는 프로젝트를 GitHub를 통해 원격 저장소로 연결하는 방법에 대해서 배웠다.
이 글에서는 GitHub로 넘긴 다음 그 이후 커밋이 생겼을 때 혹은 커밋을 받아와야할 때, 어떻게 버전 관리를 해야 하는지에 대해서 알아볼 것이다.
방법
Push : 커밋한 내용 GitHub로 넘기기
git push
전 글에서 보면 프로젝트를 GitHub로 연결하기 위해서 3줄의 코드를 복사-붙여넣기 한 적이 있다. 그 코드 중 'git push -u origin main'이라고 있는데, 이것은 origin 원격의 main 브랜치를 지정한다는 뜻이다.
따라서 push를 할 때에도 미리 지정한 게 있기 때문에 'git push origin main'이 아닌, 'git push'만 적어도 된다.
Pull : GitHub의 커밋을 현재 내 로컬로 가져오기
git pull
pull 명령어 역시 push와 같은 이유로 'git pull'만 적어주면 된다.
우선 순위는 Pull ☞ Push (선Pull 후Push)
pull과 push에도 우선 순위라는 게 있다. 만약, A라는 항목이 있다고 할 때 로컬이 아닌 원격에서 A의 값이 a로 커밋되었고, 로컬에서는 A의 값이 b로 커밋되었다고 할 때 우선적으로 원격에서의 a값을 먼저 pull 해줘야 한다.
즉, 내가 push 할 게 있는데 누군가 프로젝트를 먼저 커밋한 게 있다면, 먼저 커밋된 내용을 pull 하고 그 이후에 내가 커밋한 내용을 push 해줘야 한다는 것이다. 한 마디로 로컬은 원격보다 뒤쳐지면 안 된다.
git pull --no-rebase // merge 방식
git pull --rebase // rebase 방식
앞에서 말한 것처럼 로컬이 GitHub보다 뒤쳐져 있으면 pull을 하고 그 다음 push를 해줘야 하는데, 이 때 그냥 단순히 'git pull'을 하면 오류가 발생하는 것을 볼 수 있다. 이미 로컬에서도 커밋한 내용이 있기 때문에 '병합'없이 불러올 수 없기 때문이다. 이를 해결하기 위해서 병합을 통한 pull을 먼저 해줘야 한다.
병합은 앞 글에서 다룬 적이 있듯이, merge 방식과 rebase 방식이 있다.
merge는 타임 라인을 하나로 맞춰주는 것이고 rebase는 타임 라인을 똑 떼서 메인 타임 라인에 붙여주는 것이다.
pull에서의 merge는 브랜치 병합에서와 똑같이 타임 라인을 하나로 붙여준다. pull에서의 rebase는 약간 다른데, 브랜치 병합에서는 단순히 똑 떼서 메인 브랜치에 붙여주는 거라면 pull에서는 로컬의 현재 커밋 바로 뒤로 원격의 커밋을 붙여주는 것이다. pull에서는 굳이 시간선을 나눌 필요가 없으므로 rebase 방식을 통해 깔끔하게 시간선을 맞춰주는 편이 좋다.
이런 과정으로 로컬의 최신화를 먼저 하고, 'git push'를 하면 그제서야 내 코드를 원격으로 넘길 수 있게 되는 것이다.
다만, 혼자 하나의 컴퓨터에서 프로젝트를 관리하는 경우에는 굳이 pull을 할 필요가 없다. (push하는 사람이 나 혼자이기 때문)
'Git' 카테고리의 다른 글
[Git] GitHub로 프로젝트 올리고 받는 방법 (0) | 2022.03.29 |
---|---|
[Git] 브랜치(Branch) 병합하는 방법 (merge, rebase) (0) | 2022.03.28 |
[Git] 또 다른 차원, 브랜치(Branch) 만들고 이동하기 (0) | 2022.03.22 |
[Git] Git의 commit을 기준으로 과거로 돌아가기 (0) | 2022.03.22 |
[Git] Git으로 프로젝트 관리하기 (add, commit) (0) | 2022.03.22 |