제타마인드

위와 같이 master 외에 서브브랜치를 만들어 별도의 프로젝트를 진행했다고 하자. 별 생각없이 v2라는 메시지로 커밋하였는데 나중에 master와 merge 할 것을 생각하니 보기 안 좋을 것 같다. 또한 서브 브랜치의 커밋내역을 하나로 깔끔하게 합치고 싶다면 어떻게 해야 할까? 이 때 사용하는 것이 Interactive Rebase 다.

여기서는 서브 브랜치의 내용을 master와 분기된 시점부터 모두 하나로 합치고 싶다. 따라서 master 브랜치를 선택한 후 마우스 우클릭 > Interactive Rebase를 클릭한다.

위와 같은 화면에서 커밋 목록이 나오는데, 1번이 더 과거의 목록이다. 변경하고 싶은 목록을 클릭한 뒤 우측 상단의 버튼을 클릭해서 해당 목록의 Action 상태값을 변경해준다.

1) Pick
해당 커밋을 아무 변경없이 그 상태로 놔둔다는 의미다.

2) Squash / Fixup
1번과 2번을 합치려면 2번을 클릭한 뒤 우측 상단의 Squash 또는 Fixup 을 클릭하여 2번의 Action을 변경해준다. 이 2개의 옵션은 반드시 더 과거의 커밋목록이 있어야 실행이 가능하며 차이점은 Message 뿐이다. Squash는 합치는 목록들의 메세지를 한 문장으로 합치며, Fixup은 가장 과거의 Message 즉, 여기서는 1번의 Message를 사용하게 된다.

3) Reword
Message를 수정할 수 있다.

사실 나는 1번의 Message를 그대로 사용하고 싶기 때문에 Fixup을 사용하면 되지만, 여기서는 Squash를 사용해보겠다. 2번을 Squash로 변경한다. 또한 기능 테스트삼아 1번을 Reword로 변경해 보았다.
이제 좌측 상단의 Start를 클릭한다.

1번을 Reword로 선택했기 때문에 Message 변경 박스가 뜬다. 1번 메시지를 수정하고 싶다면 수정한 후 Reword를 클릭하여 진행한다.

커밋이 하나로 합쳐지긴 했지만 squash를 선택했기 때문에 Message도 하나로 합쳐진 것을 볼 수 있다.

커밋 Message를 수정하려면 마우스 우클릭 > Modify > Edit 를 클릭한다. (메시지만 수정하고 싶다면 Reword, Author와 Committer도 수정하고 싶다면 Edit)

Git Staging에서 수정하고 싶은 Commit Message로 수정한 후 Commit 하면 메시지가 변경된다.

이전 게시물에서 충돌했을 경우 병합하는 방법에 대해서 다루었었다.

https://zetamind.tistory.com/32?category=1018375 

그러면 프로젝트에서 많은 개발자들이 각자 작업한 소스를 충돌없이 병합하려면 어떻게 해야 할까?

각자 자신의 로컬 PC에만 브랜치를 생성하여 개발한 후 최종적으로 master 브랜치에 병합하는 것을 추천한다.

즉, 아래와 같은 과정을 거친다.

1. 로컬PC에 local_dev 라는 브랜치를 생성한다.

2. local_dev 브랜치에서 작업한 소스를 commit 한다. (push 하면 안됨)

3. master 브랜치로 스위칭 한 후 싱크를 맞춰서 다른 사람이 작업한 소스코드를 pull 한다.

4. master 브랜치를 기준으로 local_dev를 병합한다.

5. master 브랜치를 remote에 commit and push 한다.

각, 과정에 대해 상세히 설명해 보겠다.

(여기서는 테스트를 위해 다른 개발자가 origin/master에 커밋했다는 전제하에, mater 브랜치에 임의의 소스를 추가하여 Commit and Push 하였다.)

1. 로컬PC에 local_dev 라는 브랜치를 생성한다.

프로젝트 우클릭 > Team > Switch To 메뉴에서 New Branch를 선택하여 local_dev 브랜치를 생성한다.

제대로 생성되면 아래와 같이 프로젝트명 옆에 표시되는 브랜치가 local_dev 로 변경된다.

2. local_dev 브랜치에서 작업한 소스를 commit 한다. (push 하면 안됨)

로컬에서 작업을 완료한다.

프로젝트 우클릭 > Team > Syncronyze Workspace에서 Commit 할 목록을 Staged Changes로 옮긴다.

작업후 Remote에 쓸데없는 브랜치가 생기지 않도록 Commit만 하도록 한다.

물론, 실수로 Push했다면 Git Repository의 Remote Tracking에서 Delete 하면 된다. (이 경우엔 실수로 다른 branch를 삭제하지 않도록 주의하자.)

