Magit에서 리베이스

발행: (2026년 3월 10일 PM 10:38 GMT+9)
10 분 소요

Source: Hacker News

Rebasing in Magit

당신의 명령 센터: git 로그

I open the log by first invoking Magit (bound to F3) and then pressing lL:

  • l – 로그 관련 명령의 프리픽스.
  • L모든 로컬 브랜치와 추적하는 원격 브랜치의 로그를 표시합니다.

Magit log view – all branches

더 복잡한 로그 명령 탐색

If we pause after the first l, Magit displays unobtrusive hints for every available option:

Magit log options hint

Because the hints are always present, we never have to memorise the exact flags. Below are a few examples of how to build a sophisticated log step‑by‑step.

목표눌러야 할 키Magit이 보여주는 내용
특정 작성자 제한-A저장소 모든 작성자의 퍼지 매칭 목록. 작성자 이름(e.g., kqr)을 입력하고 Enter를 누릅니다.
날짜 범위 제한=u캘린더 보기(또는 직접 날짜를 입력할 수 있음). 예시: 2025‑06‑01.
파일 diffstat 표시-s--stat 플래그를 활성화합니다.
하위 디렉터리 제한-- then tests Enter로그를 tests/ 아래 파일로 제한합니다.
모든 브랜치와 원격 포함b--branches --remote를 추가합니다.
색상, 장식 및 병합 커밋 제외 그래프 보기(기본적으로 이미 활성화됨; 굵게/하이라이트된 플래그로 표시)--graph --color --decorate --no-merges.

Putting the pieces together, the full key sequence (with ␍ = Enter) is:

l -A kqr ␍ =u 2025-06-01 ␍ -s -- tests ␍ b

Even though it looks long, we built it incrementally by consulting the hints. After a few repetitions the sequence becomes second nature—both discoverable and efficient.

동등한 셸 명령

git log --branches --remote --author=kqr --until=2025-06-01 \
        --graph --color --decorate --no-merges --stat -- tests

Magit displays this exact command in its log hints, so we never need to flip back to the man page to verify what is being run.

왜 이것이 중요한가

Some fear that using an interactive interface will erode command‑line skills. Magit is deliberately transparent: every operation shows the underlying Git command, encouraging you to learn the CLI while benefiting from a fast, discoverable UI.

Although this discussion appears in an article about rebasing, the Git log is the foundation for understanding repository history. In Magit the log is interactive, making it an ideal “command centre” for everyday Git work.

Source:

로그에서 리베이스하기

다시 한 번, 우리가 작업하고 있던 뷰는 다음과 같습니다:

Magit rebase view

profiling-of-test-suite 브랜치를 optimise-company-name-generation 위에 리베이스하려고 합니다. 현재 브랜치는 optimise이며(파란색 상자로 강조됨) 다음과 같습니다.

단계

  1. profiling 브랜치 체크아웃
    profiling 브랜치(회색으로 강조된)에 커서를 놓고 다음을 입력합니다

    bb⏎
    • 첫 번째 b = checkout
    • 두 번째 b = branch
    • 퍼지 매칭 리스트는 기본적으로 커서가 있는 브랜치를 제시하므로 Enter 를 눌러 profiling 으로 전환합니다.
    • 파란 상자가 이제 profiling 브랜치로 이동하여 체크아웃이 완료됐음을 확인합니다.
  2. optimise 위로 리베이스
    커서를 다시 optimise 브랜치로 옮기고 다음을 입력합니다

    re⏎
    • r = rebase
    • e = elsewhere (즉, upstream이 아닌 다른 곳)
    • 퍼지 매칭 리스트는 다시 커서가 있는 커밋을 기본값으로 제시하므로 Enter 로 확인합니다.

    팁: 확신이 서지 않을 때는 첫 글자만 입력하면 Magit이 힌트를 보여줍니다.
    -i 를 추가하면 (예: re -i⏎) 인터랙티브 리베이스가 시작됩니다.

  3. 결과
    로그가 업데이트되어 profiling 브랜치가 이제 optimise 위에 놓인 것을 확인할 수 있습니다.

인터랙티브 리베이스 (선택 사항)

