개발 협업에서 Git & GitKraken 사용하기

 

깃과 깃크라켄 사용법을 가장 기초부터 실전 활용법까지 설명하고 있습니다.

깃이란?

깃은 버전 관리 시스템!

기말과제, 기말과제최종, 기말과제최최종, 기말과제진짜최종, 기말과제이게찐임
이렇게 네이밍 해보신 적 있으신가요?

내용을 덧붙이거나 수정하면서 새로운 파일을 만드는 건데, 우리는 이걸 조금 더 고급스러운 단어로 '버전 관리'라고 합니다.

깃은 바로 이 버전 관리를 도와주는 시스템입니다!

 

협업에 사용하는 깃

우리가 깃을 사용할 때 gitHub 등의 원격 깃저장소를 사용하는데, 이 점 덕분에 우리가 협업할 때에도 깃을 사용하게 됩니다.

gitHub는 우리가 git을 인터넷(원격) 상에 올려두고 각자의 컴퓨터(로컬)에 그 파일을 다운받아 작업 후 변경 내용을 다시 인터넷(원격)으로 올리는 방식으로 깃을 관리해주고 있습니다.

그럼 이제 내 컴퓨터에만 저장되어 있는 파일이 아니라 인터넷 상에 업로드 되어 있어서 모두가 접근 가능하기 때문에 다른 사람과도 협업이 가능해지게 됩니다!

누구든지 gitHub에 들어가서 해당 폴더를 다운받기만 하면 작업이 가능한 거죠.

 

+) 깃 용어 정리 (원격, 로컬, 레포)

위에서 제가 괄호 안에 원격, 로컬 등의 어려운 단어를 사용했는데 깃을 다룰 때 사용되는 단어들부터 간단히 훑고 갑시다!

앞에서 gitHub를 git을 인터넷에 올리는 거라고 했는데, 이때 gitHub를 원격, 리모트(remote) 등으로 부릅니다.
반대로 내 컴퓨터에 있는 파일은 로컬(local)이라고 합니다.

우리에게 조금이라도 더 친숙한 구글드라이브를 예로 들어보면,
구글 드라이브를 원격, 리모트 / 우리 휴대폰이나 컴퓨터에 저장되어 있는 파일을 로컬이라고 부르는 거죠!

그래서 각 위치에 있는 저장소들을 저장소를 의미하는 영어 단어인 repository를 써서 리모트 레파지토리, 로컬 레파지토리라고 부르는데, 사실 짧게 '레포'라는 표현을 더 자주 사용합니다.

 

깃크라켄이란?

깃크라켄: 깃 GUI 툴

깃크라켄(gitKraken)은 기존 CLI 바탕에서 이뤄지는 git 작업들을 우리에게 익숙한 그래픽과 버튼으로 보여주는 깃 GUI 툴입니다.

깃을 처음 사용하는 분도, 깃을 어느 정도 사용해 본 분들도 깃크라켄의 직관적인 브랜치 구성 표현, merge conflict 해결 과정 undo 기능 등을 통해 깃에 더 친숙하게 다가갈 수 있는 것 같아요!

 

깃크라켄 다운 받기

깃크라켄은 https://www.gitkraken.com/ 여기서 다운로드 할 수 있습니다!

 

깃크라켄 프로 라이센스 받기 (학생)

만약 깃허브 학생 인증으로 프로를 사용하고 있다면 깃크라켄 홈페이지에서 깃허브 계정으로 로그인 해 무료로 깃크라켄 프로 라이센스를 받을 수 있습니다!

깃크라켄 무료 라이센스로는 private repository를 사용할 수 없기 때문에 꼭 프로로 업그레이드 해서 사용하시는 걸 권장합니다!

 

사담) 깃 초보자에게는 깃크라켄을 추천합니다

깃을 CLI로 처음 접하려고 하면 많은 명령어와 직관적이지 않은 사용법에 일찍 포기하고 깃을 어렵다고만 느끼게 되기 쉬운 것 같아요.

깃크라켄의 모든 기능은 CLI로 표현이 가능합니다. 따라서 깃크라켄으로 깃을 입문해 깃의 개념에 대해 확실히 파악하고 난 후에 '깃크라켄의 이 버튼을 CLI 명령어로 쓰면 어떻게 되는 거지?' 고민하고 검색해보며 연결 짓는 방식으로 깃을 학습하는 걸 추천하고 싶습니다.

 

깃 & 깃크라켄 사용법

