소스트리 완벽분해 가이드 (2) Revision - Discard, Reset, Revert

안녕하세요.
휴몬랩 초보 안드로이드 앱 개발자(Ho Park)가 작성하는 초보 안드로이드 앱 개발자를 위한 글 입니다.

이 글은 초보 개발자 기준으로 개인적인 생각과 경험을 바탕으로 작성되었습니다.

이번 페이지에서는 소스트리의 작업 되돌리기 Revision에 관련해서 한번 파헤쳐볼까 합니다. 어찌보면 가장 어렵고 헷갈리고 잘못하면 작업이 다 꼬여버려서 더 이상 손 쓸 수 없을정도로 변해버려 백업해둔 파일을 다시 불러온 경우가 생기게ㄷ….
생각조차 하기 싫을 정도입니다!!
그래서 첫 번째 심화단계로 이 부분을 먼저 하나씩 자세하고 쉽게 최대한 잘 파 보는게 어떨지 생각이 들더군요 :)

 

이번 페이지에서는 소스트리의 작업 되돌리기 Revision에 관련해서 자세하게 한번 파헤쳐볼까 합니다.

어찌보면 가장 어렵고 헷갈리고 잘못하면 작업이 다 꼬여버려서 더 이상 손 쓸 수 없을정도로 변해버려 백업해둔 파일을 다시 불러온 경우가 생기게ㄷ….

생각조차 하기 싫을 정도입니다!!

그래서 첫 번째 심화단계로 이 부분을 먼저 하나씩 자세하고 쉽게 최대한 잘 파 보는게 어떨지 생각이 들더군요 :)

 

 

Revision 은 사전적 의미로 수정(정정), 검토, 변경 이라는 뜻입니다.

흔히 file's history revision 또는 Revision history라고도 하네요.

즉 정정되거나 수정된 파일들을 일컬어 리비전이라고 불립니다.

 

자, 그럼 좀 더 자세하게 파고들어 Discard, Reset, Revert에 대해서 한번 알아볼까요?

 

1) Discard (커밋하기 전, 되돌리기)

Discard 는 취소하기/되돌리기라는 뜻으로 앞에서 짤막하게 설명했었는데요

한국어 버전으로 볼 시에는 " 폐기 " 라는 단어로 나오더군요.

 

위 그림에서 test22.xml 이라는 변경된 코드 파일이 하나 있습니다.
이 파일을 소스트리 상에서 되돌리고 싶을 때..어찌해야 할까요?
우클릭을 하였을 시, 나오는 창에서 Remove, Discard가 있는데 둘 다 비슷한 작업인 것 같은데 왜 따로 있을까요..?

전 한국말로 보면 더 헷갈리더군요 제거와 폐기 ㅎㅎ…

그렇다면 여기서 잠깐 Remove와 Discard의 차이점은 무엇일까요?
Remove는 Stage에 있든 없든 해당 파일을 무조건 삭제합니다.
작업중인 환경(folder)에서 해당 file자체를 삭제해버리죠.
* 꼭 지워져야 하는 경우가 아니라면 함부로 사용하지 않기를 권장합니다!!

Discard는 말 그대로 취소하기/되돌리기 입니다.
위 그림에서 보았을 때 Discard가 비활성 되있는게 보이나요?
하지만 Stage에 올릴경우 활성화가되며 클릭 시, 방금 한 작업을 되돌리게 됩니다.
Stage All 로 올라갔었다면 Discard 후 다시 Unstage All 쪽으로 가지겠죠.
마찬가지로 소스트리 상단 바 부분의  Discard도 활성화 되며, 특별히 여기선 이전 작업들을 한눈에 살펴볼 수 있으며, 되돌리고 싶은 작업을 선택해서 진행할 수 있습니다.

 

• Remove는 꼭 지워져도 상관없다 할 때만 사용할 것!
• Discard는 Commit전 단순히 되돌리는 작업

그렇다면 Commit후 되돌리기는 무엇으로 할까요?
바로 Reset과 Revert입니다.
하나 쓰는것도 힘든데 같은 기능이 왜 두개나 존재하는걸까요..ToT
이유는 과연…?!!

