본문 바로가기
코딩해보니/Git

[Git_44] 서버(원격) 저장소로 전송(push) 할 때 유의할 점

by 위시랜 2023. 3. 31.

서버(원격) 저장소로 전송(push) 할 때 유의할 점
서버(원격) 저장소로 전송(push) 할 때 유의할 점

서버(원격) 저장소로 전송(push) 할 때 유의할 점

아직 서버(원격) 저장소로부터 내려받는 방법 중 하나인 pull에 대해서 얘기하진 않았지만, 이전 포스팅에서 서버로 전송 시 오류 상황에 대해 얘기했었기에 정리 차원에서 미리 짚어두고자 합니다.

 

 

[Git_43] 로컬 저장소의 커밋을 리셋(reset) 후 전송(push) 하기

로컬 저장소의 커밋을 리셋(reset) 후 전송(push) 하기 - 강제 전송 제목 그대로 로컬 저장소에서 작업하면서 실행했던 커밋을 리셋한 이후에 서버(원격) 저장소로 전송(push)하면 어떻게 될까요? 이

wishlan.tistory.com

pull(내려받기)을 실행하면 서버 저장소의 내용을 로컬 저장소로 내려 받은 후 로컬 저장소의 내용과 병합(merge)이 자동으로 실행됩니다.

push를 실행해 서버로 전송하면, 마찬가지로 원격 저장소는 업로드받은 내용으로 원격 저장소의 내용과 병합(merge)을 실행합니다.

그렇기 때문에 push는 동시에 여러 사람이 실행할 수 없습니다.

push를 실행하기 전에는 자신의 로컬 저장소가 서버 저장소보다 최신의 커밋 정보를 가지고 있어야 합니다.


다음과 같이 서버 저장소와 두개의 로컬 저장소 A, B가 모두 동기화되어 있는 상태에서

여러 사람이 함께 협업하는 상황의 저장소 예시
여러 사람이 함께 협업하는 상황의 저장소 예시

 

“로컬 저장소 A”와 “로컬 저장소 B”는 각자 수정 작업을 진행하고 커밋을 진행해서 다음과 같아졌습니다.

여러 사람이 함께 협업하는 상황의 저장소 예시
여러 사람이 함께 협업하는 상황의 저장소 예시

 

여기서, 로컬 저장소 A와 B가 동시에 push를 진행할 경우 문제가 어느 한쪽에서는 발생하게 됩니다.

 

서버 저장소 입장에서는 순차적으로 받아 처리하게 됩니다.

아무리 동시에 실행했다고 해도 먼저 처리한 쪽은 문제없이 완료되지만,

뒤에 처리하려고 한 push 쪽은 거부당하게 됩니다.

 

만약에 A의 push 요청이 먼저 처리가 되었다고 한다면

A의 push 요청으로 서버 저장소가 갱신되어 B가 알고 있던 서버 저장소의 정보와 달라지게 됩니다.

여러 사람이 함께 협업하는 상황에서 동시에 Push 실행시 발생 가능한 오류 상황 예시
여러 사람이 함께 협업하는 상황에서 동시에 Push 실행시 발생 가능한 오류 상황 예시

 

그래서, B의 push 요청은 다음과 같은 오류를 마주하게 될 것입니다.

실제 발생 가능한 오류 상황
실제 발생 가능한 오류 상황

 

이럴 경우에는 B가 pull(내려받기)을 실행해 서버 저장소의 업데이트 된 사항을 내려받은 다음 push를 실행해야 합니다.

이러한 문제를 최소화하기 위해서는 push를 실행하기 전에 항상 서버 저장소를 먼저 확인하는 것이 좋습니다.

새로운 커밋 정보가 없는지 pull을 실행해서 확인하는 것이 좋습니다.

 

소스트리(Sourcetree)를 사용하면 자신의 저장소와 서버 저장소가 차이가 없는지 쉽게 확인할 수 있습니다.

소스트리로 확인하면, 서버 저장소와 차이가 있으면, 소스트리 상단 메뉴 중에

메뉴에 차이가 나는 커밋 이력 개수만큼의 숫자로 표시를 해주고 있습니다.

 

 

좌측 사이드 메뉴의 master 브랜치 옆에도

와 같이 표시해주고 있습니다.

하지만 소스트리의 이러한 부분도 정확하진 않습니다.

 

갱신할 사항이 없음에도 표시해주고 있는 경우도 종종 있으니

push 전에는 pull을 실행하는 것을 습관화하는 것이 좋습니다.

 

다음엔 서버(원격) 저장소로부터 내려받기에 대해 확인해 보겠습니다.

 

감사합니다.

댓글