협업을 위한 GIT 개발일지 - 2주차 (2) Git Branch, Merge, conflict

💡수업 목표💡

1. 협업하기 위한 Git 기본 개념을 익힌다 - issue, branch, merge
2. 두 명 이상과 협업하는 Git 프로젝트를 만들 수 있다.
3. 기능별로나누어 작업내역을 남길 수 있다.

 

2022.09.15 - [스파르타코딩클럽/Git] - 핵심쏙쏙 GIT 개발일지 - 2주차 (1) GitHub issue 사용하기

핵심쏙쏙 GIT 개발일지 - 2주차 (1) GitHub issue 사용하기

 

---

 

Git Branch

동일 소스코드를 기반으로 서로 다른 작업을 하면서 각각 서로 다른 버전의 코드가 생성될 수 밖에 없다. 작업내역이 한 곳에서 섞이다보면 각 작업이 어떻게 진행되고 있는지 보기 어렵고, 충돌이 나서 오류가 생길수도 있다. 

이때, 여러 개발자들이 독립적으로 작업 할 수 있게 만들어주는 기능이 '브랜치(Branch)'이다.

 

 

 

 

프로젝트에 Branch 만들기 - branch

Branch는 개념은 어렵지만 생성하는거는 매우 간단하게 branch 란 명령어로 만들 수 있다.

$ git branch [브랜치명]
$ git branch -v # 브랜치 목록을 알수 있다.

 

브랜치 이름은 중요하다. 혼자 프로젝트하는거면 상관없을 수 있겠지만 협업을 하는 프로젝트일 경우 잘 관리하게끔 일정규칙을 가지고 적어줘야한다.

보통은 [항목/번호-이름] 이런 형식을 사용는 편이다. 기능 개발하는 브랜치면 관행적으로 feature를 사용해서 이슈번호를 같이 적어주는 형식을 사용하면 관리에 좋다. 같이 협업하는 팀마다 규칙은 각각 다르지만 나름 통상적으로 쓰이는 규칙들이 있으니 참고하면 좋다.
👉 https://nvie.com/posts/a-successful-git-branching-model/

 

 

Branch 전환하기 - checkout

우리가 새로 만든 브랜치를 사용하여 어떤 작업을 수행하려면, 이 브랜치를 사용 하겠다고 명시적으로 지정해야한다.  이 때 사용하는 명령어가 바로 checkout 이다.

checkout을 하게 되면 프로젝트 내용이 작업이력을 기준으로 맞춰진다. 그래서 아무리 다른 브랜치에서 많은 작업하더라도 checkout을 하면 영향을 받지 않는다. 

git checkout [전환할 브랜치명]

 

checkout 명령에 -b 옵션을 넣으면 브랜치 생성과 체크아웃을 한꺼번에 실행할 수 있다.

git checkout -b [새 브랜치명] # 브랜치 새로 생성하고 바로 전환하기

 

 

Branch 삭제하기 - branch -d

브랜치를 생성을 했으면 삭제도 가능하다. 삭제하기 위해서는 삭제할 브런치가 아닌 다른 브런치로 전환 후에 삭제가 가능하다.

단 삭제를 하게되면 기존 작업이력과 파일내용도 사라지니 삭제하기 전에 다른 branch와 병합(merge)하는 것을 잊지말자.

$ git checkout [다른 브런치] # 삭제를 위해 다른 브런치로 전환해준다.

$ git branch -d [삭제할 브런치명] # 삭제 (merget 전은 안됨)
$ git branch -D [삭제할 브런치명] # 강제 삭제(merge 전도 가능)

병합(merge)가 되지 않은 브런치는 -d로는 불가능하다. 정말 원한다면 -D로 강제 삭제도 가능하다. 

 

 

Branch에 작업이력 남기기

새로만든 독립된 branch에 작업이력을 남길려면 항상 현재 branch가 어디인지 체크를 잘해줘야한다. 

 

작업이력을 남기고 git 히스토리를 확인해보면 해당 branch의 작업이력을 볼 수 있다.

브랜치 생성할 때까지의  master의 작업내역 + 해당 branch에서 작업한 신규 작업내역 두개를 한번에 볼 수 있다. 

 

 

이런식으로 branch를 사용해서 나눠서 작업을 하면 아래와 같이 작업이력을 관리할 수 있다.

 

 

 

Git Merge

$ git checkout [기준 브랜치명] # 병합을 위해 합칠 기준이 되는 브랜치로 전환해 작업한다.

$ git merge [합칠 브랜치명]

 

 

Merge 방식

Merge 메세지 중에서 눈여겨 봐야할 것이 있다. Merge를 두번했는데 나오는 메세지의 내용이 다르다. 이유는 merge 방식이 다르기 때문이다. 

• Fast-forward
• 3-Way Merge ( 'ort' 혹은 recursive)

 

Fast-forward

Fast-forward 라는 메시지가 보인다.

master가 새로운 커밋을 생성하고 있지 않았을 때, feature/3_jeon 브랜치는 master브랜치에 기반하기 때문에 Merge 과정없이 그저 최신 커밋으로 이동한다. 이런 방식을  Fast-forward라고 한다.

별도의 commit을 생성하여 병합하는 것이 아니라, master가 가리키고 있는 브랜치 포인터를 변경하기만 한다.

 

 

3-Way Merge

Merge made by the 'ort' strategy. 라는 메세지가 보인다. 

feature/4_jeon 브랜치가 생성된 후 기준이 된 master는 새로운 commit이 생겼다.(feature/3_jeon 브랜치 merge에 대한)

그러므로 fast-forward가 생기지 않고, master의 새로운 commit과 합쳐져 새로운 결과, commit을 만든다.

 

 

 

Git의 Merge Conflict

git에서 master와 branch를 만들고 작업하다보면 pull request할때 conflict(충돌)이 나는 경우가 빈번하다. 특히 다른 작업자가 나와 같은 라인을 수정하고, 그 수정한 내역을 merge했을 때 발생한다.

이때, 당황하지말고 충돌된 코드를 잘 수정해주면 성공적으로 merge를 할 수 있다.

 

 

 

충돌된 파일을 살펴보면 아래와 같이 하나의 파일을 여러 군데에서 변경했기 때문에 변경된 내용 중 어떤 것을 브랜치에 반영할지 파악을 돕기 위해 정보를 알려주고 있다. <<<<<<< 에서 >>>>>>> 까지가 충돌이 나는 부분입니다.

conflict를 해결할때 <<<<<<< HEAD , ======= ,  >>>>>>> 충돌나는 브랜치명 또는 commmit 아이디 를 지우면 된다. 그러면 Git 이 해결되었구나! 하고 알아듣는다. 단, 이때 conflict를 해결하는 데 집중해야지 새로운 코드를 짜게 되면 프로젝트 관리에 어려움을 겪게 된다. 수정을 하고 싶으면 conflict 수정 후 별도의 commit을 남기는 것이 좋다.

<<<<<<< HEAD
{현재 브랜치의 다른 파일 내용}
=======
{충돌나는 브랜치명 또는 commit에서의 다른 파일 내용}
>>>>>>> 충돌나는 브랜치명 또는 commmit 아이디

 

 

 

conflict된 파일을 수정하면 merge commit을 해주면 된다.

git commit -m(커밋 간단메세지)가 아닌 git commit 을 하게 되면 Conflict에 대한 간단한 내용을 자동으로 commit에 입력 받을 수 있다.  

 

 

성공적으로 commit이 남겨지면 merge 성공!