Reset과 Revert 설명에 앞서 한가지 중요한 사항이 있습니다!!
바로 Push에 관련된 내용입니다.

Push 하지 않는 이상 자신만의 브랜치에서 자유롭게 작업 할 수 있지만 로컬 저장소에서 작성한 브랜치를 다른 이들과 공유하려면 push를 통해 원격 저장소로 저장됩니다.

하지만 모두가 함께 공유하고 있는 상황에서 임의로 영향을 끼치면 복잡해질수도 있으니 항상 조심하며 가급적이면 Push나 *Merge는 신중하게 해서 나쁠게 1도 없다는거죠!!ㅎㅎ

 

위에 그림처럼 소스트리 하단부분에 Commit할 때 기본적으로 바로 Push한다는 체크를 해제하고 따로 Push 하는 것을 추천 드립니다.

 

이것을 먼저 설명하는 이유는 이미 Push한 상황에서는 Reset을 해봤자 무의미(?) 하기에 Revert를 사용할 수 밖에 없게 됩니다. 왜 그런지는 Reset과 Revert를 한번 파헤쳐보고 마지막 정리할 때 이해해 볼까요?

 

 

2) Reset (커밋 후, Description을 제거하고 되돌리기)

목록에서 되돌아가고 싶은 버전을 선택하고 마우스 우클릭한 뒤, 'Reset current branch to this commit'을 선택하면 아래의 창이 뜹니다.

• Soft 모드 : Stage에 올라가있으며 Description에 Uncommitted changes라고 남아있는 상태
• Mixed 모드 : Stage에는 올라가지 않은 상태지만 Description에 Uncommitted changes라고 남아있는 상태
• Hard 모드 : Stage에도 Description에도 아무것도 남게되지 않는 상태

잘못된test를 지우고 싶어서 test2 기준으로 Hard mode Reset을 하였을 경우 그 후의 파일(들)은 다 제거된 상태 입니다. 깔끔하죠?

 

• Commit후 Push까지 해버렸다면 Reset은 더 이상 생각하지 않기!!

 

3) Revert (커밋 후, Description에 추가하고 되돌리기)

말은 Revert라 하지만 소스트리상에선 Reverse commit.. 입니다.

 

 

Revert도 Reset과 마찬가지로 동일한 결과를 가져옵니다.
하지만 왜?! 도대체 왜?!! 따로쓰는 걸까요..ㅠㅠ
결과는 같지만 남는 이력은 다르기 때문이죠!

 

위에 Reset에서는 깔끔하게 사라졌다면 Revert는 아래 그림처럼 기록이 남게됩니다.

잘못된test에서 고쳤던 부분이 Revert”잘못된test”에서 되돌려져 있는걸 확인할 수 있습니다.

단 이렇게 되었다..라고 이력이 남게 되는 것 뿐

 

• 여기서 가장 크게 주의할 점은 위에서부터 아래로,
  즉 역순으로, 차례대로 하나씩 Reverse Commit 해야 추후에 Conflict가 발생하지 않습니다.

 

자 이제 그럼 마지막으로 정리를 한번 해볼까요?

Push를 하기 전과 하고 나서에 따라 Reset과 Revert를 사용해야 하는 이유는?!

소스트리 버전관리를 개발자 1인이 사용한다면 상관없겠지만 대게는 2인이상 여럿이서 사용하게 될 경우 문제가 발생합니다.

개발자 A가 Test_A 작업을 완료하고 push를 하였는데 개발자 B가 Pull을 해서 Test_A와 함께 새로운 작업을 시작합니다. 이미 개발자 B가 Test_A를 가지고 작업중인 상황에서 개발자 A는 Test_A에 문제가 있음을 발견하고 되돌려보지만 이미 늦었다는걸 알 수 있겠죠?!! 
즉, 개발자 B가 사용중인 Test_A를 reset으로 없애버릴 수 없기 때문에 revert를 사용하여 되돌려야 하는거죠. 이 와중에 Conflict가 날 수 있지만 잘 해결할 수밖에 없겠죠? ㅎㅎ

 

 

 

다음번엔 Revision에 이어서 Rebase, Cherry Pick, Merge에 대해서 파헤쳐보도록 하겠습니다 :)