[Git&Github] Git Branch와 Merge

처음 협업을 진행할 때 Git은 매우 두려운 존재이다.
낯설기도 하고, 내 잘못된 선택으로 프로젝트에 영향을 미칠 수도 있다는 걱정으로😥
실수하지 않도록 옳은 Branch & Merge 사용법을 알아두어야 할 필요가 있다!

📌Branch

Git에는 Branch라는 개념이 있다. 개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 생긴다. 기존의 모든 코드를 복사하고 나서 원래 코드에는 영향을 미치지 않고, 독립적으로 개발을 진행할 때 Branch를 사용한다!
여러 브랜치를 만들어 개별적으로 작업하고 나중에 Merge 하는 방법이 권장된다!

📌Merge

독립적인 갈래에서 개발을 진행하다가
변경사항을 원래의 갈래에 적용하고 싶을 때 Merge를 통해 병합한다!
작업 내용을 합치는 것이다.

 

독립적인 브랜치에서 각자 의도와 목표에 맞는 개발을 진행하고 하나의 main branch에 merge 하는 것. 이 흐름은 Git에서의 이상적인 협업 방법이라고 말할 수 있다!

---

📌Branch와 Merge의 사용

본격적으로 Git에서 Branch와 Merge를 사용하는 기본적인 커맨드를 알아보자
*기본 디렉터리를 Git 저장소로 만드는 방법을 다룬다.

1. git init

Git으로 버전관리를 하고 싶은 경우 우선 프로젝트의 디렉터리로 이동한다.
그리고 터미널에서 git init을 실행한다.
이 명령을 통해 내 디렉터리에 코드 변경을 추적하는 감시자를 세우는 것이다!

$ git init

 

2. git add

변경사항이 생길 경우, 이 사항을 저장소에 기록해야 한다.
이를 위해선 Git에게 이 사항을 알아두어라 = staged 상태로 만들어야 한다!
📌 unstaged 상태의 파일은 커밋되지 않는다.
git add (파일명) 또는 git add. 를 사용한다. 후자는 현재까지 모든 변경사항이 존재하는 파일을 다 staging area로 올리는 것이다!

$ git add .

 

3. git commit

수정한 것을 커밋하기 위해, 기록하기 위해. 앞의 단계에서 파일을 staged 상태로 만들었다.
git commit 명령어를 사용하여 커밋한다. 이때 해당 명령어를 입력하면 편집기가 실행되고, 편집기를 통해 어떤 변경사항이 존재하는지 기록할 수 있다.
💡 git commit -m "(type): 메시지"를 통해 편집기 없이도 커밋 메시지 작성이 가능하다.

 

 

 

커밋을 한 후 아직 아무것도 수정하지 않은 상태에서 어떤 파일을 수정하면, Git은 그 파일을 modified 상태로 인식한다. 커밋을 하기 위해 앞선 과정처럼 수정한 파일을 staged 상태로 만들고, staged 상태의 파일을 커밋하는 라이프사이클을 반복한다.

 

출처: 🔗Git

 

본격적으로 온라인에서 다른 사람들과 협업하기 위해서 사용하는 플랫폼이 있는데,
바로 Github이다! Github을 통해 온라인 백업, 협업이 가능하다.

4. git push

수정된 코드를 github에 반영하기 위해 사용하는 명령어이다!

$ git remote add origin <내 github 주소>

을 통해 내 github 주소 (레포지터리 주소)를 연결해 주고,

$ git push -u origin <브랜치명>

을 통해 업로드가 가능하다!

 

💡 기본 브랜치명이 master임을 확인할 수 있는데, 그보다는 main으로 바꿔 사용하곤 한다.
과거 노예제도를 연상시키기 때문이라고 한다.

$ git branch -M main

 

5. git checkout / switch

하나의 갈래에서 모든 개발을 진행하는 것은 git에서 권장하는 방식이 아니며, 협업과 버전관리에도 도움 되는 방식이 아니다. 새로 branch를 만들고, 이동하여 개발을 해야 한다!

$ git branch <브랜치명>

을 통해 브랜치를 새로 만들 수 있다.

$ git checkout <브랜치명>
$ git switch <브랜치명>

을 통해 앞서 만든 브랜치로 이동이 가능하다.
💡 그리고 브랜치를 만들면서 바로 이동하는 엄청난 shortcut이 존재한다!

$ git checkout -b <브랜치명>
$ git switch -c <브랜치명>

 

6. Pull Request

독립적인 갈래에서 개발을 완료했다면, 이제 남은 것은 Merge이다. 하지만, 로컬에서 git merge를 하는 대신 Github를 통해 병합하는 방법이 있다.
그게 바로 PR, Pull Request이다.

PR을 사용하면 팀원들과의 코드를 공유하고 리뷰할 수 있으며,
기능 단위의 작업을 기록하고 관리하는 등의 장점이 존재한다!
잘못된 코드를 리뷰를 거치지 않은 채 main에 병합해 버린다면,,, 매서운 눈초리를 받을 수 있다ㅎㅎ

 

출처: GitHub문서

github의 내 원격 브랜치에 업로드된 변경 사항을 PR을 통해 main 브랜치에 merge 요청할 수 있다.
만약 팀원들이 내 PR 요청을 보고 코드 리뷰를 마친 뒤, 병합하는 데에 문제가 없다고 판단하면 승인해 줄 수 있고 이후에 본인이 Merge Pull Request 버튼을 눌러 병합하면 된다!

---

📌유용한 Git 커맨드

다음으로는 유용한 Git 명령어를 몇 가지 소개해보려고 한다!

7. git restore

$ git restore --staged <파일명>

해당 명령어를 통해 staged 상태인 파일을 unstaged 상태로 만들 수 있다.
이렇게 해도 내 작업 디렉터리에 변경사항은 저장되어 있다.
💡 커밋 단위를 분리하고 싶거나 원격 저장소에 올리고 싶지 않은 내용까지 staging area에 올라갔을 때 등의 상황에서 사용하면 좋다!

8. git status

$ git status

git이 현재 인식하고 있는 프로젝트 관련 내용을 출력한다.
현재 상태를 파악할 때 유용하다.
💡 항상 내가 어느 branch에 있는지 확인하는 습관을 들일 것을 추천한다!

9. git log

$ git log

해당 명령어를 통해 커밋 히스토리를 볼 수 있다.

$ git log --pretty=oneline

해당 명령어는 한 줄로 커밋 히스토리를 깔끔하게 출력해 준다.

10. git tag

$ git tag <태그명> <커밋아이디>

해당 명령어는 일반 커밋과는 다르게 더 중요한 내용을 담고 있는 커밋에 태그를 지정할 수 있다.

11. git clone

$ git clone <레포지터리 주소>

해당 명령어를 통해 다른 사람의 github 레포지터리를 내 컴퓨터로 옮겨올 수 있다.

 

해당 내용은 Git과 GitHub의 사용에서 가장 기본적인 것들이다.
개발, 특히 협업에서 꼭 알아두어야 할 것이다!
다음 포스트에서는 Branch를 병합하는 다양한 방법을 다루려고 한다!

참고: [🔗Git],
[🔗GitHub 문서]