Git, Github 기초 뽀개기 👊 (2)

대망의 2탄

 

 

 

서론

스터디 1주 차(2)를 맞이했다.

1주 차(1)에서는 init, add, commit, push ... github 연동까지 알아봤었다.

이번에는 pull, branch, switch, merge, reset ... 등등에 대해 공부했다.

읽어도 읽어도 뭔 소리야 .. 싶은 경우가 많았기 때문에 아래 사이트를 이용하여 실습했다!

Git 공식문서

Git / GitHub 안내서

브랜치 연습하기!

역시 실제로 해봐야 이해도 되고 늘기도 하는구나. 그래도 역시 협업을 해보며 부딪혀 보고 싶다는 생각이 들었다.

실습, 공부하며 새롭게 알게된 (이해한) 지식들을 까먹지 않기 위해!! 적어둔다.

 

 

 

 

---

 

 

 

branch ?

나무에서 여러 갈래로 나누어지는 가지들을 떠올리면 이해가 쉽다.

여러 사람이 동시에 여러 작업을 진행하고 작업이 끝나면 다시 합치는 과정! 이 가능하다.

브랜치는 부모 브랜치가 가지고 있는 파일들을 그대로 가져온다.

그리고 그 상황에서 추가, 수정을 할 수 있다.

 

⚠️ 충돌 (Conflict)

각자 다른 브랜치에서 똑같이 존재하는 A.html 이라는 파일을 수정했다고 치자.

작업이 끝나고 브랜치를 합치려고 할 때 오류가 발생한다. CONFLICT !

👉 이런 상황에는 충돌을 해결한 후 다시 커밋하거나, 브랜치를 합치는 작업(merge)을 취소한다. (git merge --abort)

 

 

 

브랜치를 만들고 이동하자

브랜치를 만든다 👉 git branch 브랜치명

다른 브랜치로 이동한다 👉 git switch 이동할 브랜치명 ( = git checkout 이동할 브랜치명(새 버전이 나오면서 switch로 대체))

브랜치를 만들고 이동하자 👉 git switch -c 새롭게 만들 브랜치명

 

 

 

HEAD ?

현재 작업 중인 커밋을 가리킨다.

항상 작업트리의 가장 최근 커밋을 가리킨다.

보통 브랜치의 이름을 가리키지만, 커밋으로 HEAD를 분리할 수도 있다.

git switch(checkout) 분리할 커밋명

 

 

 

브랜치를 합치자

git merge 현재위치한 브랜치와 합칠 브랜치명

conflict 가 발생했을 경우, 충돌 내용 해결 후 다시 커밋 / git merge --abort 로 merge 취소

 

 

 

merge 와 rebase 뭘 써야 할까?

브랜치를 합치는 방법은 사실 두 가지이지만 어떤 걸 써야 할지 갈피가 잘 잡히지 않았다.

그러던 와중 공식 문서를 보고 고개를 끄덕이게 되어서 인용해 둔다.

Merge 와 Rebase 둘 중 뭘 써야 좋을까?

  이 질문에 대한 답을 찾기 전에 히스토리의 의미에 대해서 잠깐 다시 생각해 보자.
  히스토리를 보는 관점 중에 하나는 작업한 내용의 기록으로 보는 것이 있다. 작업 내용을 기록한 문서이고, 각 기록은 각각 의미를 가지며, 변경할 수 없다. 이런 관점에서 커밋 히스토리를 변경한다는 것은 역사를 부정하는 꼴이 된다. 언제 무슨 일이 있었는지 기록에 대해 거짓말 을 하게 되는 것이다. 이렇게 했을 때 지저분하게 수많은 Merge 커밋이 히스토리에 남게 되면 문제가 없을까?
  역사는 후세를 위해 기록하고 보존해야 한다. 히스토리를 프로젝트가 어떻게 진행되었나에 대한 이야기로도 볼 수 있다. 소프트웨어를 주의 깊게 편집하는 방법에 매뉴얼이나 세세한 작업내용을 초벌부터 공개하고 싶지 않을 수 있다. 나중에 다른 사람에게 들려주기 좋도록 Rebase 나 filter-branch 같은 도구로 프로젝트의 진행 이야기를 다듬으면 좋다.

  Merge 나 Rebase 중 무엇이 나으냐는 질문은 다시 생각해 봐도 답이 그리 간단치 않다. Git은 매우 강력한 도구고 기능이 많아서 히스토리를 잘 쌓을 수 있지만, 모든 팀과 모든 이가 처한 상황은 모두 다르다. 예제를 통해 Merge 나 Rebase가 무엇이고 어떤 의미인지 배웠다. 이 둘을 어떻게 쓸지는 각자의 상황과 각자의 판단에 달렸다. 일반적인 해답을 굳이 드리자면 로컬 브랜치에서 작업할 때는 히스토리를 정리하기 위해서 Rebase 할 수도 있지만, 리모트 등 어딘가에 Push로 내보낸 커밋에 대해서는 절대 Rebase 하지 말아야 한다.

 

 

 

git pull

원격 저장소에 변경된 내용을 로컬 저장소로 불러오는 명령어.

자동으로 동기화되지 않기 때문에 자주자주 pull 해주는 게 좋다고 한다.

 

실습 중 push를 할 때 error를 확인했었다.

그 이유가 바로 pull 을 해주지 않았기 때문이었다. 원격 저장소에 있는 파일이 로컬 저장소에는 없었기 때문에.

그때그때 자주자주~ 습관적으로 pull 을 해줘야겠다 !

 

 

 

현업에서는 어떻게 사용할까?

 

1. 새 브랜치를 만들고 작업 완료 후 원격 저장소에 push 한다

2. 원격 저장소로 가면 이러한 메시지와 버튼을 확인할 수 있다.

3. 변경내용, 작업내용 등을 간략히 적는다 > create pull request!

4. 코드리뷰 등 코멘트의 장이 열린다!

이런 식으로 코멘트를 달 수 있다!

그렇구나 현업에서는 이런식으로 코드리뷰를 하는구나 🥹 감격의 순간..

코드리뷰를 받고 수정 > push > 리뷰 > 수정 > push  ... 의 반복이 끝나고 완성이 되었다면!

 

5. Merge pull request 버튼을 클릭.

버튼을 클릭하면 이 브랜치를 main (나의 경우는 master) 브랜치에 merge 한다.

 

⚠️ 여기서 주의할 점

원격저장소의 변경은 로컬저장소에 자동 동기화 되지 않는다.

꼭 메인 브랜치로 이동 후 git pull 명령어를 사용하자.