Git, 어렵지 않게 시작하기 4 - branch

2020. 2. 23. 23:13ETC/GIT

반응형

개발자라면 피할 수 없는 협업 도구인 Git. 진입장벽은 높지만 배우면 크게 도움이 되는 도구이기 때문에 소개해 드리고자 합니다. git을 처음 보는 사람을 위해서 git이 무엇인지 알아가고 사용하기 까지 발 맞춰 배워가는 것이 이 글의 목표입니다.

 

 

---------------  INDEX  ---------------

 

🔥 Git을 사용하는 이유

🚀 Git을 시작하는 방법

🌈 Git 활용하기

💻 Git으로 협업하기

🎠 그 밖에 할 수 있는 것들

 

--------------------------------------

 

 

이 글은 Git, 어렵지 않게 시작하기 3 에 이은 네번째 후속편입니다. 1, 2, 3편을 먼저 보고 오시는 것을 추천해드립니다.

 


 

이 번 포스팅에서는 Git으로 협업하기에 대해서 알아보는 시간을 가져보도록 하겠습니다. Git의 큰장점 중 하나는 협업하면서 생기는 문제들을 부드럽게 해결할 수 있다는 것입니다.

 

이 번 포스팅에서 다룰 주제는 “Branch”입니다. Branch는 Git에서 수정, 협업을 쉽게 만들어 주는 개념이자 도구입니다.

 

Branch : 코드 전체를 복사하고 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것

 

Git은 프로젝트가 시작되면 ‘master’라는 이름으로 브랜치를 하나 만듭니다. 그리고 별 다른 브랜치를 만들지 않고 작업을 계속 이어나간다면 ‘master’ 브랜치에서 계속 작업을 하게 됩니다.

 

 

 

그런데, 브랜치는 굳이 왜 만들어 사용할까요?

브랜치를 만들어 개발하면 여러 개발자들이 동시에 다양한 작업
할 수 있게 됩니다. 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있습니다.

 

 

HEAD?

HEAD는 현재 사용 중인 브랜치의 선두 부분을 나타내는 이름입니다. 브랜치가 여러개일 때, 여러개의 브랜치들 중에서 HEAD는 사용중인 브랜치의 맨 앞에서 표시를 합니다. 기본적으로 HEAD는 master 브랜치의 맨 앞에 위치하고 있습니다.

자, 그럼 브랜치를 만들고 병합하는 과정과 필요한 명령어를 알아보도록 합시다.

일단, 현재 로컬에 어떤 브랜치가 있는 지 확인해보겠습니다.

 

 

브랜치 생성

 

git branch

 

위와 같은 명령어를 입력하면 아래와 같은 결과 창이 나옵니다.

 

git branch <new branch name>

 

새로운 브랜치를 만들려면 위와 같은 명령어를 입력해줍니다.

 

 

develop이라는 이름의 브랜치를 만들고 확인해보니 ‘develop’과 ‘master’이라는 브랜치가 있다는 것을 확인할 수 있습니다.

이 때, master에는 *(별표)와 초록색으로 표시가 되어있는 모습을 볼 수 있습니다.

이 것은 master 가 현재 작업중인 브랜치라는 의미입니다.

현재 작업중인 브랜치에 따라 working directory가 변경됩니다.

 

현재 브랜치가 master라면, 작업 환경은 master에서 작업한 내용으로 맞춰집니다.

여기서 develop 브랜치로 전환한다면 develop에서 작업한 작업 환경으로 프로젝트가 변경됩니다.

 

 

브랜치 변경

 

git checkout <branch name>

 

위와 같은 명령을 입력하면 해당 브랜치로 전환되는 것을 확인 할 수 있습니다.

 

이건 로컬 저장소에 생성된 branch 입니다.

만약 원격에 바로 branch의 이름만 올려두고 싶다면

 

git push <리모트 저장소 이름> <브랜치 이름>

 

을 바로 입력하면 변경사항없는 브랜치 하나가 올라갑니다.

 

 

브랜치 삭제

 

이번에는 생성한 브랜치를 삭제해 보도록 하겠습니다.

 

git branch -d <branch name>

 

위와 같은 명령을 입력하면 브랜치가 삭제됩니다.

 

 

브랜치 병합

 

브랜치를 병합할 때에는 두 가지 방법을 사용할 수 있습니다.

 

  1. Pull Request
  2. git merge

두 가지 방법을 한 번 살펴보겠습니다.

 

✨ pull request (PR)

pull Request는 github에 저장된 두 브랜치를 병합합니다. 그래서 pull request 작업은 github에서 합니다. 같이 pull request를 만들어서 병합해보도록 합시다!

 

 

원격 저장소로 가서 프로젝트 상단에 Pull requests 를 선택합니다.

 

 

new pull request를 눌러 PR하나를 만들어 줍니다.

 

 

병합할 브랜치와 병합될 브랜치를 꼭! 확인해주세요!

 

 

그럼 위와 같은 화면이 보입니다.