3. master 브랜치로 스위칭 한 후 싱크를 맞춰서 다른 사람이 작업한 소스코드를 pull 한다.

프로젝트 우클릭 > Team > Switch To 메뉴에서 master 브랜치로 변경한다.

프로젝트 우클릭 > Team > Syncronyze Workspace 실행 후 pull 을 실행하여 소스를 최신화한다.

4. master 브랜치를 기준으로 local_dev를 병합한다.

프로젝트 우클릭 > Team > Merge를 실행한다.

local_dev를 선택 후 Merge 한다.

위와 같이 병합이 된 상태에서 충돌이 발생한 파일은 우클릭 > Team > Merge Tool을 실행한다.

아래와 같이 병합툴이 실행된다.

Pre-merged Local Version 쪽의 소스를 수정하여 병합후 저장한다.

5. master 브랜치를 remote에 commit and push 한다.

깔끔하게 push 되는 것을 볼 수 있다.

Git Repositories에서 확인해 보면 아래와 같이 Remote에는 쓸데없는 브랜치를 생성하지 않고 origin/master에 내가 작업한 결과물을 적용하였다.

이런식으로 관리하면 여러 개발자가 동시에 작업하여도 origin/master 브랜치를 깔끔하게 관리할 수 있다.

local_dev 브랜치는 로컬에만 생성되었으므로 삭제해도 되고, local_dev로 스위칭 한 후 origin/master를 병합해서 다음 작업에 다시 사용해도 된다.

1. 일단 같은 Git URI를 바라보는 2개의 프로젝트를 세팅해놓고 시작하겠다. 사용자1은 master 브랜치에 그대로 커밋하고, 사용자2는 별도의 브랜치에 작업하다가 merge할 생각이다. 사용자1, 2 모두 별도의 브랜치를 만들어 시작할 수도 있지만, 나중에 병합할 때 어차피 한쪽은 master 브랜치와 fast-forward 병합하고, 남은 한쪽은 충돌 병합을 해야 하기 때문에 여기서는 충돌 병합에 중점을 맞춰보겠다.
프로젝트 우클릭 > team > Show in History 를 클릭하면 아래 사진의 우측하단과 같이 History 창이 보이게 된다. 사용자 1, 2 모두 아래와 같이 master, origin/master, HEAD가 모두 동일한 revision에 위치한 상태에서 시작하도록 하겠다.

2. 사용자1의 파일에 내용을 추가한 후 master 브랜치에 Commit and Push 한다.

3. 사용자2에 user2라는 branch를 추가한다. (프로젝트 우클릭 > Team > Switch To > New Branch)
checkout new branch에 체크하여 생성하면 해당 branch로 전환된다. Switch To 메뉴에서 다른 branch로 전환 가능하다.

4. 사용자2가 user2 브랜치에서 내용을 작성한 후 Commit and Push 한다. 아래의 History와 같이 master, origin/master는 작업시작에 위치하여 있고 사용자2의 HEAD는 user2 브랜치에 위치하게 된다.

5. 이제 사용자2의 user2와 master 브랜치를 병합해 보겠다. 위의 3번에서 설명했던 Switch To 메뉴를 이용해서 사용자2의 브랜치를 master로 변경한다. 프로젝트 우클릭 > Team > merge 를 선택한 후 병합할 branch인 user2를 선택한 후 Merge를 실행한다.

병합을 실행하면 사용자2의 현재 History는 아래와 같이 된다. master, user2, HEAD가 같은 Revision에 위치해 있다.

6. 이제 사용자2에서 push를 실행해보자. 프로젝트 우클릭 > Team > Push Branch 'master' 를 실행한다. 실행하면 아래와 같이 rejected-non-fast-forward 에러가 발생하는 것을 볼 수 있다. 위의 2번에서 사용자1이 Remote의 origin/master를 이미 변경한 상태이기 때문에 충돌이 발생하게 된다.

7. 이제 사용자2의 로컬 master와 Remote의 origin/master를 병합을 시도해 보겠다. 사용자2의 프로젝트 우클릭 > Team > Merge를 실행한다. Merge 팝업창에서 Remote Tracking > origin > mater를 선택 후 Merge 한다. 이 역시 Already-up-to-date 팝업창이 뜨며 병합에 실패하는 것을 볼 수 있다.

8. 프로젝트 우클릭 > Team > Remote > Configure Fetch from Upstream...을 클릭한다. Ref mappings에 아무것도 없다면 Add...를 눌러 추가하고, 있으면 Advanced를 클릭한다.