우리가 깃을 사용할 때 기계적으로 add, commit, push를 하는데
이건 왜, 무엇을 위해 하는 걸까요?
그리고 각각의 명령어가 끝나면 어떤 변화가 생길까요?

 

작업폴더(Working Directory)의 구성

파일 추적 여부 - 추적 & 추적 안 함 (gitignore)

워킹 디렉토리는 추적 여부에 따라 크게 변화가 생기면 추적을 하는 파일과, 변화가 생겨도 추적을 하지 않는 파일 이렇게 두 개로 나눠집니다.

변화가 생겨도 추적을 하지 않는 파일은 주로 내가 건들지 않아도 시스템상 자동으로 생성되거나 변경되는 파일, 그러나 프로젝트에는 영향을 미치지 않는 파일들입니다. 이건 gitignore로 관리하게 됩니다!

gitignore 처리 된 파일들은 변화가 생겨도 추적되지 않고, 당연히 git의 add와 commit 과정에도 전여 관여하지 않게 됩니다.

그 외 나머지 모든 것들은 우리가 git status 명령어를 입력했을 때 그 변경사항이 보이게 됩니다.

 

파일 추적 상태

gitignore가 아닌 모든 추적되는 파일은 다시 세 단계로 나뉘는데요, 변경없음(unmodified), 변경함(modified), 스테이지됨(staged) 단계가 존재합니다.

unmodified는 말 그대로 변경이 되지 않은 파일, modified는 변경이 된 파일인데, staged는 뭘까요?

결론부터 말하자면, modified 상태의 파일을 git add 하면 staged 상태가 됩니다.

 

add, commit: 체크포인트

git이 버전 관리 시스템인만큼, 파일에 변동이 생겼을 때 나중에 복구하기 쉽게, 변동 내역을 알아보기 쉽게 적당히 체크포인트를 찍어주는 게 중요합니다.

이렇게 변경이 된 상태에서 체크포인트를 만드는 일을 '커밋한다(commit)'라고 하고, git commit 명령어를 사용합니다.

commit은 주로 기능 단위로 하고, 그리고 이렇게 해야 코드 리뷰할 때 보기 편합니다! 예를 들면, 퍼블리싱도 코드를 짜는 사람에 따라 다르겠지만 저는 컴포넌트 구성, 스타일 적용, 기능 함수 구현 등으로 나눠 각각 commit을 하는 편입니다.

그런데 만약, 개발이 너무 손에 잘 잡혀 여러 가지 일을 한 번에 해버렸다면 어떻게 해야 할까요?

이런 경우를 위해 staged 단계가 존재합니다.
staged는 commit을 위한 준비 단계로, modified 된 파일 중 선택적으로 파일을 stage해서 해당 내용만 commit 할 수 있게 합니다.

이 부분을 깃크라켄에서 보면 우측 패널에서 맨 위에 있는 Unstaged Files가 modified(변경)된 모든 파일, Staged Files가 staged된 파일입니다.

Stage all changes 버튼을 통해 변경된 모든 파일을 add 할 수 있고 (git add .)
파일 이름 위에 마우스를 올리면 나오는 Stage File 버튼을 눌러 개별 파일만을 add 할 수도 있습니다 (git add [파일이름]).

그 후 Staged Files를 commit 하기 위해 하단에 커밋 메시지를 적고 Commit changes to [n] files 버튼을 누르면 커밋이 됩니다! (git commit -m "[커밋메시지]")

추가로, staged 된 파일을 취소하고 싶은 경우 Unstage all changes 버튼이나 파일 이름 위에 마우스를 올리면 나오는 Unstage File 버튼을 누르면 add 하기 전 상태로 돌아갑니다!

 

add 더 똑똑하게 하기!

위에서는 파일 단위로만 add 하는 방법을 보여줬는데, 깃크라켄에서는 더 세세한 변경내용 add가 가능합니다.

우측 패널에서 파일 이름을 누르면 파일 변경 내용이 보이는데, 여기서 stage hunk를 누르면 파일 전체가 아닌 해당 부분만 stage 하는 것도 가능합니다.

저는 이 기능을 폭주기관차처럼 코드를 쓰고 난 뒤에 기능1 먼저 커밋하고, 기능2 커밋하고, 기능3 커밋하고 이런 식으로 한 파일 내에서 커밋을 쪼갤 때 종종 사용합니다.

