순서

원격 저장소에는 다수의 개발자가 동시에 커밋을 푸시할 수 없습니다. 여러 명이 협력해서 개발할 때는 순차적으로 푸시해야 합니다.

최신 상태

먼저 원격 저장소에 푸시하려면 자신의 로컬 저장소를 최신 상태로 유지해야 합니다. 즉, 자신의 저장소가 원격 저장소의 커밋보다 최신이어야 한다는 의미입니다. 최신이라는 의미를 좀 더 구체적으로 알아봅시다.

누군가 내 저장소보다 먼저 커밋하여 새로운 커밋으로 서버를 갱신했습니다. 하지만 나는 간발의 차이로 갱신된 서버 정보를 가지고 있지 않습니다. 푸시는 서버의 마지막 커밋과 푸시되는 커밋을 병합합니다. 이때 내 커밋은 서버의 최신 커밋보다 늦은 커밋으로 밀리게 됩니다. 커밋이 순차적이지 않을 때 깃은 푸시 동작을 거부합니다.

푸시 동작이 거부되면 풀 또는 페치 작업으로 자신의 로컬 저장소를 갱신해 주어야 합니다. 갱신 후에 다시 푸시합니다.

예를 들어 보겠습니다. 개발자 1, 개발자 2가 함께 코드를 개발합니다. 개발자 1이 코드를 수정했고, 개발자 2도 동시에 코드를 수정했습니다. 그리고 개발자 1이 코드를 푸시하여 원격 저장소를 갱신했습니다. 이후 개발자 2가 자신의 코드를 푸시하면 오류가 발생합니다. 개발자 1이 원격 저장소를 먼저 갱신하여 커밋 + 1 상태가 되었기 때문입니다. 따라서 개발자 2의 로컬 컴퓨터는 개발자 1이 갱신한 상태로 자신의 저장소를 pull 명령어로 업데이트한 후 푸시할 수 있습니다.

충돌 방지

깃이 최신 상태에서만 푸시를 허용하는 것은 충돌을 방지하기 위해서입니다. 원격 저장소의 커밋을 내려받는 풀 작업은 내려받은 커밋들을 현재 브랜치로 자동 병합합니다. 이때 커밋 내용이 순차적이지 않으면 병합 과정에서 충돌이 발생합니다.

개발자 1과 개발자 2가 서로 다른 작업을 했다면 충돌이 없을 수도 있지만, 같은 영역을 동시에 수정했다면 개발자 2가 풀 작업을 할 때 무조건 충돌이 발생합니다. 개발자 2는 충돌을 해결한 후 커밋하고 푸시해야 하는데, 이를 해결하기가 어렵습니다. 따라서 깃은 이를 더 쉽게 해결할 수 있도록 푸시할 때 커밋의 순차적 기록을 확인합니다.

push 명령어를 사용할 때는 충돌을 최소화하기 위해 미리 원격 저장소를 확인합니다. 새로운 커밋 갱신이 없는지 pull 명령어를 사용하여 지속적으로 확인하는 것이 좋습니다.

최대한 충돌을 피할 수 있는 방법은 자신의 저장소와 원격 저장소의 상태를 자주 최신으로 유지하는 것입니다.

그림 5-10] 권장 순서

풀과 푸시를 자주 하여 충돌을 최소한으로 줄여 나가면서 작업을 유지합시다.

소스트리를 사용하면 푸시하기 전에 자신의 저장소와 어떤 차이점이 있는지 쉽게 확인할 수 있습니다. 소스트리의 push 5-a.jpg 위에 조그마한 숫자가 표시됩니다. 숫자는 현재 로컬 저장소와 원격 저장소 간 커밋 차이점을 출력합니다.

Note: 인증 정보 캐시
원격 저장소로 깃허브, 비트버킷 같은 호스팅 원격 저장소를 이용할 때는 아이디와 비밀번호가 있어야 접속할 수 있습니다. 매번 아이디와 비밀번호를 입력하는 것은 귀찮습니다. 그래서 깃은 인증 정보 캐시(credential cache) 기능을 이용하여 아이디와 비밀번호를 임시적으로 보관할 수 있습니다. 이 기능을 활성화하려면 다음과 같이 환경 설정이 필요합니다.

$ git config --global credential.helper cache

Note: 원격 저장소 원리
깃을 원격 저장소에 연결하면 ./git/config 파일 안에 리모트 연결에 대한 설정 정보가 자동으로 추가됩니다.

[remote "origin"]
        url = https://github.com/jinygit/gitstudy05.git
        fetch = +refs/heads/*:refs/remotes/origin/*