9. 리스트에 나와있는 Ref의 Remove 필드에 있는 휴지통을 눌러 제거하고 좌측상단의 Source ref 콤보박스를 클릭하여 master를 선택하고 Add Spec 버튼을 눌러 리스트에 추가한다. Finish 버튼을 클릭하여 현재 창을 닫은 후 부모창의 Save and Fetch 버튼을 클릭하여 저장한다.

10. 이제 다시 위의 7번처럼 Merge를 시도하면 아래와 같이 병합이 된 것을 볼 수 있다. 빨간색 마름모 모양 표시가 있는 파일이 충돌이 발생한 파일이다. 파일의 내용을 보면 아래와 같이 꺽쇠로 표시되어 내 로컬 소스와 Remote 소스가 합쳐진 것을 볼수 있다. 꺽쇠 부분을 최종 반영할 형태로 수정해야 한다.

11. 곧바로 수정해도 되지만 파일 우클릭 > Team > Merge Tool을 클릭하면 충돌 부분을 서로 비교해 보면서 수정할 수 있다.

12. 병합 수정한 내용을 저장한 후 프로젝트 우클릭 > Team > Commit 버튼을 눌러 Commit and Push를 실행한다. 아래와 같이 정상적으로 Push 되는 것을 볼 수 있다. 사용자2의 History에서도 master, origin/master, HEAD가 같은 Revision에 위치하여 정상적으로 병합된 것을 볼 수 있다.

git의 Remote에서 다른 사람이 작업한 내용을 내 소스에 반영하는 것을 pull 이라고 부른다. (SVN의 update와 동일)

Remote에서 내려받을 변경사항들, 즉 pull이 가능한 경우 Project Explorer 또는 Git Repository의 프로젝트 명 옆에 ↓3 과 같이 건수가 표시된다. (반대로 push할 내용이 있을 경우 ↑3 과 같이 표시된다.)

프로젝트명 우클릭 후 pull 을 클릭하여 내려받으면 된다.

아래와 같이 Fast-forward 병합 결과가 표시되면 정상적으로 처리된 것이다.

아래 블로그에 잘 설명되어 있다. push를 시도했는데  rejected-non-fast-forward 메시지와 함께 실패했을 경우 먼저 merge 한 후에 push를 시도한다.

https://hanyda.tistory.com/36

revert, reset 모두 commit 한 내용을 이전상태로 되돌리는 기능이다. 단, 로컬저장소에만 해당된다.

revert : 이전 상태로 되돌리면서 Message에 Revert 라고 표시되며 commit 이 하나 추가된다. 이를 계속 반복한 것이 아래의 모습이다.

reset : 특정 위치에서 우클릭하여 reset 하면 당시의 상태로 되돌아가고 그 위의 커밋된 내용들은 모두 history에서 사라진다. 만약 reset 을 실수로 해서 reset 하기 전단계로 되돌아가고 싶다면 아래와 같이 Git Reflog 창을 열어서 원하는 상태에서 reset 하면 된다. ( Window > Show View > Other 에서 Git Reflog 추가)

소스를 원복해야 할 경우 revert를 사용하는 것이 바람직할 것 같다. reset으로 origin보다 이전 버전으로 되돌릴경우 나중에 병합이 힘든 것 같다. 만약 origin/master 보다 이전 버전으로 reset 해서 병합이 안될 경우는 Git Reflog에서 origin/mater 이후 버전으로 다시 reset 하면 된다.

프로젝트 우클릭 > Switch To > New Branch 선택. 브랜치 이름을 적고 Finish 한다.

Checkout new Branch 가 체크되어 있는데 그러면 새로 생성된 Branch로 이동하게 된다.

Branch 사이의 이동 또한 Switch To 메뉴에서 할 수 있다.

새 브랜치 이름을 feature/detail-page 로 적고 Commit and Push 해 보았다.

아래와 같이 표시되는 것을 확인할 수 있다.

origin 은 원격저장소의 닉네임이다. 회색 사각형의 origin/master 는 원격저장소 밑의 master 브랜치 임을 알 수 있다.

녹색사각형은 로컬저장소를 가리킨다.

HEAD 는 내가 현재 보고 있는 위치를 가리키는 포인터이다.

commit 만 3회 했을 경우

커밋2 에서 우클릭 > Push Commit을 선택하고, 아래와 같이 Branch으 빈칸에 master를 입력하여 Next -> Finish 하면

아래와 같이 origin/master가 이동한 것을 볼 수 있다.

최종버젼에서 Push Commit 하면 아래와 같은 형태가 된다.

origin 은 원격저장소의 닉네임이다. 회색 사각형의 origin/master 는 원격저장소 밑의 master 브랜치 임을 알 수 있다.

녹색사각형은 로컬저장소를 가리킨다.

HEAD 는 내가 현재 보고 있는 위치를 가리키는 포인터이다.