또 라인 별로 stage를 관리할 수도 있는데 코드 맨 왼쪽에 마우스를 가져다 대면 + 버튼이 나옵니다! + 버튼을 눌러 줄 별로 따로 stage 할 수도 있습니다.

 

작업 내용 없애기

가끔은 작업하고 나서도 코드가 점점 더 꼬여만 가는 것 같아 그 전 체크포인트로 그냥 돌려버리고 싶다 생각할 때도 생기는 것 같아요.
이럴 때 지금 작업하고 있던 내용을 모두 날리고 마지막 체크포인트(commit)로 가는 방법은 우측 패널에 있는 휴지통 아이콘을 누르는 것입니다. (git checkout .)

만약 특정 내용만 날리고 싶다면 파일 이름을 누르고 들어가 Discard Hunk 버튼을 눌러주시면 그 부분만 삭제됩니다!

 

push, pull: 리모트와 로컬의 동기화

이렇게 commit을 하면 그 커밋 내역은 내 컴퓨터에만 저장되어 있는 상태입니다. 하지만, 협업을 하려면, 또는 다른 컴퓨터로 옮겨 현재 하고 있던 작업을 이어서 하려면 리모트에 업로드가 되어 있어야 하겠죠! 이렇게 리모트로 업로드 하는 작업을 push라고 합니다. (git push)

반대로 리모트에 있는 내용을 로컬로 동기화하는 건 pull이라고 해요. (git pull) 사실 pull은 fetch와 merge가 합쳐진 개념입니다.

여기서 fetch는 가져오기, merge는 병합하기 기능인데요, 단순히 리모트의 작업 내용을 가져와서 보기만 하고 합치고 싶지 않다면 fetch를 하면 됩니다. fetch 한 후 내용을 확인하고 삭제하면 내 브랜치에는 아무 영향도 일어나지 않습니다. 하지만, 작업 특성 상 가져와 보기만 하는 경우보다 가져와서 합치는 경우가 더 많아 이를 pull로 묶어서 기능 제공을 하기 시작했다고 합니다.

직관적으로 생각해봤을 때 push는 미는 거니까 내가 작업한 내용을 리모트로 밀어올리는 것, pull은 당기는 거니까 리모트에 있는 파일을 내 컴퓨터로 당겨오는 것이라고 생각하면 기억하기 쉽습니다.

깃크라켄에서는 상단 push, pull 버튼을 통해 간편하게 할 수 있습니다.

 

브랜치 관리하기

브랜치란?

혼자 작업할 거라면 앞에서 설명한 add, commit, push만 해도 되지만, 협업을 하기 시작하면 브랜치 관리라는 걸 해야 합니다.

브랜치 개념이 생소하실 분들을 위해 간단한 예를 하나 들어볼게요.

초등학교 대청소 날이라고 합시다.
선생님과 학생들이 다같이 교실에 물을 뿌리고 비누칠을 하고 쓸고 닦고 하고 있었어요. 어느 정도 청소가 마무리 되어가자 선생님이 한 학생에게는 대걸레 빨아와~ 라고 하시고 다른 학생에게는 쓰레기통 비우고 와~ 라고 하시고 나머지 학생들에게는 책상 원위치하자라고 했다고 가정합시다.

그러면 이 세 학생은 서로에게 전혀 영향을 주지 않는 다른 미션들을 하고 오겠죠? 하지만 이 학생들이 최종적으로 교실로 돌아왔을 때는 대걸레도 빨아져있고, 쓰레기통도 비워져 있고, 책상도 원위치 되어 있는 깨끗한 교실의 상태가 되어 있을 거예요.

이렇게 어떤 한 시점(청소가 마무리되어가는 시점)에서 서로에게 전혀 영향을 주지 않는 서로 다른 행위(대걸레, 쓰레기통, 책상)를 하기 위해 우리는 브랜치를 생성합니다. 여기서는 선생님이 학생들 한 명 한 명을 브랜치로 만든 거라 생각하시면 돼요. 각각 브랜치에서 작업이 끝나면 다시 학생들이 교실로 돌아와 대걸레를 청소도구함에 넣고 쓰레기통을 원래 자리에 두듯이 원래 있던 브랜치로 그 작업을 모두 합치는 일을 합니다.

조금 더 개발자적인 설명으로 브랜치 설명을 마무리해볼게요.