자동 merge 가능 여부라고 적혀있는 곳은, 다음과 같은 메세지가 뜹니다.

 

 

   ✔️Able to merge : 따로 충돌나는 파일이 없는 상태로, 자동으로 merge를 할 수 있는 상황입니다.

   ❌ Can’t automatically merge : 충돌이 발생한 파일이 존재하는 상태로, 자동으로 merge를 할 수 없는 상황입니다. 수동으로 충돌을 해결하면 merge할 수 있습니다.

 

참고로, 아래에는 변경되는 파일들이 나열되니 한 번 확인해보시길 바랍니다!

 

 

위의 그림과 같이 메세지를 남길 수 있습니다. 아무 것도 적지 않아도 괜찮습니다.

 

 

다음과 같이 ‘no conflicts’ 메세지가 뜨면 Merge pull request를 눌러주고, 마지막으로 commit 메세지를 확인하면 끝납니다.

 

 

성공적으로 마쳤다면 성공적으로 브랜치를 병합했습니다.

하지만, 병합을 했다고 브랜치가 사라지는 것은 아닙니다. 아직 두 브랜치는 남아있습니다. 브랜치가 더 이상 필요없다면 Delete branch를 하셔도 좋습니다.

만약 브랜치들의 흐름을 도식적으로 보고싶다면 아래와 같이 Insights>Network에 들어가셔서 확인해보는 것도 추천드립니다.

 

 

 

 

git merge

두 번째는 로컬에서 수동으로 병합하는 방법입니다.

터미널/git bash창에서

 

git merge <branch>

 

base branch (병합할 브랜치)로 checkout 한 상태에서 위와 같은 명령어를 입력해주면 됩니다.

만약 conflict없이 병합이 되었다면 다행이지만 만약에 conflict가 발생했다면 직접 그 파일을 수정해주어야 합니다.

충돌이 난 부분은 아래와 같이 git에서 표시를 해줍니다.

 

 

‘<<<<<<<<< HEAD ’부터 ‘============ ’ 까지가 base branch에 있는 README.md 파일에 포함되어 있는 부분입니다.

 

‘============’ 부터 ‘>>>>>>>>> feature-BB’ 라고 적혀져있는 부분까지가

병합될 브랜치에 있는 README.md 파일에 포함되어 있던 부분입니다.

같은 라인에 다른 내용이 적혀있어서 생긴 오류입니다.

 

‘<<<<<<< HEAD ’, ‘=========== ’, ‘>>>>>>> feature-BB’ 을 모두 지우고 원격저장소에 올릴 최종 내용으로 수정하여 저장합니다.

 

이렇게 모든 conflict를 해결하고 원격저장소에 올리면 됩니다.

 

명령어 익히기

 

 

명령어가 헷갈릴 것 같아서 정리해 보았습니다 !

도움이 되셨길 바랍니다😊

 

 

 

브랜치 관리 — Git Flow

브랜치를 생성할 때, master에서 바로 작업하는 것보다 더욱 효과적인 방법에 대해 소개해드리겠습니다.

 

 

 

🖍 Main Branch

일반적으로 master 브랜치와 develop 브랜치가 있습니다. 이 둘은 평행하게 이어지는 주브랜치입니다.

  • master :배포 가능한 상태’만을 관리합니다.
  • develop : 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행합니다.

 

🖍 Feature Branch

topic branch라고도 불리며, 새로운 기능을 개발하거나 버그 수정이 필요할 때 ‘develop’ 브랜치로부터 분기합니다. 피처 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 원격으로는 관리하지 않습니다. 개발이 완료되면 ‘develop’ 브랜치로 병합하여 다른 사람들과 공유합니다.

 

🖍 Release branch

release branch는 릴리즈를 위한 최종적인 버그 수정 등의 개발을 수행합니다. 이 브랜치에서 배포 가능한 상태가 되면 master branch에 병합합니다.

보통 이름을 지을 때에는 ‘release-<release name>’과 같이 사용합니다.

 

 

🖍Hotfix branch

배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, ‘master’ 브랜치에서 분기하는 브랜치입니다. 브랜치 이름 앞에 ‘hotfix-<hotfix name>’과 같이 사용합니다.

 

출처 —  https://nvie.com/posts/a-successful-git-branching-model/

 

 

위의 그림은 이 네 가지 분기를 가장 잘 설명하고 있는 그림이라고 생각해서 가지고 왔습니다! 이제 이해 가시나요?

위에서 설명드린 Branch 전략은 기본 전략이기 때문에 상황에 맞게 변형해서 사용하시면 됩니다.

그런데 왜 굳이 이러한 git flow를 사용할까요?

 

✔️ 각 브랜치의 이름으로 기능 개발의 책임 소재를 분명히 알 수 있다.

✔️개발 버전과 제품 버전을 따로 관리할 수 있습니다.

 

등을 이유로 사용합니다.

 

여기까지 Git으로 협업할 때 꼭 필요한 개념과 명령어를 알아보았습니다. 도움이 되셨나요?

그럼 다음에는 ‘Git, 어렵지 않게 시작하기’ 의 마지막 포스팅으로 찾아뵙겠습니다.

반응형