보다 복잡한 리베이스가 필요하면 인터랙티브 리베이스를 시작합니다 (re -i⏎). Magit은 편집 가능한 커밋 목록과 유용한 단축키를 제공합니다:

동작
k커밋 버리기
fFixup (커밋 메시지를 유지하지 않고 스쿼시)
w커밋 메시지 재작성
sSquash (이전 커밋과 합치기)
… (커밋 목록 아래에 있는 전체 지원 작업 목록을 참고)

리베이스 중에 새 커밋을 만들거나 머지 커밋을 만들 수도 있지만, 이런 경우는 드뭅니다.

방금 뭐가 일어났나요?

Magit이 실행한 명령을 알고 싶다면 $ 키를 눌러 Magit command log를 확인할 수 있습니다. 여기서 Magit은 실행한 모든 Git 명령을 나열합니다. 이번 경우에는 다음과 같이 표시됩니다:

git checkout profiling-of-test-suite
git rebase --autostash optimise-company-name-generation

… 뭐지, --autostash가 뭘까, 그리고 왜 Magit이 기본값으로 쓰는 걸까? man git-rebase에서 찾아보겠습니다:

--autostash

작업이 시작되기 전에 임시 스태시 항목을 자동으로 만들고, 작업이 끝난 후에 이를 적용합니다. 이는 더러운 작업 트리에서도 rebase를 실행할 수 있음을 의미합니다. 다만 주의해서 사용하세요: 성공적인 rebase 후 최종 스태시 적용 과정에서 충돌이 발생할 수 있습니다.

음, 기본값으로 쓰기에 충분히 이해가 됩니다. 저는 더러운 작업 트리 상태에서 자주 rebase를 수행하는데, 수동으로 스태시를 만들 필요가 없어서 편합니다.

이것은 Magit이 Git을 더 잘 사용할 수 있도록 가르쳐 주는 또 다른 방법입니다. Magit이 기본값으로 --autostash를 사용하지 않았다면 저는 이 옵션을 알지 못했을 것입니다. 또한 --force-with-lease--force보다 확실히 더 나은 옵션이라는 사실도 알게 되었는데, 이를 아는 사람은 많지 않죠.

Other Git Interfaces {#other-git-interfaces}

이 작업은 복잡하지 않았습니다. Git 명령줄을 통해 수행할 수도 있었고, 그 경우는 아주 간단했을 것입니다—실제로 우리는 Magit이 내부에서 실행한 두 개의 명령을 방금 확인했습니다. 하지만 인터랙티브한 Magit 로그 뷰를 통해 리베이스를 수행함으로써, 명령이 실제로 무엇을 하는지에 대한 직관을 훨씬 더 잘 얻을 수 있습니다. Magit에 익숙해지면, 명확하고 인터랙티브한 프레젠테이션을 제공하는 Magit 없이는 자신 있게 실행하기 어려운 더 복잡한 명령들을 실행하게 될 것입니다.

물론 다른 그래픽 Git 인터페이스도 존재하며, 이들 중 어느 것이든 같은 리베이스를 수행할 수 있었습니다. 하지만 Magit을 사용하면서 얻은 Git에 대한 이해만큼은 얻지 못했을 것입니다.

Magit은 해결책 공간에서 완벽한 지점에 자리합니다: 본질적으로 Git 명령줄의 얇은 래퍼이며, 이를 부끄러워하지도 않습니다. 동시에 명령줄에 인터랙티브함, 탐색성, 그리고 다른 곳에서는 찾기 힘든 효율성을 더합니다.

우리는 여기서 그 힘의 일부분만 살펴보았습니다—Magit이 파일, 청크, 심지어 청크의 일부까지도 인터랙티브하게 스테이징, 언스테이징, 되돌리기, 리셋을 얼마나 쉽게 할 수 있는지 직접 경험해 보세요.

0 조회
Back to Blog

관련 글

더 보기 »

모든 마찰이 같은 것은 아니다

소개 요즘 많은 게시물들이 “마찰의 종말”을 축하하며, AI가 코드를 작성하는 데 따르는 마찰을 없애고 개발 속도를 높이는 것을 칭송하고 있다...