우리가 소프트웨어를 하나 개발한다고 하면 여러 사람이 함께 개발을 시작합니다. 하지만 작업 폴더는 하나만 만들죠. 여기서 동시에 작업을 하려고 하면 정말 다양한 문제가 발생할 거예요. (구글 docs나 노션 동시 편집 사용해보신 분들은 공감하실 거예요)

그래서 개발자들이 동시에 작업을 하지만 서로에게 전혀 영향을 주지 않도록 해주는 게 이 브랜치 기능입니다. 각자 독립적인 영역을 가지고 작업을 한 후에 작업이 끝나면 합치게 되죠. 브랜치를 생성하면 다른 브랜치의 파일이나 작업 내용은 전혀 보이지 않게 됩니다. 그러다 브랜치를 합치면 원래 브랜치와 합쳐진 브랜치의 두 내용이 모두 나타나게 되죠!

그래서 보통 브랜치는 기능 단위로 만드는 경우가 많습니다.

 

브랜치 만들기

브랜치를 만드는 방법은 깃크라켄에서는 매우 간단합니다.

우선 새로운 파생 브랜치를 만들고 싶은 곳을 고른 후 브랜치 이름 오른쪽 ...을 눌러 create branch here을 클릭합니다. 그러면 브랜치 이름을 입력할 수 있도록 하는 창이 뜨는데, 이름을 입력한 후 엔터를 치면 원래 브랜치의 작업 내용을 모두 가지고 있는 새로운 브랜치가 만들어집니다!

 

브랜치 merge 방법

앞에서 설명했듯 브랜치에서 작업이 끝나면 병합을 하는 과정을 거쳐야 합니다.

여기서 병합하는 방법에는 크게 3가지가 있어요. merge, squash and merge, rebase and merge 순서대로 살펴볼게요!

우선 우리가 가장 흔하게 사용하는 merge입니다.
브랜치에서 파생된 브랜치가 작업을 마치고 돌아오면 그 이력을 모두 가지고 원래 브랜치에 그대로 연결시켜주는 형태입니다.
그러면 내가 브랜치를 만들고 난 후에 다른 사람이 원래 브랜치에서 무슨 일을 얼마나 했든 상관없이 merge를 할 수 있습니다.

squash and merge는 내가 다른 브랜치에서 한 모든 작업을 원래 브랜치로 합칠 때는 하나의 커밋으로 가져오는 것을 말합니다.
커밋 이력이나 브랜치 개수가 많아지면 브랜치 구조를 깔끔하게 유지하기 위해 squash and merge를 사용합니다.

마지막으로 rebase and merge는 다른 브랜치에서 작업했던 커밋을 원래 브랜치로 가져오며 그 내역을 모두 브랜치 앞에 붙이는 걸 의미합니다.
여기서 merge와 가장 큰 차이점은 merge는 merge commit 기록이 커밋으로 남지만, rebase의 경우에는 그 기록이 남지 않아 마치 원래 브랜치에서 모두 작업한 것처럼 보인다는 것입니다.

추가로, 브랜치 merge가 끝나면 리모트에 있는 파생 브랜치는 삭제해줘야 합니다. 어차피 로컬에 있는 브랜치에는 영향을 미치지 않기 때문에 다같이 사용하는 리모트는 깔끔하게 유지해주는 거죠!

 

브랜치 merge conflict 해결

브랜치를 여러 개 만들어 서로 다른 브랜치에서 같은 부분을 수정한 후 병합하려고 하면 git이 자동으로 병합해주지 못해 merge conflict가 일어나고 사람이 직접 이를 해결해줘야 하는 상황이 생깁니다.

절대 겁 먹을 필요 없어요!
깃크라켄은 이 과정을 아주 편리하게 해결해주고 있습니다.

merge를 하고난 후 conflict가 일어나면 우측 패널 상단 박스에 충돌이 일어난 모든 파일을 보여줍니다. 그 파일을 클릭해 들어가면 어디서 충돌이 났는지 보여줘요. (여기서 파일 이름 위에 마우스를 올렸을 때 나타나는 mark as resolved를 누르지 않도록 주의해야 합니다)

우리가 할 일은 충돌이 난 부분을 차례로 확인하고 어떤 부분을 살려야 할지 정해주는 일입니다.

왼쪽과 오른쪽 브랜치에서 살릴 부분을 각각 체크박스로 클릭해주고 (만약 두 내용 모두 살려야 한다면 두 부분에서 다 클릭할 수 있습니다) 하단 화살표 버튼을 통해 다음 충돌난 부분으로 이동 후 다시 체크, 이 과정을 반복합니다. 그러면 체크박스 표시에 따라서 아래 output에 결과물이 표시될 거예요. 여기서 체크박스를 맞게 표시해줬는지, 이대로 병합이 된다면 우리가 의도한 결과물이 될 것인지 확인해주면 됩니다.

