01
빨리 감기부터 확인
main이 feature의 조상이라면 merge는 기존 끝으로 main만 옮깁니다. 분기된 예제와 달리 새 병합 커밋을 만들지 않습니다.
Git & Version Control
Git 시뮬레이터명령 전에 커밋 흐름 확인
예제와 작업을 고르면 실행 없이 히스토리의 변화를 미리 볼 수 있습니다.
Git 시뮬레이터
예제 커밋 그래프
A–D와 프라임 기호는 학습용 ID이며 실제 Git 해시가 아닙니다.
히스토리 미리 보기
예제와 작업을 골라 미리 보면 여기에 결과가 나옵니다.
고정 학습 그래프만 브라우저에서 처리하며 실제 저장소를 읽거나 연결하지 않습니다.
옵션
대상 브랜치: main · 출처 브랜치: feature
Ctrl/Cmd + Enter로 선택한 작업을 미리 봅니다.
작업을 골라 미리 보세요.
이 그래프는 고정된 한 줄 파일만 모델링하며 실제 Git 병합 전략을 재현하지 않습니다.
Git 시뮬레이터는 공통 커밋에서 갈라진 main과 feature를 출발점으로 삼습니다. 커밋 그래프에서 부모 관계와 브랜치 끝을 보면 merge와 rebase가 남기는 기록이 왜 다른지 쉽게 알 수 있습니다.
빨리 감기 예제와 같은 줄 충돌 예제를 바꿔 볼 수 있습니다. A부터 D까지는 학습용 기호이며 실제 저장소의 해시가 아닙니다. 초안은 자신의 브랜치와 작업 트리에 맞춰 검토해야 합니다.
Git 시뮬레이터가 필요한 이유
같은 시작점에서 다른 결과 비교
Git 시뮬레이터는 머지 후 두 부모를 가진 노드와 리베이스 후 복사된 C′·D′를 구분합니다. Git 실습장에서 명령만 외우는 대신 어떤 포인터가 움직이는지 살필 수 있습니다.
충돌 설명에 예제 파일을 연결
같은 줄 충돌 예제는 app.js의 기준값과 양쪽 변경값을 함께 보여 줍니다. 체리픽이나 머지 충돌을 설명하지만 실제 저장소의 충돌 가능성을 계산하지는 않습니다.
결과를 읽는 세 가지 단서
02
복사한 커밋 수 확인
rebase는 C와 D를 순서대로 C′, D′로 다시 기록합니다. cherry-pick은 선택한 한 커밋만 main에 복사하고 원래 feature는 유지합니다.
03
변경 후 다시 미리 보기
예제나 작업을 바꾸면 기존 결과가 즉시 오래된 상태가 되어 복사와 다운로드가 잠깁니다. Ctrl/Cmd + Enter로 갱신한 뒤 명령 초안의 가상 이름을 실제 참조와 대조하세요.
브랜치 포인터와 새 노드
merge의 두 경로
분기된 경우에는 두 부모를 가진 노드가 생기고 빨리 감기에서는 포인터만 이동합니다. 두 결과 모두 원래 커밋을 다시 작성하지 않습니다.
rebase와 cherry-pick의 범위
리베이스는 feature의 연속된 커밋을 새 기반에 복사하지만 체리픽은 선택한 하나만 옮깁니다. 프라임 기호는 실제 SHA가 아니라 새 객체를 나타냅니다.
고정 파일로만 충돌 표시
같은 줄 예제에서는 기준, 현재, 들어오는 값을 보여 줍니다. 실제 Git의 줄 단위 병합이나 이름 변경 검출은 구현하지 않으며 충돌 파일을 자동 수정하지 않습니다.
학습용 그래프의 한계
- 실제 저장소와 연결하지 않음
- Git 시뮬레이터는 git log, 로컬 폴더, 원격 URL을 읽지 않고 명령도 실행하지 않습니다. 미커밋 변경, 권한, 원격 정책을 검사할 수 없습니다.
- 협업 브랜치 안전성은 판단하지 않음
- 공유한 커밋을 rebase로 다시 쓰면 다른 사람의 기록과 충돌할 수 있습니다. 예제의 main과 feature가 실제 참조인지 확인하고 팀 규칙을 따르세요.
- 충돌은 한 줄 스냅샷에 한정
- 내장 app.js 예제의 양쪽 값이 달라 멈춘다는 것만 보여 줍니다. 실제 충돌 해결, --continue, 세부 병합 전략은 제공하지 않습니다.
- 자유 명령과 원격 작업은 제외
- push/pull, stash, squash, revert, 임의 명령 입력은 지원하지 않습니다. 커밋 그래프만으로 실제 Git의 모든 상태를 재현할 수 없기 때문입니다.
Git 시뮬레이터 자주 묻는 질문
Merge commit, Squash and merge, Rebase and merge는 언제 선택하나요?
merge는 분기 기록을 보존하고 rebase는 feature 커밋을 새 기반에 다시 씁니다. squash는 여러 변경을 한 커밋으로 합치지만 이 페이지는 시뮬레이션하지 않습니다. 팀의 기록 정책을 먼저 확인하세요.
rebase와 merge는 충돌 가능성이 똑같나요?
둘 다 파일 내용에 따라 충돌할 수 있습니다. rebase는 커밋을 순서대로 다시 적용하므로 중간 단계에서 멈출 수도 있습니다. 여기서는 고정된 한 줄 예제만 확인합니다.
master의 최신 커밋만 merge해도 중간 변경사항이 모두 반영되나요?
브랜치의 최신 커밋은 조상 커밋의 기록을 따라가므로 보통 그 히스토리도 병합 대상에 포함됩니다. 빨리 감기 예제에서는 main 포인터가 feature 끝으로 이동하는 모습을 볼 수 있습니다.
충돌과 병합을 혼자 어떻게 연습하면 좋을까요?
같은 줄 충돌 예제를 고르고 merge와 rebase를 각각 미리 보세요. 기준값과 양쪽 값을 비교하면 어디서 멈추는지 이해할 수 있습니다. 실제 해결 연습은 별도 테스트 저장소에서 하세요.
cherry-pick이나 squash merge를 하면 커밋 기록은 어떻게 남나요?
cherry-pick은 선택한 한 커밋의 변경을 새 부모 위에 복사하고 원본도 남깁니다. squash merge는 여러 변경을 한 커밋으로 모으지만 이 도구 범위 밖입니다.
기기 설명서와 다른 미리보기인가요?