원격 저장소에 변경 사항을 푸시 할 때이 Git 경고 메시지는 무엇입니까?

원격 저장소에 변경 사항을 푸시 할 때이 Git 경고 메시지는 무엇입니까?

---

설명은 약간 간결합니다. 내 로컬 마스터 브랜치에 파일을 추가하고 원격 저장소로 다시 푸시했습니다. 이것이 왜 나오는지 아십니까?

경고 : 현재 분기 업데이트
경고 : 현재 체크 아웃 된 분기를 업데이트하면 혼동이 발생할 수 있습니다.
경고 : 인덱스와 작업 트리는 HEAD에있는 변경 사항을 반영하지 않습니다.
경고 : 결과적으로 방금 푸시 한 변경 사항을 볼 수 있습니다.
경고 : 거기에서 'git diff'를 실행하면 되 돌리며 원할 수 있습니다.
경고 : 복구 작업을 시작하기 전에 'git reset --hard'를 실행합니다.
경고: 
경고 : 'receive.denyCurrentBranch'구성 변수를 다음과 같이 설정할 수 있습니다.
경고 : 원격 저장소의 '거부'로 푸시를 금지합니다.
경고 : 현재 분기.
경고 : 현재 분기로 푸시를 허용하려면 '무시'로 설정할 수 있습니다.
경고 :하지만 작업을 업데이트하지 않는 한 권장되지 않습니다.
경고 : 다른 방식으로 푸시 한 것과 일치하는 트리.
경고: 
경고 :이 메시지를 없애려면 '경고'로 설정할 수 있습니다.
경고: 
경고 : 기본값은 git의 향후 버전에서 변경됩니다.
경고 : 현재 분기 업데이트를 거부하려면
경고 : 구성 변수가 '무시'또는 '경고'로 설정되었습니다.   

---

실제로, 그것은 당신이 밀고있는 저장소에서 누군가가 작업하고 있고, 당신이 밀고있는 것과 똑같은 브랜치를 현재 누군가가 체크 아웃했다는 것입니다.

이것은 매우 혼란 스럽습니다. 왜냐하면 그는 그가 최신 버전의 브랜치를 체크 아웃했다고 생각하기 때문입니다. 사실 여러분은 브랜치를 최신 버전으로 업데이트했습니다. 따라서 그가 이제를 실행 git commit하면 그의 커밋은 기본적으로 방금 푸시 한 모든 커밋을 되돌립니다. 그리고 그가 달릴 때 그는 git diff비록 그가 아무것도 변경하지 않았더라도 당신이 방금 밀었던 모든 것과 반대되는 것을 보게 될 것입니다.

따라서 일반적으로 베어가 아닌 저장소로 푸시하는 것은 나쁜 습관으로 간주됩니다. 베어 리포지토리, 즉 첨부 된 작업 복사본이없는 리포지토리에만 푸시해야합니다. 최소한 현재 체크 아웃 된 브랜치로 푸시하지 않도록해야하지만 일반적으로 다른 사람의 리포지토리로 코드를 밀어 넣는 것이 아니라 대신 사용자에게서 가져 오도록 요청해야합니다.

Git 리포지토리에서 웹 사이트를 제공하고이를 푸시하여 웹 사이트를 업데이트하려는 경우와 같은 일부 특수한 경우에는 실제로 현재 체크 아웃 된 브랜치로 푸시하는 것이 합리적이지만이 경우 반드시 확인해야합니다. 체크 아웃 된 작업 복사본 을 실제로 업데이트 하는 후크가 설치되어 있는지 확인 합니다 . 그렇지 않으면 웹 사이트가 업데이트되지 않습니다.

---

Git 2.3.0 사용 (2015 년 2 월 이후)

원격이 아닌 베어 리포지토리에서 아무도 작업하지 않으면 체크 아웃 된 브랜치로 푸시 할 수 있습니다.

그러나이 작업에서 더 안전하기 위해 이제 원격 저장소에서 수행 할 수 있습니다 (Git 2.3.0, 2015 년 2 월 사용).

git config receive.denyCurrentBranch updateInstead

config보다 안전 receive.denyCurrentBranch=ignore합니다. 진행중인 수정을 재정의하지 않는 경우에만 푸시를 허용합니다.

참조 1404bcb 커밋 에 의해 (요하네스 Schindelin dscho) :

receive-pack: 다음에 대한 다른 옵션 추가 receive.denyCurrentBranch

작업 디렉터리간에 동기화 할 때 ' push'대신 ' ' 를 통해 현재 분기를 업데이트하는 것이 편리 할 수 ​​있습니다 pull. 예를 들어 VM 내부에서 수정 사항을 푸시하거나 사용자의 컴퓨터에서 수정 한 사항을 푸시 할 때 (개발자가 사용자의 암호는 물론이고 ssh 데몬을 설치할 자유).

이 패치에서는 일반적인 해결 방법 (임시 분기로 푸시 한 다음 다른 시스템에서 병합)이 더 이상 필요하지 않습니다.

새로운 옵션은 다음과 같습니다.

updateInstead

그에 따라 작업 트리를 업데이트하되 커밋되지 않은 변경 사항이있는 경우이를 거부하십시오.

---

는 4d7a5ce 커밋 테스트를 더 추가하고 언급한다 :

The previous one tests only the case where a path to be updated by the push-to-deploy has an incompatible change in the target's working tree that has already been added to the index, but the feature itself wants to require the working tree to be a lot cleaner than what is tested.

Add a handful more tests to protect the feature from future changes that mistakenly (from the viewpoint of the inventor of the feature) loosens the cleanliness requirement, namely:

• A change only to the working tree but not to the index is still a change to be protected;
• An untracked file in the working tree that would be overwritten by a push-to-deploy needs to be protected;
• A change that happens to make a file identical to what is being pushed is still a change to be protected (i.e. the feature's cleanliness requirement is more strict than that of checkout).

Also, test that a stat-only change to the working tree is not a reason to reject a push-to-deploy.

With Git < 2.3.0 (Before February 2015)

The most common approach is to create a bare repository from the non-bare repository and have both the remote/local non-bare git repos point at the newly created bare repository.

---

This is the same problem as This question, the solution is to use git init --bare or git clone --bare.

참고URL : https://stackoverflow.com/questions/804545/what-is-this-git-warning-message-when-pushing-changes-to-a-remote-repository