파일을 하나하나 모두 확인해줬다면 commit and merge를 눌러 합쳐주면 됩니다.

 

브랜치 전환

깃크라켄에서는 브랜치 이동을 좌측 패널 브랜치 이름을 더블클릭하는 액션으로 제공하고 있습니다.

로컬에 있는 브랜치도 더블클릭하면 이동할 수 있고, 리모트에 있는 브랜치도 더블클릭 시 로컬로 받아오고 이동하는 작업을 모두 자동으로 해줍니다.

깃크라켄에서는 워킹디렉토리가 비지 않았는데 브랜치 이동을 하려고 할 때 auto stash를 해주거나 브랜치를 이동할 수 없다는 에러 메시지를 띄워주는데, CLI에서는 경고 없이 작업 내용을 모두 날려버리니 주의가 필요합니다!

 

커밋 관리하기

커밋 되돌리기 - reset

만약 커밋을 했지만 해당 커밋을 취소하고 싶은 경우가 생긴다면 어떻게 해야 할까요?

이럴 때를 위해 git은 reset 기능을 제공하고 있습니다. reset은 soft, mixed, hard 세가지로 나눠집니다.

우선 soft reset은 커밋 기록은 지우지만 커밋 했던 모든 작업내용을 staged 상태로 올려줍니다.

mixed reset은 커밋 기록을 지우고 커밋 했던 모든 작업 내용을 unstaged로 올려줍니다.

hard reset은 가장 위험한 reset 방법입니다. 커밋 기록도 지우고 그 안에 작업물도 모두 날려버립니다.

깃크라켄에서는 되돌리고자 하는 커밋을 우클릭하면 reset 옵션이 나타납니다. 여기서 삭제하고자 하는 커밋이 아닌 되돌리고자 하는 커밋의 상태를 클릭해야 함을 주위해야 합니다!

예를 들면 커밋이 1, 2, 3 순서대로 있다고 할 때, 3을 지우고 2의 상태로 되돌리고 싶다면 3으로 리셋하는 것이 아니라 2로 리셋해야 합니다.

 

커밋 안전하게 되돌리기 - revert

reset은 커밋을 아예 지우는 것이기 때문에 깔끔하기도 하지만 자칫하면 위험해보입니다. 그럴 때 제가 추천하는 방법이 revert입니다.

revert는 커밋을 지우지 않고 되돌린 내용을 새로운 커밋으로 쌓아 올립니다. 그러니 예전에 커밋 했던 이력도 남아있고, 내가 커밋을 되돌리고자 하는 목적도 달성하는 거죠.

깃크라켄에서 revert를 하면 바로 커밋을 하겠냐는 문구가 나옵니다. 여기서 yes를 클릭하면 revert 내용을 확인하지 않고 바로 커밋이 되고, no를 누르면 해당 커밋에서 작업한 내용을 staged files에 올려주기 때문에 내가 직접 파일을 열어 어떤 작업이 있었는지 확인하고 commit을 하거나 unstage 후 discard change를 할 수 있습니다.

단점이 있다면 커밋 이력이 복잡해진다는 건데, 초보자에게는 그런 것보단 깃을 꼬이게 하지 않는 게 더 중요하니 revert를 추천하는 편입니다.

 

force push / pull ?

reset을 하고 난 후에 리모트로 Push를 하려고 보면 force push나 pull 둘 중 하나를 선택해야 한다는 문구가 나올 때가 있습니다.

리모트에는 reset 하기 전 커밋이 남아있는데, 로컬에서 reset 후 새로운 커밋을 만들어버려 버전에 차이가 나게 되면 나오는 경고문구입니다.

여기서 로컬의 버전을 유지하고 싶다면 force push를 하면 되고, 만약 다른 사람이 내 브랜치에서 작업한 내용이 있어 그 내용을 유지해야 하는 상황이라면 pull을 하면 됩니다.

 

stash & pop: 임시저장

작업 내용은 있는데 커밋은 못 하겠고 일단 그걸 어딘가에 저장해두고 다른 작업 해보고 싶다 하신 적이 있으신가요?

그럴 때 사용할 수 있는 게 임시저장, stash 기능입니다.

