00:00:00여러분 안녕하세요. 저는 Git Brother의 CEO, 스콧 채콘입니다.
00:00:02새로운 Git Brother CLI의 데모를 빠르게 진행해 보겠습니다.
00:00:06명령줄 인터페이스(CLI)에 익숙하시거나,
00:00:08Git Brother를 프로그래밍 방식으로 사용하고 싶으시다면,
00:00:11새로운 Git Brother CLI가 아주 유용할 것입니다.
00:00:14그럼 시작해 보죠. 우선 저장소부터 살펴보겠습니다.
00:00:18여기 작은 Rust 프로젝트가 하나 있는데요.
00:00:20Git Brother CLI의 기본적인 워크플로를 따라가 보겠습니다.
00:00:23이 도구는 기본적으로 Git을 대체해 바로 사용할 수 있습니다. 설치하고 나면
00:00:27Git 대신 “but” 명령어를 메인 인터페이스로 사용하게 됩니다.
00:00:32“but”을 입력하거나 “but status”를 실행하면 됩니다. 전자는 후자의 줄임말이죠.
00:00:35그러면 현재 상태가 표시됩니다.
00:00:38Git status의 출력 결과와 매우 유사한 것을 볼 수 있습니다.
00:00:41수정된 파일이 4개 있다는 것을 알 수 있네요.
00:00:44추적되지 않은 파일(untracked)과 변경된 파일이 각각 몇 개씩 있습니다.
00:00:47새 파일과 수정된 파일이 섞여 있지만, “but”의 출력 결과인
00:00:50status는 단순히 변경 사항 4개를 목록으로 보여줍니다. 그렇죠?
00:00:55이것들은 여러분이 수정한 내용입니다. 이제 원하는 방식대로
00:00:59커밋을 할 수 있습니다. 그냥 “but commit”을 실행하면 됩니다.
00:01:02그러면 임시 브랜치가 생성됩니다. 실제로 한번 해보죠.
00:01:05그리고 다시 “but status”를 실행하면 모든 변경 사항이 하나로 묶인 것을 볼 수 있습니다.
00:01:11“but status -f” 또는 “--files” 옵션을 실행할 수도 있습니다.
00:01:15이 커밋에서 수정된 파일들을 보여주는 옵션이죠.
00:01:18하지만 이 모든 변경 사항을 하나의 커밋으로 묶고 싶지 않다고 해봅시다.
00:01:21일부는 Clod 관련이고, 하나는 Readme 파일이며,
00:01:24또 하나는 기능 수정입니다. 사실상 세 개의 별개 작업이죠.
00:01:28그러니 세 개의 커밋으로 나누고 싶습니다. 일단 실행 취소를 해보죠.
00:01:31“uncommit” 명령어를 실행해서 커밋을 되돌릴 수 있습니다.
00:01:36자, 돌아왔습니다. 여전히 임시 브랜치는 남아 있네요.
00:01:40원한다면 삭제할 수도 있지만, 그냥 이걸 다시 활용해 보겠습니다.
00:01:44이름을 바꿀게요. 브랜치명을 “Clod stuff”라고 하겠습니다.
00:01:48이제 새 브랜치가 생겼고, git add처럼 여기에 파일을 스테이징할 수 있습니다.
00:01:53“but stage G0 H0”라고 입력해 보죠.
00:01:58이것들은 파일의 단축 코드입니다.
00:02:01원한다면 전체 경로를 다 입력해도 되지만,
00:02:04작업을 빠르게 할 수 있도록 이렇게 만들었습니다. 이제 확인해 보면
00:02:08파일들이 “Clod stuff” 브랜치에 스테이징되었습니다. 여기서 -o 옵션으로 커밋하면
00:02:12스테이징된 항목만 커밋됩니다. 만약 그냥 “commit”을 실행하면
00:02:15스테이징된 항목과 스테이징되지 않은 항목이 모두 커밋됩니다.
00:02:18브랜치가 더 많아지면 더 잘 이해되실 텐데요, 일단 커밋해 보겠습니다.
00:02:20이제 커밋이 하나 있는 브랜치가 생겼고,
00:02:25스테이징되지 않은 변경 사항이 몇 개 남았습니다.
00:02:28여기서부터 아주 흥미로워집니다. Git과는 다르거든요.
00:02:31예를 들어 이 Readme 파일을
00:02:34커밋하고 푸시해서 풀 리퀘스트(PR)를 올리고 싶다고 해봅시다.
00:02:37지금 제가 “Clod” 브랜치에 있다면 보통의 경우에는
00:02:41현재 브랜치를 스태시(stash)하고, Readme를 추가해서 커밋한 다음,
00:02:44PR을 위해 푸시해야 합니다.
00:02:45하지만 Git Brother에서는 병렬 브랜치(Parallel branches)를 활용할 수 있습니다.
00:02:50“but branch new as read-me”라고 입력하면 보시는 것처럼
00:02:55새로운 브랜치가 생성되고 그 파일을 스테이징할 수 있습니다.
00:03:00그리고 그 파일을 바로 커밋할 수 있죠.
00:03:01변경된 파일들을 확인해 볼까요?
00:03:07Clod 관련 작업 2개가 포함된 커밋이 있고,
00:03:09Readme 변경 사항 1개가 포함된 커밋이 따로 있습니다. 마찬가지로
00:03:11다시 한번 해볼게요. “commit” 명령어를 쓰는데
00:03:17-c 옵션은 생성을 뜻합니다. 이런 식으로 새 브랜치를 만들 수 있죠. 음,
00:03:21실제로 뭘 변경했는지 다시 확인해 볼게요. 깜빡했네요.
00:03:25아, 이 “read” 명령어군요.
00:03:27그러면 마지막으로 커밋되지 않은 항목들이나 현재 남은 모든 변경 사항을 가져와서
00:03:32새 브랜치를 만들고 거기에 커밋할 수 있게 해줍니다.
00:03:35이제 세 개의 브랜치가 생긴 것을 볼 수 있습니다.
00:03:38이들은 모두 서로 독립적입니다.
00:03:39그러면서도 모든 변경 사항은 여전히 작업 디렉터리에 남아 있습니다.
00:03:42작업 디렉터리의 실제 파일을 전혀 건드리지 않았기 때문입니다.
00:03:44우리는 그저 메모리상에서 커밋을 생성하고 있을 뿐입니다.
00:03:46이제 “but push”를 실행하면 무엇을 푸시할지 묻습니다.
00:03:50이 모든 걸 푸시할까요? 각 브랜치에는 푸시되지 않은 커밋이 하나씩 있습니다.
00:03:53아니면 하나만 할까요? Readme만 푸시해 봅시다.
00:03:57지금 당장 준비가 된 건 그것뿐이라고 가정해 보죠.
00:03:59해당 브랜치를 선택하면 푸시가 진행됩니다.
00:04:02다시 상태를 확인해 보면
00:04:03상태 표시를 통해 이 브랜치가 푸시되었음을 알 수 있습니다.
00:04:06나머지 브랜치들은 여전히 로컬에만 있고요.
00:04:08Git Brother는 여러 브랜치를 동시에 다루는 데 매우 강력합니다.
00:04:11또한 스택 브랜치(Stacked branches) 기능도 제공하죠.
00:04:13이미 작업한 커밋 중 하나를 기반으로
00:04:17새로운 작업을 만드는 예를 살펴보겠습니다.
00:04:19기존 커밋 위에 스택 브랜치를 만드는 것이죠.
00:04:20그러면 아래쪽 작업은 머지하고 위쪽 작업은 계속 이어갈 수 있습니다.
00:04:23자, 스택 브랜치를 만들어 보겠습니다.
00:04:26이 “read” 명령어가 리뷰를 거쳐 머지되길 원하지만,
00:04:30그 위에서 작업을 계속 이어가고 싶다고 해보죠.
00:04:32이런 경우 의존성이 있기 때문에 독립 브랜치보다는 스택 브랜치가 적합합니다.
00:04:35방법은 이렇습니다. “but branch new”를 입력하고,
00:04:38앵커 포인트(기준점)를 의미하는 -a 옵션 뒤에 기반이 될 브랜치명을 적습니다.
00:04:42그리고 새 브랜치명을 “SC read more”라고 하죠.
00:04:46이제 결과를 확인해 보면
00:04:48브랜치가 다른 브랜치 위에 쌓여 있는(stacked) 것을 볼 수 있습니다.
00:04:50자, 이제 코드를 수정해 보겠습니다.
00:04:52현재 메시지 10개를 가져와서 보여주고 있네요.
00:04:57이걸 20개로 바꾸고, 관련 내용도 수정하겠습니다.
00:05:02변경 사항을 보면 자물쇠 아이콘이 보이는데, 이미 어딘가에 커밋된
00:05:09파일을 수정하고 있기 때문입니다.
00:05:11그래서 특정 커밋에 잠겨(locked) 있는 것이죠.
00:05:13해당 커밋에서 도입된 코드를 수정하는 것이므로 그 위에만 커밋할 수 있습니다.
00:05:16diff 명령어로 무엇이 변했는지 확인할 수 있는데,
00:05:20어떤 덩어리(hunks)가 수정되었는지 보기 좋습니다. 이제
00:05:25커밋을 완료하겠습니다. 좋습니다.
00:05:28커밋을 옮기는 게 얼마나 쉬운지도 보여드리고 싶은데,
00:05:32한번 보여드리죠.
00:05:33“status -f”로 모든 파일을 확인하겠습니다.
00:05:37이제 공유를 해보죠. 아까 원격 저장소로 보내는 “push”는 보셨죠.
00:05:40하지만 풀 리퀘스트를 바로 생성하는 “PR” 명령어도 있습니다.
00:05:42한번 실행해 보죠.
00:05:46어떤 브랜치들에 대해 PR을 열지 묻습니다.
00:05:48모든 브랜치에 대해 PR을 생성해 보겠습니다.
00:05:50그러면 각 브랜치마다 에디터가 열리면서
00:05:54PR 설명을 입력하라고 합니다. 저는 그냥 간단하게 적을게요.
00:05:57자, 이제 모든 PR이 생성되었습니다. PR을 생성하고 나면
00:06:01상단에 1번, 2번 같은 숫자들이 보이는데,
00:06:04이것들이 PR 번호와 메시지입니다.
00:06:06매번 같은 메시지를 사용하고 있네요.
00:06:08-v(verbose) 옵션을 사용하면
00:06:10각 PR의 상세 URL도 볼 수 있습니다.
00:06:12하나를 직접 확인해 보겠습니다.
00:06:14이것은 Readme를 수정한 PR입니다. 보시는 것처럼
00:06:18커밋 하나와 Readme 파일의 변경 사항만 포함되어 격리되어 있습니다.
00:06:23이번엔 스택 브랜치를 보시죠.
00:06:24이걸 보면 시스템이 어떻게
00:06:28스택을 구성했는지 알 수 있습니다. 첫 번째,
00:06:30즉 하단 PR은 main 브랜치를 대상으로 하고 있고,
00:06:35여기서 이동할 수 있는 두 번째 PR은 첫 번째 PR을 대상으로 하고 있습니다.
00:06:39스택 브랜치가 아주 제대로 구현되어 있죠.
00:06:41이제 무언가를 통합(integrate)하면 어떤 일이 벌어지는지 보겠습니다.
00:06:43이 Readme 풀 리퀘스트로 가서,
00:06:46내용이 좋으니 머지해 보겠습니다. 이제 업스트림에 반영되었습니다.
00:06:49“but pull --check”를 실행하면 상태를 확인합니다.
00:06:55“but fetch”를 실행해도 같은 작업을 수행해 주며,
00:06:57주기적으로 백그라운드에서 fetch를 수행하기도 합니다.
00:07:00명령어를 실행할 때 가끔 보셨을 수도 있는데,
00:07:02백그라운드 작업을 시작했다는 메시지가 뜹니다. 아무튼 이 작업이 통합된 것을 볼 수 있습니다.
00:07:06업스트림에 통합된 것을 확인했으니 “but pull”을 실행하면,
00:07:10새로운 정보를 가져오게 됩니다.
00:07:13그런 다음 다른 브랜치들을 리베이스(rebase)하고, 통합된 브랜치는 정리합니다.
00:07:16로컬에서 해당 브랜치가 제거된 것을 볼 수 있죠.
00:07:19자, 이제 해당 작업은 완료되었고
00:07:22나머지 브랜치들은 최신 상태로 업데이트(리베이스)되었습니다. 원한다면 다시 푸시하면 되죠.
00:07:25그리고 언제든지
00:07:29다시 일반 Git 방식으로 돌아가고 싶다면 “but tear-down”을 실행하면 됩니다.
00:07:33그러면 브랜치 중 하나를 선택하게 되는데,
00:07:36처음에 있던 브랜치를 기본으로 선택해 줄 것입니다.
00:07:39작업하던 모든 브랜치는 여전히 남아 있습니다.
00:07:43다만 일반 Git은 한 번에 하나의 브랜치에만 있을 수 있으니 다시 그렇게 돌아가는 거죠.
00:07:47이렇게 set-up과 tear-down을 사용해 Git Brother 모드를 넘나들 수 있습니다.
00:07:50여러 브랜치를 동시에 작업하거나, 혹은 일반적인 Git 커밋 도구를 쓰고 싶을 때 말이죠.
00:07:55하지만 Git Brother 모드 중에도 대부분의
00:08:00Git 명령어는 그대로 사용할 수 있습니다. “git show”를 써도 똑같이 작동하고,
00:08:04“git log”도 평소처럼 잘 작동합니다.
00:08:08읽기 관련 명령어들은 모두 괜찮습니다. show, log 등등 말이죠.
00:08:13우리가 대신 관리해 드리는 건 주로 커밋 과정입니다.
00:08:16또한 직접 다른 브랜치를 체크아웃(checkout)하면 Git Brother가 이를 감지하고
00:08:21수행 중이던 작업들을 정리합니다. 그러면 다시
00:08:24평소처럼 사용하실 수 있습니다.
00:08:26마지막으로 보여드릴 점은 모든 명령어에
00:08:30--json 옵션이 있다는 것입니다. status 명령어를 --json과 함께 실행하고 싶다면
00:08:34그렇게 할 수 있습니다. 특정 커밋에 대해 show를 실행할 때도 마찬가지고요.
00:08:41거의 모든 명령어에 이 옵션이 있습니다.
00:08:44“but help”를 쳐보시면 아시겠지만, 거의 모든 명령어가
00:08:48--json 혹은 -j 옵션을 지원합니다.
00:08:52이 말은 스크립트로 짜기가 매우 쉽다는 뜻이죠. 흥미롭게도
00:08:56diff 결과도 JSON 형식으로 받을 수 있는데,
00:09:00정말 멋진 기능이라고 생각합니다.
00:09:01지금까지 Git Brother의 소개와 Git 대비 차이점을 살펴보았습니다.
00:09:05다시 말씀드리지만, 어떤 Git 저장소에서든 바로 시작할 수 있습니다.
00:09:08“but set-up”을 실행하고 이 모든 명령어를 사용해 보세요.
00:09:12결과를 JSON으로 뽑을 수도 있고, 여러 브랜치를 관리할 수도 있습니다.
00:09:15스택 브랜치 관리도 가능하고요.
00:09:17GitHub 연동과 PR 관리까지 모두 지원합니다.
00:09:20그냥 설치해서 바로 “but” 명령어를 쓰기만 하면 됩니다. 간단하죠.
00:09:24언제든 Git으로 돌아가고 싶다면,
00:09:26비록 이 환경에서도 대부분의 Git 명령어가 작동하긴 하지만,
00:09:29tear-down을 하거나 브랜치를 체크아웃하면 모든 것이 깔끔하게 정리됩니다.
00:09:33지금 바로 한번 사용해 보세요.
00:09:35[gitbrother.com/cli에서](https://www.google.com/search?q=https://gitbrother.com/cli%EC%97%90%EC%84%9C) 다운로드하여 사용해 보실 수 있습니다.
00:09:39저희 디스코드에 오셔서 의견도 남겨주세요. 감사합니다.