비개발자도 Git을 쓰는 AI 시대
Git을 쓰다 보면 어느 순간부터 이런 상황을 겪는다.
기능 개발을 위해 브랜치를 따서 작업을 하고 있었는데,
다른 사람이 버그를 먼저 고쳐서 메인(main)에 반영했다.
그리고 내 작업을 합치려는 순간, 갑자기 충돌이 난다.
처음에는 이렇게 생각한다.
“버그 수정된 게 덮어써진 건가?”
“내 작업이 날아간 건가?”
결론부터 말하면 그렇지 않다.
덮어써진 것이 아니라, ‘합칠 수 없어서 멈춘 상태’다.
이 상황을 이해하려면 브랜치를 이렇게 보면 된다.
브랜치는 단순히 작업 공간이 아니라
“특정 시점의 복사본”이다.
예를 들어보자.
main (기준)
├─ A (기능 개발)
└─ B (버그 수정)
A와 B는 같은 main에서 출발했지만,
각자 다른 방향으로 발전한다.
흐름을 시간 순서대로 보면 이렇다.
A 브랜치에서 기능 개발 진행
B 브랜치에서 버그 수정
B → main 머지 (버그 반영 완료)
여기까지는 아무 문제없다.
문제는 그다음이다.
A는 여전히 버그 수정 이전 상태를 기준으로 작업 중인 것이다.
여기서 두 가지 경우로 나뉜다.
B: 결제 로직 수정
A: UI 디자인 변경
영향이 없다.
결과:
UI 변경 유지
버그 수정도 유지
아무 문제 없이 머지된다.
B: 로그인 오류 수정
A: 로그인 기능 개선 작업
> 같은 코드를 건드렸다
이때 Git은 판단을 못 한다.
그래서 이렇게 말한다.
=> “둘 중 뭐가 맞는지 모르겠다. 네가 정해라”
이게 바로 충돌이다.
이 상황에서 가장 많이 하는 오해가 있다.
“버그 수정이 덮어써진 것 같다”
하지만 실제로는 다르다.
코드가 사라진 게 아니다
Git이 자동으로 선택하지 않았을 뿐이다
즉, 결정되지 않은 상태로 멈춰 있는 것이다.
이건 실제로 많이 겪는 상황이다.
A: 신규 기능 개발 (며칠 걸림)
B: 긴급 버그 수정 (당일 반영)
B가 먼저 main에 반영된다
그리고 A를 나중에 머지하려고 하면 충돌이 발생한다.
이때 내 작업이 꼬였다고 생각할 수 있지만
사실은 시간선이 달라졌을 뿐이다.
핵심은 하나다.
내 브랜치를 최신 main 기준으로 맞춘다.
즉, A를 현재 상태로 끌어오는 것이다.
방법은 두 가지다.
git checkout A
git merge main
main의 변경사항을 A에 합친다.
git checkout A
git rebase main
A 작업을 최신 main 위로 다시 쌓는다
이걸 안 하면 생기는 문제는 명확하다.
마지막에 충돌이 한 번에 몰린다
어디서 꼬였는지 찾기 어렵다
버그가 다시 살아난 것처럼 보인다
반대로 미리 맞추면
충돌을 작은 단위로 해결 가능
작업 흐름이 끊기지 않는다
안정적으로 머지 가능
이건 팀이 있든 혼자 하든 동일하다.
작업 중간에 한 번씩 main을 당겨오는 것이다.
예를 들어
하루에 한 번
머지 전에 한 번
이 정도만 해도 충분하다.
브랜치는 이렇게 보면 쉽다.
“각자 다른 시간에서 작업하는 것”
B는 미래로 갔다 (버그 수정 반영됨)
A는 과거에 머물러 있다
그래서 해야 할 일은 A를 현재로 끌어와
맞추는 것이다.
브랜치를 나눠서 작업할 때 중요한 건 흐름을 이해하는 것이다.
브랜치는 같은 시점에서 출발한다
main은 계속 변한다
내 브랜치는 과거에 머물 수 있다
그래서 항상 기준을 맞춰야 한다.
이 개념을 이해하면 Git이 훨씬 덜 무서워진다.
그리고 협업이 훨씬 덜 피곤해진다.
작업이 꼬이는 이유는 대부분 복잡한 기술 때문이라기보다는
단순히 “시간선이 어긋났기 때문”이라고 보면 된다.
브랜치와 충돌을 이해하면
Git이 왜 필요한지는 어느 정도 감이 잡힌다.
하지만 실무에서는 여기서 한 단계 더 나아간다.
결국 중요한 건 변경을 어떻게 쪼개고 기록할 것인가 이다.
그 기준이 바로 커밋 규칙이다.
이 부분은 따로 정리해 두었으니,
실제로 Git을 업무에 쓰기 시작했다면
함께 보는 것을 추천한다.
- 커밋 규칙 : https://brunch.co.kr/@144ce42dff304dd/56
- Git 기초, 용어 : https://tamisandbox.tistory.com/16