stash를 하면 지금 작업하던 내용물 모두가 임시저장소로 가고 폴더 상태는 제일 마지막 커밋했던 상태로 돌아가요.

저같은 경우는 개발하다 욕심이 생겨 저도 모르게 새로운 기능을 연습하다가 정신차리고 다시 개발해야지 할 때 그 새로운 기능 연습하던 작업물을 stash 해놓고 다시 개발에 집중하는 방법으로 활용합니다.

반대로 임시저장 했던 걸 다시 꺼내서 보고 싶을 땐 pop을 하면 됩니다!

스태시한 내용들은 왼쪽 패널 STASHES에 모두 저장되고 stash 한 순서나 브랜치에 상관없이 pop 해서 꺼낼 수 있습니다!

 

깃크라켄 똑똑하게 사용하기

브랜치 현황과 commit 한 사람 보기

깃 크라켄은 가운데 메인 화면에 브랜치가 어떻게 생성되고 어떤 작업이 이뤄지고 있는지, 어떻게 병합되었는지를 모두 보여줍니다.

여기서 깃허브에 등록된 사진이나 로고가 있는 건 리모트, 컴퓨터 모양은 로컬로 각각의 HEAD(현재 위치하는 곳을 가리키는 손가락)가 어디 있는지도 알려주고 있어요.

그리고 커밋 동그라미 위에 마우스를 올려보면 누가 커밋을 했는지도 알 수 있어 누가 어떤 작업을 하고 있는지 알 수 있습니다. 또 나중에 merge conflict가 생기거나 했을 때 누구에게 연락해야 할지도 바로 알 수 있어요!

 

브랜치 이름 옆 화살표의 의미

로컬 저장소의 브랜치 이름 옆을 보면 화살표가 생길 때가 있습니다.

리모트 저장소에 있는 같은 브랜치와 비교해 로컬 브랜치의 커밋이 몇 개 앞서있는지, 뒤처져있는지를 표시하고 있는 건데요, 간단히 말하면 위 화살표는 Push 했을 때 리모트 브랜치에 등록될 커밋 개수를, 아래 화살표는 Pull 했을 때 가져와질 커밋 개수를 의미합니다.

만약 두 화살표가 모두 보이고 있다면 force push나 pull을 해야 하는 상황입니다.

 

undo 기능 활용하기

깃크라켄은 undo 기능을 제공하고 있습니다.
손가락이 미끄러져 commit 버튼을 잘못 눌렀을 때, 실수로 브랜치를 만들어버렸을 때 등등 유용하게 활용해보세요!

 

stash 기능 활용하기

feat 브랜치를 만들어 작업해야 하는데, 실수로 develop 브랜치에서 작업해버렸다면???

일단 심호흡을 한 번 합니다. 후 ... ~

그 후 stash 버튼을 누르고 브랜치 이동 후 pop을 하면 develop에서 했던 작업이 모두 이동한 브랜치로 가져와져 있고 develop 브랜치는 깔끔한 걸 확인하실 수 있습니다!

 

커밋 메시지 수정하기

CLI에서 커밋 메시지를 잘못 적었다면, 설상가상 그 이후에 다른 커밋을 또 해버렸다면 커밋 메시지를 수정하기 매우 귀찮아지겠지만 깃크라켄에서는 이 작업을 자동으로 해주고 있습니다.

push를 하지 않은 커밋은 커밋 메시지를 누르면 '이 커밋 메시지를 수정하면 [n]개의 커밋을 리베이스하게 됩니다'라는 메시지가 뜨지만 별로 무섭지 않습니다. 그냥 커밋 메시지 수정하고 update message를 클릭하면 자동으로 수정 후 다른 커밋들은 다시 원상복귀 시켜줍니다. 우리는 어떤 과정을 거쳐 이 커밋 메시지가 수정됐는지도 모르게요!

사실은 위 커밋들을 지우고 커밋 메시지 수정된 커밋을 반영한 후에 rebase를 통해 얹어 놓은 거겠죠? 깃크라켄에서는 그런 거 몰라도 됩니다.

 

브랜치 폴더 만들기

사실 브랜치 폴더라는 개념이 존재하는지는 잘 모르겠지만, 깃크라켄에서 브랜치 이름을 [폴더이름]/[브랜치이름]으로 설정해주면 브랜치 폴더가 만들어집니다.

그래서 폴더 안에 하위 브랜치들이 있는 모양으로 브랜치 관리가 가능합니다.