집PC·사무실PC·서버를 오가며 작업할 때, 왜 “커밋·푸시는 오직 서버에서만”이어야 하는가
새솔CRM은 집PC, 사무실PC, 그리고 실제 서버, 이렇게 여러 장소를 오가며 작업합니다. 그러다 보니 “지금 이 코드가 어디에 있는 진짜 상태인가”를 헷갈리기 쉽습니다. 최근 클로드 코드와 이 문제를 놓고 세 번을 연달아 물어보며 정리한 내용을, 다른 분들도 헷갈릴 만한 부분이라 생각해서 정리해봅니다.
결론부터 말씀드리면, 헷갈림의 원인은 “로컬에서 코드를 고치는 것” · “서버에 실제로 배포하는 것” · “GitHub에 기록을 남기는 것(커밋·푸시)”이 서로 완전히 다른 세 가지 작업이라는 걸 하나로 뭉뚱그려 생각했기 때문이었습니다.
1. 세 가지는 서로 다른 작업이다
먼저 이 세 가지가 왜 별개인지부터 짚고 갑니다.
로컬 편집 · 서버 배포 · GitHub 기록은 각각 따로 움직이는 세 개의 축
예를 들어 코드를 고쳐서 서버에 배포까지 했어도, GitHub에 커밋·푸시를 안 했다면 “서버는 최신인데 GitHub 기록은 옛날 상태”인 상황이 생깁니다. 반대로 로컬에서 커밋만 하고 서버 배포도, GitHub 푸시도 안 했다면 “내 컴퓨터에만 있는 유령 커밋”이 생기는 거고요. 이걸 별개로 인식하지 않으면 “분명 저장했는데 왜 다른 컴퓨터엔 없지?” 같은 혼란이 생깁니다.
2. git reset –hard는 “검토 후 병합”이 아니라 “무조건 덮어쓰기”
처음 헷갈렸던 부분이 이거였습니다. git fetch origin && git reset --hard origin/main을 실행하면, git이 알아서 “차이점을 검토하고 안전하게 이어붙이는(fast-forward)” 것처럼 느껴지실 수 있는데, 사실은 다릅니다.
reset –hard의 실제 동작
“지금 로컬에 뭐가 있든 상관없이, GitHub에 있는 최신 상태로 무조건 맞춰라”는 명령입니다. 검토·비교 없이 그냥 덮어씁니다.
다만 우리 워크플로우(로컬에서는 절대 커밋하지 않고, 오직 서버에서만 커밋·푸시)에서는 로컬에 애초에 “버려질 만한 내용”이 없기 때문에, 결과적으로 항상 안전하게 최신 상태를 그대로 따라잡는 것처럼(fast-forward처럼) 동작하는 것뿐입니다. 이건 reset –hard 자체가 안전해서가 아니라, 우리가 로컬에 커밋을 안 남기는 규칙을 지키고 있어서 안전한 겁니다.
3. 진짜 위험은 “로컬 커밋 O, 푸시 X” 상태일 때만 생긴다
여기서 두 가지 시나리오를 비교하면 헷갈림이 확실히 풀립니다.
위: 커밋+푸시까지 마치면 어디서 동기화하든 안전 / 아래: 커밋만 하고 푸시를 안 하면 이력이 갈라지고, 다음 강제 동기화 때 조용히 유실
✅
안전한 경우 — 사무실PC에서 커밋 후 push까지 마쳤다면, 사무실PC의 로컬 main과 GitHub의 main은 완전히 같은 커밋입니다. 이 상태에서는 집PC든 어디든 fetch && reset --hard를 해도 그냥 최신 상태를 받아오는 것뿐, 잃을 게 없습니다.
⚠️
위험한 경우 — 사무실PC에서 커밋만 하고 push를 안 한 상태로 두었는데, 그 사이 서버 쪽에서 같은 내용을(또는 다른 내용을) 별도로 커밋·푸시해버리면, GitHub의 이력과 사무실PC의 로컬 이력이 서로 다른 갈래로 갈라집니다(diverge). 이 상태에서 사무실PC가 다음번에 습관대로 reset --hard origin/main을 실행하면, 사무실PC에만 있던 커밋은 아무 경고 없이 버려집니다.
4. “버려진다”고 해서 코드 내용까지 사라지는 건 아니다
여기서 한 가지를 더 정확히 짚고 넘어가야 합니다. 시나리오 B에서 사무실PC의 커밋이 “버려진다”는 말을 들으면, 마치 그날 작업한 코드 자체가 통째로 날아가는 것처럼 느껴지실 수 있는데, 실제로는 그렇지 않습니다. 사무실PC에서 만든 로컬 커밋의 내용이 서버로 정확히 배포되고, 서버에서 그걸 그대로 커밋·푸시했다면 — 서버·GitHub·(원래) 로컬 세 곳의 내용은 결국 같아집니다. 이 상태라면 사무실PC든 집PC든 나중에 reset --hard origin/main을 해도, 결과적으로 같은 코드 내용을 GitHub 경로로 다시 받는 것뿐이라 실질적인 손실은 없습니다.
배포가 정확했다면 잃는 건 커밋의 “이력 메타데이터”뿐, 코드 내용은 GitHub에 그대로 남는다
그럼 진짜로 걱정해야 할 손실은 언제 생길까요? 정확히 다음 두 가지 경우뿐입니다.
① 배포가 불완전했을 때
로컬에서 파일 5개를 고쳤는데 서버엔 3개만 옮겼거나, 옮기다가 일부 내용이 빠졌다면 — 그 차이분은 서버 커밋에도 안 담기고, GitHub 어디에도 없고, 로컬 커밋마저 나중에 지워지므로 그 차이분만큼은 영구 소실됩니다.
② 커밋 이후 추가로 손댄 게 있었을 때
로컬 커밋을 만든 시점 “이후”에 뭔가 더 고쳤는데, 그건 서버 배포도 커밋도 안 됐다면 — 그 추가분도 같이 조용히 사라집니다.
✅
배포가 정확했고 커밋 이후 추가 미반영 변경도 없었다면, 시나리오 B도 실질적으로는 “같은 코드 내용을 두 개의 다른 커밋 해시로 두 번 기록한 것”뿐입니다. 코드를 잃는 게 아니라, 이력의 흔적만 정리되는 것에 가깝습니다.
5. 그래서 “커밋·푸시는 오직 서버에서만”이라는 원칙이 필요하다
여기서 자연스럽게 결론이 나옵니다. 로컬 편집 / 서버 배포 / GitHub 기록, 이 세 가지 중 “GitHub에 기록을 남기는 지점”만큼은 반드시 한 군데(서버)로 고정해야 한다는 것입니다.
집PC·사무실PC는 편집만 하고, 서버가 배포와 커밋·푸시를 전담 — GitHub 이력이 하나의 선형 흐름으로만 진행
이렇게 “커밋하는 장소”를 하나로 고정해두면, GitHub의 이력은 항상 하나의 선형(linear) 흐름으로만 진행됩니다. 여러 컴퓨터가 각자 커밋을 만들면서 생기는 분기(diverge)·충돌·유실 위험이 애초에 발생할 수 없는 구조가 되는 것입니다.
반대로 “어떤 날은 서버에서, 어떤 날은 로컬에서” 커밋·푸시를 오가면, GitHub 이력이 여러 갈래로 갈라지기 시작하고, 그때부터는 어느 커밋이 진짜 최신인지, 무엇을 지켜야 하는지 사람이 매번 판단해야 하는 복잡한 상황이 됩니다.
6. 원칙을 지키면 왜 항상 안전한가
정리하면, 우리 워크플로우에서 로컬 PC(집·사무실)의 역할은 딱 하나, “편집 후 서버로 전달”까지입니다. 커밋이라는 행위 자체를 로컬에서 하지 않기 때문에, 로컬에는 애초에 “지켜야 할 커밋”이 존재하지 않습니다.
그래서 어느 PC에서든 작업을 시작하기 전에 git fetch origin && git reset --hard origin/main을 실행하는 게 항상 안전합니다 — 버릴 게 없는 상태에서 최신 상태를 받아오는 것뿐이니까요. 이 원칙이 깨지는 유일한 순간은 로컬에서 실수로(또는 급해서) 커밋을 만들고 푸시를 건너뛰는 순간이며, 그 순간부터는 다음 강제 동기화가 그 커밋을 조용히 삼켜버릴 수 있습니다.
자주 묻는 질문
Q. reset –hard는 항상 위험한 명령인가요?
A. 명령 자체는 “무조건 덮어쓰기”라 로컬에 지킬 내용이 있다면 위험할 수 있지만, 로컬에 커밋을 남기지 않는 워크플로우에서는 지킬 게 없으므로 안전합니다. 위험 여부는 명령 자체가 아니라 “그 순간 로컬에 origin에 없는 내용이 있는가”에 달려 있습니다.
Q. 로컬에서 커밋만 하고 아직 push를 안 했다면 지금 당장 위험한가요?
A. 그 자체로는 아직 안전합니다. 위험은 그 상태에서 “다른 곳(서버 등)이 origin에 별도로 커밋·푸시를 해서 두 이력이 갈라진 다음” 그 로컬 PC에서 reset –hard를 실행하는 순간 발생합니다. 가장 간단한 예방책은 커밋했다면 바로 push까지 마치는 것입니다.
Q. 커밋·푸시 장소를 왜 굳이 서버 하나로만 고정하나요?
A. 서버에서 커밋하기 전에는 실제 배포·스모크테스트 등 검증 절차를 거치기 때문에, “검증된 코드만 GitHub 이력에 남는다”는 보장도 함께 얻을 수 있습니다. 또한 커밋 지점이 하나로 고정되면 GitHub 이력이 항상 하나의 선형 흐름을 유지해, 여러 PC가 각자 커밋할 때 생기는 분기·충돌·유실 위험이 원천적으로 사라집니다.