00:00:00안녕하세요 여러분, GitButler의 CEO 스콧입니다.
00:00:02오늘은 GitButler의 멋진 기능들을 몇 가지 살펴보고
00:00:05이 Git 클라이언트가 무엇을 할 수 있는지 전반적으로 소개해 드리겠습니다.
00:00:07여기 예시 프로젝트가 하나 있는데요. X(트위터)의 복제판인 'Y'라는 앱입니다.
00:00:12제가 이미 수정한 내용들을 추가하면서
00:00:16커밋 생성, 브랜치 생성, 병렬 브랜치 및
00:00:20스택 브랜치를 만드는 법을 알아보겠습니다. 파일을 수정하면
00:00:25작업 디렉토리에서 수정된 파일들을 보여주는 'Git status'와 비슷한 결과를 볼 수 있습니다.
00:00:30이 파일들을 어떻게 커밋하고 싶으신가요? 여기서 직접 검토할 수 있습니다.
00:00:34application.css, sidebar, index 파일들을 볼 수 있죠? 제가 몇 가지 수정을 해두었습니다.
00:00:39이제 새로운 브랜치를 만들고 이 변경 사항들을 해당 브랜치에 커밋하려고 합니다.
00:00:45방법은 몇 가지가 있습니다. '새 브랜치에 커밋(commit to new branch)'을 누르거나
00:00:49여기서 직접 새 브랜치를 만들 수도 있습니다. 종속 브랜치가 아닌
00:00:54독립적인 브랜치를 만들어 보겠습니다. 스태킹(stacking)은 잠시 후에 설명해 드릴게요.
00:00:57이름을 정하고 브랜치를 생성하면 몇 가지 작업을 할 수 있습니다.
00:01:03먼저 그냥 커밋을 할 수 있습니다. 이 application.css 파일을
00:01:08레인(lane)으로 드래그하여 커밋을 생성하거나, 여기서 바로 커밋을 시작할 수도 있습니다.
00:01:15작은 입력창에 짧은 커밋 메시지를 적거나, 창을 확장해서
00:01:19길고 멋진 커밋 메시지를 작성할 수도 있습니다. 일단은 간단하게 해보죠.
00:01:27또한 이 커밋에 무엇을 포함할지 결정할 수 있습니다. 측면에 세 개의 파일이 있는데요.
00:01:34특정 파일을 제외하는 것뿐만 아니라, 파일 내의 특정 라인만 선택할 수도 있습니다.
00:01:39하지만 지금은 모든 변경 사항을 커밋해 보겠습니다. 아니면 두 개의
00:01:44서로 다른 커밋으로 나눠보죠. 이 커밋에는 사이드바 수정 사항을 넣지 않겠습니다. '프런트엔드 수정' 커밋 하나와
00:01:48또 다른 '사이드바 수정' 커밋을 만들었습니다. 이제 새 브랜치에 두 개의 커밋이 생겼네요.
00:01:55제가 좀 게을러서 Claude code를 사용해 작업을 진행해 보겠습니다. 테마를
00:01:59파란색에서 빨간색으로 바꾸고, 프런트엔드 수정 사항과는 별개로
00:02:04새로운 독립 브랜치를 추가해 보겠습니다. 작업이 끝난 것 같네요. 이전 웹사이트 모습입니다.
00:02:09트위터와 비슷하죠? 변경 사항을 적용하면 보시는 것처럼
00:02:14멋진 빨간색 테마로 바뀌었고 프런트엔드 수정도 완료되었습니다. 보시다시피 이것들은 독립적인
00:02:18브랜치들입니다. 만약 프런트엔드 수정 스택을 적용 해제(unapply)해도
00:02:25여전히 빨간색 테마는 유지됩니다. 제가 한 작업이 이거였죠. 다시 적용할 수도 있고
00:02:34빨간색 테마를 적용 해제하면 다시 원래 색으로 돌아옵니다. 다시 적용해 보죠.
00:02:43이제 두 개의 서로 다른 브랜치가 있습니다. 여기서 멋진 점은 이것을 GitHub에
00:02:48푸시하면 변경 사항들이 서로 분리된 채로 유지되면서도, 동시에 적용되어 있다는 것입니다.
00:02:52Git 브랜치와 같지만, 동시에 여러 브랜치를 작업할 수 있다는 점이 다릅니다.
00:02:57사이드바 작업을 계속 이어가면 여기에 나타납니다. 여기서
00:03:04여러 가지를 할 수 있는데, 파일을 드래그해서 기존 커밋을 수정(amend)할 수도 있고
00:03:10해당 브랜치에 새로운 커밋으로 추가할 수도 있습니다. 이제 병렬로 작동하는 두 브랜치가 생겼습니다.
00:03:14다른 방식도 살펴보죠. 예를 들어
00:03:18빨간색 테마가 프런트엔드 수정 사항에 의존하는 상황이라고 가정해 봅시다.
00:03:24빨간색 테마를 머지하기 전에 프런트엔드 작업을 먼저 머지하거나
00:03:29한꺼번에 머지하고 싶을 때가 있죠. 이 커밋을 취소(uncommit)해 보겠습니다.
00:03:37커밋을 취소하고 스택을 해제합니다. 이제 여기에 새로운 종속 브랜치를 추가하겠습니다.
00:03:42새 브랜치 생성을 누르고 종속 브랜치를 추가합니다. 또는
00:03:47여기서 종속 브랜치 생성을 누르고 기존의 프런트엔드 수정 사항을 스택으로 쌓은 뒤
00:03:51이름을 'sc_red_theme'으로 짓습니다. 이제 브랜치들이 스택으로 쌓인 것을 볼 수 있습니다.
00:03:58그리고 이 변경 사항을 해당 브랜치에 커밋할 수 있습니다. 이렇게 스택 브랜치를 만들면 GitHub에
00:04:06푸시하는 것도 매우 간단합니다. GitHub 연동이 되어 있다면
00:04:11풀 리퀘스트(PR)도 생성할 수 있습니다. 여기서 'red theme'이라는 PR을 생성하면
00:04:16스택 브랜치인 경우 PR 설명의 하단에 자동으로 정보가 삽입됩니다.
00:04:20이 브랜치가 다른 타겟 브랜치에 종속되어 있다는 내용이죠. 따라서
00:04:25모두 한꺼번에 머지하거나, 빨간색 테마 전에 프런트엔드 수정을 먼저 머지해야 합니다.
00:04:30스택 브랜치를 다루는 아주 훌륭한 방법이죠. 이제 이 PR을 보면
00:04:34스택 내의 두 브랜치가 연결되어 있습니다. 하나는 스택의 2부, 다른 하나는 1부로
00:04:39서로 의존 관계에 있습니다. 또 다른 멋진 기능은
00:04:43브랜치에 할당(assigning to branches)하는 기능입니다. 현재 두 개의 레인과 세 개의 브랜치가 있습니다.
00:04:48두 개는 스택이고 하나는 독립적이죠. 수정을 시작하면 제가 원하는 대로
00:04:54코드 덩어리(hunks)를 특정 브랜치에 할당하여 작업을 계속할 수 있습니다.
00:05:00마치 각 레인이 자신만의 독립적인 스테이징 영역을 가진 것과 같습니다.
00:05:05Git에서 'git add'로 변경 사항을 스테이징하는 것과 비슷하지만, 독립적인 스테이징 영역이 여러 개인 셈이죠.
00:05:09한번 해보겠습니다. 관리자 페이지에 새로운 섹션을 추가하는 기능을
00:05:14넣어보겠습니다. 동일한 작업 디렉토리 내에서 스택이 아닌 독립적인
00:05:19새 브랜치에 할당할 것이고, 해당 변경 사항만으로 PR을 열 수도 있습니다.
00:05:24자, 변경 전의 관리자 대시보드입니다. 여기에 최근 가입자 섹션을
00:05:31추가하는 수정을 했습니다. 두 개의 변경 사항이 있는데, 이것을
00:05:37이 레인에 할당하겠습니다. 그 후 추가 수정을 하면, 시스템이 판단할 수 없는 경우
00:05:43할당되지 않음(unassigned)으로 분류되지만, 같은 코드 덩어리 내의 수정이라면
00:05:47자동으로 할당된 레인에 유지됩니다. 관리자 컨트롤러를 수정해 보죠.
00:05:55간단한 주석만 추가해 보겠습니다. 결과를 보시죠.
00:06:00관리자 컨트롤러가 이미 이 레인에 할당되어 있었기 때문에
00:06:05제가 계속 스테이징할 필요가 없습니다. 시스템이 해당 작업의 일부임을 인식하고 할당해 줍니다. 이제 커밋을 만들어 보죠.
00:06:10다시 커밋을 시작합니다. 창을 넓혀서 상세한 메시지를 적을 수도 있고, AI를 사용해
00:06:15커밋 메시지 초안을 생성할 수도 있습니다. 이를 바탕으로 수정하면 되죠.
00:06:19AI가 변경 사항을 분석하여 시작점을 제공해 줍니다. 좋습니다.
00:06:23이제 최근 가입자 관리 페이지 커밋이 생겼습니다. 옆에는 스택 브랜치도
00:06:27그대로 있고요. 역시 독립적으로 푸시하고 PR을 생성할 수 있습니다.
00:06:31그렇게 생성된 PR을 확인해 보면, 이 모든 변경 사항들이
00:06:37제 작업 디렉토리에 동시에 존재함에도 불구하고, 서로 다른
00:06:42브랜치로 완벽히 분리된 것을 볼 수 있습니다. 관리자 관련 작업만
00:06:48따로 볼 수 있고, 관리자 페이지 수정 내용이 별도의 브랜치와 커밋에 담겨 있으며
00:06:55작업 디렉토리의 다른 작업들과 섞이지 않았습니다. 별개의 브랜치로 유지되는 것이죠.
00:06:58이것이 GitButler에서 병렬 브랜치와 스택 브랜치를 사용할 때의 장점입니다.
00:07:02일반적인 Git으로는 꽤 어려웠을 일들을 여기서는 쉽게 할 수 있는데요,
00:07:06몇 가지 보여드리겠습니다. 우선 커밋을 브랜치 간에 이동시킬 수 있습니다.
00:07:11최근 가입자 커밋을 빨간색 테마
00:07:15커밋 쪽으로 옮기고 싶다면, 그냥 드래그 앤 드롭한 뒤 기존 스택을 지우면 됩니다. 이제
00:07:20커밋이 이쪽으로 옮겨졌죠. 커밋들을 합치고(squash) 싶을 때도
00:07:26바로 아래 커밋뿐만 아니라 스택 내의 어떤 커밋으로든 드래그할 수 있습니다.
00:07:30이 관리자 작업을 가져와서 사이드바 수정 커밋에 넣을 수도 있고, 순서를 바꿀 수도 있죠.
00:07:36스택 아래쪽으로 이동시키거나 다른 커밋에 합칠 수도 있습니다. 이제
00:07:41관리자 수정 내용이 사이드바 수정 커밋에 포함되었습니다. 반대로 커밋을 나누는 것도 가능합니다.
00:07:47빈 커밋을 하나 추가한 뒤, 변경 사항들을 그쪽으로 이동시키면 됩니다.
00:07:52이렇게 스택 어디에나 빈 커밋을 추가할 수 있습니다. 커밋 메시지를 먼저 적거나
00:07:58파일을 먼저 옮길 수 있죠. 파일들을 한번 보겠습니다.
00:08:02관리자 컨트롤러와 사이드바 파일이 있네요. 관리자 인덱스 파일을 드래그해서
00:08:08가운데에 있는 빈 커밋으로 옮겨보겠습니다. 이제 이 커밋은 관리자 인덱스만 가지게 되고
00:08:13기존 사이드바 수정 커밋에는 나머지 파일들이 남습니다. 관리자 컨트롤러와 사이드바처럼요.
00:08:20파일 전체가 아니라 특정 코드 덩어리만 옮길 수도 있습니다. 이제 이 커밋은 사이드바 수정의 일부를,
00:08:30저 커밋은 나머지 부분을 가지게 됩니다. 그리고 나중에 원할 때
00:08:34커밋 메시지를 변경하면 됩니다. 또한 커밋 메시지 수정이
00:08:41매우 쉽습니다. 순서를 바꾸거나 합치고 나누는 것 외에도,
00:08:46원하는 곳으로 돌아가 이름을 '2부'로 바꿀 수 있습니다. 그러면 그 위의
00:08:53모든 커밋이 자동으로 재정렬(rebase)됩니다. 커밋을 그 자리에서 바로 수정하는 것도 가능합니다.
00:08:57몇 가지 빠른 방법이 있는데요. 누군가 피드백을 줘서
00:09:01상단 여백을 0이 아니라 10픽셀로 바꿔달라고 했다고 칩시다.
00:09:06그 커밋이 네 단계 이전의 커밋이고 심지어 다른 스택에 있다면 어떻게 수정할까요?
00:09:13GitButler에서는 매우 쉽습니다. 한번 직접 수정해 보죠.
00:09:16여기 있네요. 10픽셀로 바꿔보겠습니다. 인라인 CSS가 최고죠. 제가 방금 수정한
00:09:23내용입니다. 이미 수정된 코드 덩어리를 다시 고치는 중이라 '잠금(locked)' 상태로 표시되는데,
00:09:28따라서 이 브랜치 어딘가에는 포함되어야 합니다. 별도의 병렬 브랜치로 뺄 수는 없다는 뜻이죠.
00:09:32그럼 이걸 어떻게 반영할까요? 가장 쉬운 방법은 이 파일을 잡아서
00:09:39해당 커밋으로 드래그해 넣는 것입니다. 이제 해당 커밋을 확인해 보면
00:09:4610픽셀로 수정된 내용이 반영되어 있고, 나머지 커밋들도 그 위에 자동으로 재배치되었습니다.
00:09:51또 다른 방법은 이미 보셨듯이, 일단 임시 커밋을 만든 다음
00:09:55그것을 대상 커밋에 합치는(squash) 것입니다. 결과적으로는
00:10:02동일한 작업이 수행됩니다. 다시 확인해 보면 여백이 10픽셀로 되어 있죠.
00:10:07마지막으로 흥미로운 방법은 '수정 모드(edit mode)'입니다. 아직 아무것도 안 했다고 가정해 보죠.
00:10:12여전히 0픽셀인 상태에서 이걸 고치고 싶다면, 해당 커밋으로 직접 가서
00:10:20커밋 수정을 누르면 됩니다. 그러면 아주 흥미로운 일이 일어납니다.
00:10:25Git에서 'detached head checkout'을 해보셨다면 그것과 비슷합니다.
00:10:30해당 커밋의 시점으로 체크아웃을 하는 것이죠. 원하는 대로 수정한 뒤 해당 모드를 빠져나오면
00:10:36다시 그 위에 모든 것을 재배치합니다. 다시 내용을 수정해 보겠습니다.
00:10:39파일이 수정된 것을 시스템이 감지했죠. 저장하고 종료합니다. 그러면 다시
00:10:46모든 것이 재정렬됩니다. 확인해 보면 변경 사항이 잘 저장되어 있습니다. 이렇게 커밋을 직접
00:10:52수정하거나, 내용을 바꾸고 커밋을 업데이트(amend)할 수도 있고,
00:10:57수정 후 커밋을 만들어 합칠 수도 있습니다. GitButler에서 커밋을 조작하는
00:11:01다양한 방법들이 있죠. 마지막으로 보여드릴 기능은
00:11:05'작업 히스토리(operations history)'입니다. Git에서 'reflog' 작업을 해보셨다면
00:11:10그게 얼마나 어려운지 아실 겁니다. 다들 reflog를 좀 무서워하죠. 하지만 GitButler에서
00:11:15하는 모든 작업은 로그에 저장되며, 타임라인을 보고 과거의 어느 시점으로든
00:11:21되돌아갈 수 있습니다. 여기 이 버튼을 누르면 이번 세션 동안 수행한
00:11:26모든 작업 내역이 나옵니다. 그리고 시간을 거슬러
00:11:30정확히 어느 지점으로든 돌아갈 수 있습니다. 예를 들어
00:11:37방금 한 10픽셀 수정을 하기 전으로 가고 싶다면, 이 지점으로 돌아가서
00:11:42상태를 확인하면 됩니다. 수정을 하기 전의 원래 상태가 보이죠.
00:11:47심지어 이번 세션을 시작했던 맨 처음으로 돌아갈 수도 있습니다.
00:11:52단, 이미 GitHub에 푸시된 내용은 취소되지 않습니다. 여기 GitHub에 푸시된 커밋들은
00:11:56업스트림 커밋으로 표시되지만, 저는 아무것도 커밋하기 전의 상태로 되돌아가는 중입니다.
00:12:01브랜치를 삭제하고 처음부터 다시 시작할 수도 있죠. 무엇을 하든 상관없습니다.
00:12:05되돌리기(undo) 자체도 다시 되돌릴 수 있으니까요. 여기서 스냅샷을
00:12:11복구(revert)하면 다시 원래대로 돌아옵니다. 우리는 언제든지
00:12:16원하는 시점으로 갈 수 있습니다. 정말 멋지죠. 어떤 작업을 하든 두려워할 필요가 없습니다.
00:12:22상태가 꼬였거나 10분 전 상태가 낫겠다 싶으면, 그냥
00:12:26타임라인을 열고 돌아가서 복구를 누르면 끝입니다. 자, 지금까지
00:12:32GitButler의 리베이저, 커밋 에디터, 병렬 브랜치, 스택 브랜치 기능들을 살펴봤습니다.
00:12:36다른 도구 없이도 이 모든 게 가능합니다. 지금 다운로드해서 사용해 보시고 디스코드에서 의견을 남겨주세요.
00:12:41감사합니다!