git 공부하기(3)_브랜치 사용하기
들어가기에 앞서
브랜치는 협업을 하기위한 시작과도 같은 개념이다. 서로의 공간을 나눠서 작업할 수 있게 만들어주는 장치이다. 같은 프로젝트의 코드를 수정하더라도 서로 전혀다른 공간에서 작업을 하는 것이다. 일종의 평행세계를 만드는 것과 같은 개념이다. 그렇기 때문에 서로 다른 사람들이 같은 프로젝트의 코드를 수정하더라도 수정된 코드는 나한테만 보이고 다른사람한테는 보이지 않게 된다.
git명령어를 입력하는 작업은 CLI에서 이루어진다. 이것은 명령어를 작성하고 실행시킬때는 편리하지만 전체 내역을 한 눈에 확인하기는 쉽지 않다. 이 시간에는 git의 작업내역을 한 눈에 볼 수있는 툴을 사용해볼려고 한다. git의 작업내역을 GUI로 확인 할 수 있도록 만든 툴이 여러개 있는데 그 중에서도 Sourcetree를 사용해보고자 한다. Sourcetree로도 CLI에서 명령어를 입력하는 것과 같은 작업들을 더 편리하게 할 수는 있지만 이 시간에는 작업내역을 확인하는데만 사용해보도록 하겠다.
브랜치 기본 명령어
브랜치와 관련된 기본명령어는 다음과 같다.
- git branch : branch종류 확인
- git branch <branch이름> : <branch이름>으로 된 branch 생성
- git branch -d <branch이름> : <branch이름>삭제
- git switch <branch이름> : <branch이름>으로 branch변경
- git branch -m <branch이름> <변경할 branch이름> : branch이름 변경
브랜치 다뤄보기
이제 위의 명령어들을 사용해서 브랜치를 다뤄보자. 먼저 브랜치를 생성해 줄 것이다.
빨간 네모박스가 명령어이다. new-member를 생성한 후 git branch명령어로 branch가 생성된 것을 확인 하였다. new-member라는 새로운 평행세계가 생성된 것이다.
이제 new-team이라는 브랜치를 만들고 해당 브랜치로 이동한 뒤에 새로운 팀을 만들어보도록 하자.
git switch -c <branch이름> 명령어를 사용하면 브랜치를 생성하고 바로 해당 브랜치로 이동할 수 있다. 브랜치를 따로 만들고 이동하는것보다 더 편한 방법이다. 위의 사진을 보면 명령어 실행 후 바로 new-team으로 이동된 것을 볼 수 있다.
이제 새로운 팀이 생성되었으니 팀장을 지정해주고 기존의 팀은 팀장을 변경해주도록 하자.
자세한 변경내용까지는 볼 수 없지만 NewTeam과 ProductTeam이라는 2개의 파일이 변경되었다는 것을 알 수 있다. ProductTeam은 이번에 새로 만들어진 팀이다.
이제 여기서 내용을 커밋 한 후 다시 main브랜치로 돌아가면 new-team에서 만든 모든 내용이 사라지게 될 것이다. main이라는 세계에서는 new-team이라는 세계에서 한 일을 모르기 때문이다.
꼭 주의해야 할 점!!!!
브랜치를 이동한 뒤 내용을 수정하고 커밋까지 해야 다른 브랜치로 이동했을 때 수정한 내용이 보이지 않게 된다. 만약 내용을 수정하고 커밋을 하지 않은 상태라면 다른 브랜치로 이동했을 때 수정한 내용이 같이 따라오게 된다. 실수로라도 커밋을 하지 않은 채로 브랜치를 이동해서 커밋하게 되면 해당 브랜치로 커밋내용이 저장되기 때문에 이 점을 꼭 주의해야한다!!
여러 사람이 협업해야 할 경우 이 처럼 서로 다른세계로 분리시켜서 나만의 독립적인 공간에서 코드를 작성할 수 있게 된다.
내용 합치기
브랜치가 서로 다른 세상이지만 결국 언젠가는 이 브랜치들의 내용을 합쳐야하는 경우가 온다. 서로 작성한 코드가 합쳐져야 완성된 프로젝트가 되기 때문이다. 보통은 각자 자기가 만드는 기능에 맞는 브랜치를 생성한 뒤 최종적으로 main브랜치로 병합을 한다.
병합을 하기 위한 방법은 2가지가 있다.
- git merge
- git rebase
2개의 방식은 결과적으로는 하나의 브랜치로 코드가 합쳐진다는 공통점이 있기는 하지만 git의 트리가 남아있느냐 사라지느냐의 차이가 존재한다. 그림으로 살펴보도록 하자.
먼저 new-member와 new-team에서 각각 내용을 수정하고 commit한 상태의 트리모양이다.
현재 가지상태를 살펴보면 우선 3개의 브랜치로 나누어져 있는 것을 알 수 있다. 그리고 해당 브랜치가 어디 위치에 있고 마지막 커밋내용이 어떤 것인지도 알 수 있다. 브랜치마다 커밋했을 때 새로운 가지가 뻗어나가기 때문에 브랜치별로 커밋내용을 편하게 확인할 수 있다. 현재 내가 속해있는 브랜치는 브랜치 이름 앞에 o가 표시되어 있다. 현재 사진에서 내가 속해있는 브랜치는 main브랜치이다.
이제 병합을 해보도록 하자. new-member는 merge를 사용하고 new-team에는 rebase를 사용해보도록 하자.
(1) git merge
merge를 사용하기 위해서는 내용을 합칠 브랜치로 이동한 뒤 git merge 합칠브랜치 를 입력해주면 된다. main브랜치로 최종적으로 합칠 예정이고 현재 브랜치가 main이기 때문에 바로 merge를 진행해보도록 하겠다.
new-member의 내용을 합칠 것이기 때문에 git merge new-member를 입력해준다. 명령어를 입력하면 main브랜치에도 new-member의 내용이 추가된 것을 확인할 수있다. Sourcetree를 보면 다음과 같다.
new-member로 뻗어나가던 가지가 main과 합쳐지고 커밋메세지로 Merge branch 'new-member'가 입력되었다. merge할때의 커밋메세지는 자동으로 입력되어진다.
(2) git rebase
이제 rebase방식도 알아보자. new-team을 rebase시킬 것이기 때문에 new-team브랜치로 이동한 후 git rebase main명령어를 입력해준다. 이제 main브랜치로 돌아가보면 new-team의 내용이 추가되고 Sourcetree는 다음과 같이 변한다.
merge와는 다르게 기존의 가지가 사라지고 main가지에 추가가 된 것을 볼 수 있다. 여기서 주의할 점은 main브랜치의 위치가 new-team보다 뒤에 있다는 것이다. 이것은 rebase의 특징으로 이 상태에서 main브랜치로 간 뒤에 git merge new-team을 입력해주면 main브랜치와 new-team브랜치의 위치가 같아진다.
git merge new-team명령어를 실행한 이후의 모습이다.
내용 충돌
서로 다른 브랜치에 코드를 작성하더라도 서로 같은 위치의 내용을 수정해서는 안된다. main이라는 브랜치에서 ProductTeam의 팀장을 수정하고 커밋한 뒤 new-team이라는 브랜치에서도 ProductTeam의 팀장을 수정했다. 이렇게 되면 추후에 브랜치의 내용을 합쳐야 할 때 충돌이 나타나게 된다. 이 경우에는 어느 한쪽의 수정내용을 포기하거나 다른 방법으로 수정하는 등의 방식으로 문제를 해결해야 한다. 이런 상황을 conflict가 났다고 표현한다.
conflict가 발생하면 2가지의 선택을 할 수 있다.
- merge나 rebase이전으로 되돌린다.
- 충돌된 상태에서 충돌된 부분의 내용을 수정한 후 merge를 계속 진행한다.
이전으로 되돌리는 방법은 abort명령어를 사용하면된다.
- git merge --abort
- git rebase --abort
그러면 다시 병합이전으로 돌아가기 때문에 코드를 수정한 후 다시 병합을 진행하면 된다.
만약 conflict난 상황에서 충돌된 부분을 수정한 후 merge를 계속 진행하고 싶다면 충돌난 부분의 코드를 수정한 후 다시 add와 commit을 해주어야 한다. 그런데 이때 merge의 진행과 rebase의 진행이 조금 다르다.
(1) merge를 사용해서 conflict난 경우 해결방법
- 충돌난 부분의 코드를 수정한다.
- git add . 명령어를 이용해서 다시 파일을 add한다.
- git commit을 이용해서 merge를 완료한다.
이 순서로 진행하면 순조롭게 merge가 완료된다.
(2) rebase를 사용해서 conflict난 경우 해결방법
- 충돌난 부분의 코드를 수정한다.
- git add . 명령어를 이용해서 다시 파일을 add한다.
- git rebase --continue 명령어를 이용해서 계속 진행한다.
rebase에서 continue를 사용하는 경우는 rebase는 merge와는 다르게 가지를 병합 할 브랜치에 붙이기 때문이다.
merge는 기존의 가지를 유지한 채 새로운 커밋을 만들기 때문에 한 번만 작업하면 되지만 rebase는 기존의 가지를 통째로 붙이기 때문에 여러개의 커밋내역이 있다면 모든 커밋내역을 따로따로 진행해야한다. 그래서 continue를 사용해서 뒤에 남은 가지들을 진행시키는 것이다.
병합을 했는데 conflict가 났다면 반드시 같은 부분을 수정한 사람과 이야기를 해서 진행해야한다. 업무가 엉켜버렸거나 실수로 잘못 건드렸거나 등 여러 이유로 충돌이 날 수 있기 때문에 코드를 수정할 때는 반드시 내가 만져야 하는 부분만 만져야 하고 충돌이 일어나면 커뮤니케이션을 통해 풀어나가야 한다.
'Git' 카테고리의 다른 글
git 현재커밋과 이전커밋 합치기 (0) | 2022.10.26 |
---|---|
git 공부하기(4)_깃허브 연결하기 (0) | 2022.09.05 |
git 공부하기(2)_기본 사용방법 (0) | 2022.09.02 |
git 공부하기(1)_설치 및 설정 (0) | 2022.09.02 |
.gitignore에 등록했는데 동록이 안될 때 (0) | 2022.06.29 |
댓글
이 글 공유하기
다른 글
-
git 현재커밋과 이전커밋 합치기
git 현재커밋과 이전커밋 합치기
2022.10.26 -
git 공부하기(4)_깃허브 연결하기
git 공부하기(4)_깃허브 연결하기
2022.09.05 -
git 공부하기(2)_기본 사용방법
git 공부하기(2)_기본 사용방법
2022.09.02 -
git 공부하기(1)_설치 및 설정
git 공부하기(1)_설치 및 설정
2022.09.02