이전 시간에는 기초적인 Git의 사용법에 대해서 모두 배워 보았다.
이번에는 Git에서 사용되는 여러 기능들을 살펴보자.
1. Amend
Amend는 Commit에서 누락된 변경 사항이 있을때, 방금 만들어진 커밋에 추가하는 명령이다.
예를 들어, 다음과 같이 변경사항이 발생했다고 생각해보자.
ReamMe File에 Amend Test용이라는 코드를 입력했다고 가정하자
그리고 Index.html에 p태그를 추가하여 Amend Test용이라는 글귀를 추가하였다.
그리고 Amend Test라는 Commit을 만들었다.
그런데 알고보니 우리가 추가해야할 Amend Test에서 App.js에 누락된 코드가 있었다고 가정해보자.
물론, Commit을 새로 추가하여 Commit 메시지를 Amend Test 추가와 같은 식으로 작성하여 해결 할 수도 있다.
하지만 엄밀히 말하면 같은 버전, 같은 기능을 구현한 코드는 하나의 Commit에서 관리하는 것이 올바른 버전관리를 하는 것이라고 할 수 있다.
저런 식으로 추가의 추가본을 만들게 되면 애시당초 버전관리를 하는 의미가 퇴색될 수 있기 때문이다.
이런 경우, Amend 명령을 통하여 마지막 Commit을 수정할 수 있다.
소스트리로 Commit할 때, 오른쪽 아래의 커밋 옵션을 눌러보면 마지막 커밋 수정이라는 메뉴를 찾을 수 있다.
해당 버튼을 눌러보면 마지막으로 우리가 Commit 한 Amend Test라는 Commit이 불러와 지며 해당 Commit을 수정할 수 있게 된다.
다만 이렇게 히스토리를 변경시키는 명령은 여러 작업자가 사용하는 Branch에서 작업할 경우 자칫하면 코드가 크게 꼬이는 사태가 발생 할 수 있기 때문에 반드시 혼자 쓰는 Branch를 따로 떼어내어 작업을 진행하는 것이 안전하다.
2. Stash
stash는 변경사항을 commit하기 전에 잠깐 보존해두는 용도로 사용하는 명령이다.
예를 들어서 우리가 A라는 기능을 구현하고 있다고 가정해보자.
기능을 반정도 구현을 하였는데 갑자기 팀장님이 오시더니 급한 수정건이 있으니 다른 Branch에서 B라는 기능을 수정해달라고 요청을 하셨다.
이런 경우 Branch를 옮겨 원격 저장소의 코드를 받아야 하기 떄문에 지금 있는 코드를 Commit 하지 않으면 로컬에서 우리가 작성하였던 A 기능의 코드는 모두 날아가게 될 것이다.
그렇다고 Commit을 하자니 아직 미완성의 코드를 Commit 시켜 전체 앱 자체가 동작하지 않는 상황이 벌어질수 있다고 생각해보자.
이럴때 사용하는 것이 Stash라는 기능이다.
Commit을 하기 전에 잠깐 보관하는 용도로 사용되며 서랍에 넣어두는 것처럼 코드를 잠깐 보관했다가 다시 꺼내올 수 있다.
(단, Tracked인 것만 들어가기 때문에 추적이 안되는 파일은 Stash 할 수 없다.)
그럼 소스트리를 통해 직접 실습해 보자.
우선 코드의 변경사항을 만들어 커밋되지 않은 변경사항을 만든다.
현재 우리는 app.js에 Stash Test용 코드 작성이라는 변경사항을 작성한 상태이다.
그후 리본 탭의 스태시라는 버튼을 누르면 Stash에 대한 메시지를 입력하는 창이 나타난다.
메시지 입력 후 확인을 누르면 아까 우리가 만든 커밋하지 않은 변경사항이 사라진 것을 확인 할 수 있다.
그러면 이 상태에서 다른 Branch로 넘어가 작업을 진행한 후 다시 A 기능 작성을 위하여 Stash를 가져온다.
Stash된 것을 가져오는 것을 Pop이라고 부르며 화면 왼편의 스태시를 눌러 우리가 저장해 두었던 Stash를 확인할 수 있다.
가져올 Stash에서 우클릭 후 스태시 적용을 누르거나 더클릭을 하여 pop 시킬수 있다.
Pop을 하게 되면 히스토리에 아까 우리가 작업하였던 커밋하지 않은 변경사항이 나타나는 것을 확인 할 수 있다.
3. Reset
Reset은 이름 그대로 예전 버전으로 Branch를 되돌리는 명령어이다.
예를 들어 다음과 같은 Commit 히스토리가 있다고 생각해보자.
여기서 우리는 Amend Test를 수행하기 전 충돌 해결 완료 Merge가 수행되었던 상태로 돌아가고자 한다.
Reset을 하는 방법은 간단한데, 돌아가기를 원하는 Commit을 우클릭 한 후 이 커밋까지 현재 브랜치를 초기화를 누르면 된다.
초기화하기를 누르면 모드를 선택하는 창이 나오게 된다.
모드는 총 3가지가 있으며, Soft, Mixed, Hard가 있다.
각 모드별 기능은 이미지를 참고하기 바란다.
우선 우리는 이전 변경사항을 모두 버릴 것이므로 Hard를 눌러 Reset을 진행해 보도록 하겠다.
그러면 로컬의 master가 충돌 해결완료 Commit으로 이동한 것을 확인 할 수 있다.
그런데 원격저장소(Origin)의 위치를 보면 아직 Commit이 그대로 남아 있다.
우리는 충돌해결 완료로 돌아왔으므로 이 상태의 코드를 Push하여야 원격 저장소의 Brach까지 동기화 시킬 수 있다.
하지만 실제로 Push를 시켜보면 에러 메시지가 뜨면서 Push가 되지 않는 것을 볼 수 있다.
에러가 나타나는 것은 이 작업이 히스토리를 변경하는 파괴적인 작업이기 때문이다.
이 때문에 이런 경우 force Push라고 하여 조금더 강력한 명령이 필요하며 앞서 설명했듯이 이런 파괴적인 작업인 경우 반드시 혼자 사용하는 Branch에서 수행할 것을 권장한다. (코드가 꼬이는 참사를 막기 위함이다.)
그렇다면 force Push를 수행해보도록 하자.
소스트리에서 force Push를 하기 위해선 약간의 설정 변경이 필요하다.
우선 상단의 도구에서 옵션으로 들어간다.
그 후, Git 탭으로 이동해 보면 강제 푸시 가능이라는 옵션이 있다.
이 부분을 체크를 해주어야 force push가 가능해진다.
해당 체크박스를 체크해주면 Push 진행시 강제 푸시라는 옵션이 생기게 된다.
그러면 강제 푸시에 체크를 해주고 Push를 진행한다.
그러면 다음과 같은 경고창이 나타난다.
앞서 설명했듯이 이런 작업은 히스토리를 변경하는 파괴적인 작업이기 때문에 거기에 대한 경고를 해주는 것이다.
(반드시 혼자 쓰는 Branch에서 하는것을 권장한다.)
Push를 진행하고 정상적으로 처리가 된다면 Reset한 이후의 Commit 목록이 전부 사라진 것을 확인 할 수 있다.
이렇게 되면 이제 되돌릴수 없기 때문에 반드시 Hard Reset을 진행해도 문제가 없는지 확인이 필요하며 코드가 꼬이는 것을 방지하기 위하여 혼자만 사용하는 Branch에서 진행을 하여야한다.
*추가적으로 모드에 대해서 조금 설명하자면 Mixed의 경우 이후의 Commit들을 로컬에 저장하여 커밋되지 않은 변경사항으로 남겨주고 Soft 모드로 하면 Commit 자체를 그대로 남겨준다.
4. Revert(Reverse)
Revert는 Reset처럼 Commit을 되돌리고 싶을 때 사용하는 명령이다.
다만 차이가 있다면 Reset은 히스토리 자체를 변경하지만 Revert는 기존 히스토리는 그대로 두고 새로운 Commit을 생성한다는 차이가 있다.
그럼 실제로 Revert를 수행해 보도록 하자.
우선 코드를 수정하여 커밋 실수라는 메시지의 Commit을 만들었다.
실제로는 잘못된 코드가 Commit 된것이라고 생각하면 더 좋다.
그러면 다른 사람들이 해당 Commit으로 진행되지 않도록 다시 되돌려야 한다.
이때 우리는 Reset과 Revert 중 선택하여 사용할 수 있다.
하지만 앞서 말했듯 Reset의 경우 개인이 사용하는 branch에서만 사용하는것이 좋기 때문에 만약 다른 사람이 충돌해결완료 라는 Commit에서 코드를 수정하고 있었을 경우 충돌이 발생하게 된다.
Revert는 이런 상황에서 새로운 이력을 만들어 잘못된 Commit을 날리는 명령이다.
방법은 간단한데 Revert 할 commit을 우클릭 하여 커밋 되돌리기를 눌러준다.
그러면 Revert "커밋 실수"라는 새로운 Commit이 생성된 것을 확인 할 수 있다.
해당 Commit을 살펴보면 이전에 작성하여 Commit 했던 Revert Test라는 텍스트가 삭제된 것을 볼 수 있다.
즉, 우리가 선택한 특정 Commit의 상태로 코드를 되돌려 원상 복구 시키는 Commit을 만드는 것이다.
이력을 남기며 Commit을 되돌릴 필요가 있을 때 사용하면 유용하게 쓸 수 있을 것이다.
5. Cherry-Pick
Cherry-Pick은 원하는 많은 Commit 중 특정 Commit을 하나 선택하는 기능이다.
보통 특정 Commit을 픽하여 다른 Branch에 붙여야할 때 사용한다.
그럼 직접 실습하며 Cherry-Pick에 대해서 알아보자.
우선 다른 Branch를 하나 생성하여 분기를 나누어 준다.
나는 CherryPickTest라는 이름으로 분기를 생성하였다.
그 후 해당 Branch에 새로운 코드를 추가하여 Commit을 생성한다.
나는 체리픽 테스트와 일반 코드 추가라는 2개의 Commit을 생성하였다.
그후, Branch를 master로 옮겨서 새로운 Commit을 생성한다.
나는 일반 기능 추가 2,3을 만들었다.
이 상황에서 만약 체리픽 테스트에 있는 코드만 합쳐야 한다고 가정해보자.
Merge를 이용하는 경우 필요없는 일반 기능 추가라는 Commit에서 수정한 코드들이 같이 합쳐지게 될 것이다.
Cherry-Pick 기능은 이렇게 CherryPickTest에서 일반 기능 추가는 필요 없고 체리픽 테스트에 대한 Commit 내용만 필요한 경우 사용하게 된다.
그럼 원하는 Commit인 체리픽 테스트에서 우클릭을 하여 체리픽이라는 버튼을 누른다.
그럼 체리픽에 대한 설정 창이 나오게된다.
체크된 옵션은 충돌이 없으면 즉시 Commit을 시켜주는 옵션이고 아래의 옵션은 Merge Commit 생성시 메세지에 Commit된 Id를 포함시켜주는 옵션이다.
확인을 눌러 진행하면 다음과 같이 히스토리가 표시된다.
이미지를 보면 기존에 CherryPickTest Branch에 있던 체리픽 테스트라는 Commit이 master Branch에 새롭게 추가된 것을 확인 할 수 있다.
'Git' 카테고리의 다른 글
| Git - Pull Request 사용해보기 (0) | 2024.01.03 |
|---|---|
| Git - Fork : 저장소 복제하기 (1) | 2024.01.02 |
| Git - 충돌과 충돌 해결 실습해보기 (1) | 2023.12.30 |
| Git - Merge와 Conflict (0) | 2023.12.29 |
| GIT - Branch 나누기 (2) | 2023.12.29 |