remote (리모트)
앞서, 로컬의 코드를 서버에 올리고 다운받는 등의 행위를 한다고 말했다. 그러면, 로컬의 .git 폴더는 pull이나 push를 하고 싶을 때, 서버가 어디인지 어떻게 알고 있을까? 답은 간단하다. url을 써 주면 된다..
하지만 매번 주소를 써 주는 것은 아주 번거로운 일이다. 이럴 때의 해답이 바로 remote이다. 이는 간단하게, 주소에 대한 별명을 지정하는 것이다. 가령 내가 서버에 있는 https://github.com/my_id/rep_name repository에서 작업을 하고 싶다고 해 보자. push를 할 때마다 git push https://github.com/my_id/rep_name 어쩌구이라고 입력하느니, 저 링크에 대한 별명을 지정해 주는 것이 훨씬 좋은 선택이다.
git remote add origin https://github.com/my_id/rep_name와 같은 명령어를 통해 remote 주소를 추가할 수 있다. 이러면 우리는 git push https://github.com/my_id/rep_name 대신 git push origin 어쩌구라고 할 수 있고, 나아가 --set-upstream을 통해 자동으로 origin이 가리키는 곳으로 푸시하게 만들 수도 있다.
물론 이론상 remote 주소는 여러 개 등록할 수 있으나.. 일반적으로는 remote 주소는 origin이라는 이름으로 자신의 git repository 링크를 지정해 두곤 한다. 가끔, fork한 repository라면, 자기 repository 말고 fork한 원래의 repository도 fetch를 위한 remote로 등록해 두긴 하더라.
Branch (브랜치)
Branch를 시작하고서부터 비로소 Git을 사용한다라고 볼 수 있다. 사실 Branch를 빼면, 앞의 내용들은 조금 번거로워도 구글 드라이브에서도 다 할 수 있는, 아니면 그냥 폴더 복사해서 백업해 두는 걸로도 할 수 있는 '단순 코드 백업' 정도의 기능이다. 또한 여기부터는 직접 사용해 보지 않았다면 이해하기 힘들 것이다.
앞서 말했듯 Git은 분산형 버전 관리 시스템이기 때문에, 코드의 버전을 나눌 도구가 필요하다. Branch가 그 역할을 충분히 할 수 있다. Branch는 전체 repository의 한 버전이라고 보면 된다. 1.0 버전은 main 브랜치에서 분기하여 저장해 두고, main은 2.0 버전을 향해 나아가다가, 2.0이 완성되면 또 분기하여 저장해 두고 main은 3.0을 향해 나아갈 수도 있겠다. 사실 이는 아주 바보같은 방법으로, 실제로는 이렇게 하지 않는다. 보통 Branch를 어떻게 활용하는지는 3부에서 다룰 것이다.
repository를 만들면 자동으로 main Branch가 생겨 있고, 우리는 main Branch에서 작업을 하게 된다. 그러니, 이걸 나무의 기둥이라고 생각하면 되겠다. 여담으로, 원래 master였는데, 인종차별 관련 이슈로 인해 main으로 바뀌었다.
Branching(분기) & Merge (병합)
버전을 만들려면, Branch가 생길 시점이 필요하다. 마치 나무에서 가지가 자라듯, 원래 있던 Branch에서 새로운 Branch를 분기해 내야 한다. (그럼 branch가 하나도 없을 땐 어떡하냐는 바보같은 질문을 할 수도 있겠으나, 바로 앞에서 맨 처음에는 자동으로 main 브랜치가 생겨 있다고 말했다.)
이렇게 분기를 하게 되면 똑같은 코드를 가진 브랜치가 생긴다. 하지만 이 이후로 이 브랜치에 커밋하고 푸시하는 내용은 원래의 브랜치는 반영되지 않는 것이다. 그동안 원래 있던 Branch 역시 push를 계속 받으며 성장할 테니, 마치 나뭇가지가 자라는 것과 아주 유사하다.
또한, 브랜치는 분기되었다가 다시 합쳐질 수도 있다. 이 과정을 merge라고 한다. 하지만 딱 생각해 봤을 때, Branch A에서 Branch B가 분기했다 치고, A와 B가 성장하며 코드가 서로 달라졌을 것이다. merge할 때, git은 누구의 손을 들어줘야 하는가?
이에 대한 해답은 다음과 같다. 아까도 말했든, git은 commit 내역을 가지고 있다. 만약 commit 내역을 봤을 때, 어떤 특정한 파일의 특정한 줄에 대해,
- 두 브랜치 모두 분기 이후 독립적으로 성장하며 그 줄에 대해 아무런 수정을 하지 않았다면, merge는 아무 것도 할 게 없다.
- 한 브랜치는 분기 이후 그 줄을 수정 하지 않았고, 한 브랜치는 수정했다면, 수정한 놈의 손을 들어 준다.
- 둘 다 수정했다면, 아이쿠 큰일났네. 이건 3부에서 다루도록 하겠다.
아무튼, 이를 실무에서 어떻게 응용하냐,
main Branch는 언제나 배포되는 '무조건 정상적으로 작동하는' Branch이다. 여기에는 직접 push하지 않는다. main을 수정하고 싶으면, Branch를 파서, 거기서 수정해서, main으로 pull request를 날린다. 그러면 코드 구성원들의 테스트를 통해 버그가 없는지 확인한 다음, 버그가 없는 것이 확인되면 merge한다.
처음 보는 얘기가 너무 많이 나왔는데, 다 3부에서 다룰 거다.
Fork (포크)
얘는 살짝 흐름에 맞지 않는 딴 소리긴 한데, 어디다 넣어야 될지 잘 모르겠어서 여기에 넣는다. 다른 사람의 repository에 있는 코드가 탐스러워 내 repository 가져와서 사용하고 싶다면 fork하면 된다.
이때 이 repository는 내 서버에 저장되며, 어디서 fork해 왔는지 자동으로 뜬다. 이외의 기능들은 내 repository인 것마냥 쓸 수 있다.
