GIT branch 생성과 전환 및 병합 팁

깃의 브랜치를 로컬에서 자유자재로 바꿔가며 push, pull을 해보자

Branch

브랜치를 왜 만드나???

• 브랜치는 레퍼지토리(소스코드 저장소)의 복제본이라고 생각하면 된다.
• main 브랜치를 다 같이 사용한다고 가정하면, 코드 오류 한 번 터지면 연쇄적으로 피해를 입는다.
• 이를 방지하고자 브랜치를 사용해서 복제본으로 따로 개발을 진행하고,
• 이후에 main에 병합을 하는 게 일반적이다.

그럼 브랜치는 어떻게 만들고, 전환과 병합은 어떻게 할까??

Branch 생성, 전환

명령어 기억!

• git branch 브랜치명 : 브랜치 생성
• git checkout 브랜치명 : 브랜치 변경
  • 요즘은 브랜치 전환에 switch 사용을 권장한다고 함

로컬에서 Branch 생성과 전환이나 모든 과정들을 커밋(트리구조)으로 형성되며,
추후에 이것을 GIT 저장소에 push를 하면 GIT 저장소에도 똑같이 생성이 된다.

• 이것에 관해서는 아래에 PUSH, PULL 설명에서 다시 언급하겠다!
• 참고로 브랜치 전환하기 전에 꼭 커밋을 통해서 현재 상태를 기록해놔야 전환이 될 것이다.
• 또한, 이 커밋 구조를 확인하기 편하게 도움을 주는 옵션이 있다.
  • git log –oneline –all –graph
    • 커밋 로그를 쭉 확인 가능하며, HEAD는 현재 위치를 의미하며, 브랜치 이름도 표시되어 있다.
    • 참고로 이 커밋 이름을 사용해서 해당 시점으로 돌아갈 수도 있다(형상 관리의 장점)
      이에 관해서는 다른 게시글에서 언급하겠음!!

또한, branch 전환을 하면 폴더나 파일들이 달라져서 처음엔 당황할 수 있는데 그것은 해당 브랜치의 커밋 시점으로 작업 환경이 이동한 것이기 때문에 당연한 것이다.

원래 파일들을 보려면 원래 branch로 돌아가면 되므로 당황하지 말자!

Branch 병합(중요)

이전 과정에서는 Branch 전환할 때 커밋으로 현재 변경사항을 기록해야 안정적으로 전환이 된다는 점이 키포인트였다.

현재 과정에서는 merge(병합) 명령어를 사용하는데 이는 두 커밋을 합쳐서 merge를 한 새로운 커밋을 생성한다.
이때, conflict(충돌) 현상이 발생할 수 있어서 중요하다.

(가정) main 브랜치, cat 브랜치 존재하며 main 브랜치에 cat 브랜치를 합치려 함

• merge 방법 : main 브랜치에서 git merge cat을 입력

• conflict(충돌) 발생 안 하는 상황
  • main에서 a.txt를 가지며, cat에서 b.txt를 생성했다. 이 경우에는 전혀 겹치는 게 없다.
  • 이런 상황이 충돌 발생하지 않는 안전한 상황
• conflict(충돌) 발생할 수 있는 상황
  • main, cat 두 곳에서 a.txt를 가지며 서로 내용이 다른 상황. 이 경우는 겹친 상황이다.
  • 이 상황은 당연히 충돌이므로 직접 코드 수정을 해서 해결해야 한다.
  • 정말 친절하게도 충돌 지점을 전부 표시해주며, 이를 잘 수정만 해주면 된다.
    • 해결 흐름 : 원하는 코드 남기고 -> git add -> git commit

PUSH, PULL

Git을 사용할 때 Push, Pull도 정말 많이 사용하는데 에러도 자주 발생한다.
이에 따라 동작의 흐름을 잘 이해해두는 게 중요하다.

먼저 로컬 저장소(예로 본인 PC), 원격 저장소(예로 GIT 저장소)를 잘 이해해두자.

• git remote -v를 사용하면, 현재 어디의 원격 저장소에 연결되어 있나 확인 가능
• 따라서 같은 원격 저장소에 사용 중이다??
  • push, pull을 통해서 서로 다른 로컬 저장소에서 협업이 가능

그리고 Push를 하기 전에는 Pull을 먼저 해줘야 한다. 왜??

충돌 문제 때문이다.
왜냐하면 우리가 push하기 전에 이미 다른 사람이 push를 먼저 해서 기존 코드랑 다른 경우가 생기기 때문이다.

이를 해결하고자 Git에서는 애초에 rejected 알림을 주며, hint로 git pull을 하라고 알려준다.

• (가정1) 사용자1과 사용자2가 같은 원격 저장소의 코드를 사용 중

• (가정2) 또한, 사용자1과 사용자2가 서로 같은 파일을 수정했는데 사용자 2가 먼저 push

• 이 경우에 사용자1이 pull을 먼저 하지 않고 push를 한다면??

  • rejected 알림을 주며, 먼저 git pull을 하라고 합니다.

  • 이는 먼저 로컬 저장소에서 git pull을 통해 사용자2가 새로 업데이트한 원격 저장소 코드를 가져와(merge 과정) 충돌(conflict)이 발생할 수 있는 상황을 말끔히 해결하고(새로운 커밋이 생성된 것) 원격 저장소로 push를 하라는 의미입니다.

    • 이 과정(git pull)에서 충돌로 인해 에디터로 가면, 탈출 명령어는 wq 엔터
    • 이후 git log로 커밋 확인 가능하며 이곳에서 탈출 명령어는 q로 탈출
    • 이후 최종 push까지 해야 원격 저장소에도 최종적으로 커밋 내용이 저장

  • 실제로 방금과 같은 상황을 만들고, rejected 알림을 받아서 git pull을 진행했더니 아래와 같은 충돌(conflict) 명령과 어느 파일에서 발생했는지를 알 수 있다.

    

    • 이 부분을 다시 언급하는 이유는 VSCODE의 경우 해당 코드에서 바로 충돌 지점들을 표시해줘서 해당 파일 수정 및 다시 커밋하면 해결이 되는데,

    • 여기서는 직접 어떤 파일이 conflict 된 건지 보고 직접 들어가서 해결해줘야 한다.
      다행인 것은 해당 파일에 들어가면 여기서도 충돌 지점을 표시해주고 있다는 점이다.

    • 원하는 코드로 수정 후 다시 커밋 및 푸시를 진행하면??

  

  • git add . -> git commit 입력 시 들어온 상황이며, vim 에디터인 상황!!
    • a나 키보드들을 눌러 insert 모드 접근 후 # 없이 입력하면 커밋 메시지를 작성할 수 있고,
    • esc로 다시 일반 모드로 돌아가서 :wq로 해당 내용을 저장하고 탈출할 수 있다.
      • :q!의 경우 해당 메시지 저장 안 하고 탈출할 수 있다.
  • 모든 게 해결이 되었으므로 방금 만든 커밋을 git push로 원격 저장소에 최종적으로 올린다.