git push --force-with-lease 대 --force

git push --force-with-lease 대 --force

---

나는 차이점을 이해하려고 노력하고 있습니다

git push -f

과

git push --force-with-lease

내 생각 엔 후자는 원격지 에 로컬 브랜치가없는 커밋이없는 경우 에만 원격으로 푸시 한다는 것입니다 .

질문을 표현하는 더 좋은 방법이 있다면, lmk,하지만 분명해 졌으면합니다.

---

force 원격 분기를 로컬 분기로 덮어 씁니다.

--force-with-lease더 많은 커밋이 원격 브랜치에 추가 된 경우 (다른 팀원 또는 동료 또는 귀하가 소유 한) 원격 브랜치의 작업을 덮어 쓰지 않는 더 안전한 옵션입니다. 강제 푸시로 다른 사람의 작업을 덮어 쓰지 않도록합니다.

명령에 대한 일반적인 생각이 맞다고 생각합니다. 원격 분기가 로컬 시스템의 원격 분기와 동일한 값을 갖는 경우 원격을 덮어 씁니다. 값이 같지 않으면 코드 작업을하는 동안 다른 사람이 원격 브랜치를 변경했음을 나타내므로 코드를 덮어 쓰지 않습니다. 분명히 원격에 추가 커밋이 있으면 값이 동일하지 않습니다.

--force-with-lease팀원 코드를 덮어 쓰지 않도록하고 싶을 때 사용하는 옵션으로 생각 합니다. 우리 회사의 많은 팀 --force-with-lease이 안전 장치를위한 기본 옵션으로 사용 합니다. 대부분의 상황에서 불필요하지만 다른 사람이 원격으로 기여한 것을 덮어 쓰면 많은 두통을 줄일 수 있습니다.

나는 당신이 문서를 보았을 것이라고 확신하지만 여기에 더 자세한 설명이 포함될 수 있습니다.

https://git-scm.com/docs/git-push

---

git push --force 는 원격 저장소를 로컬 저장소로 무조건 덮어 쓰기 때문에 파괴적입니다. git의 push --force 는 이미 공유 저장소에 푸시 된 다른 커밋을 파괴 할 수 있으므로 권장하지 않습니다. 강제 푸시의 가장 일반적인 원인 중 하나는 분기를 리베이스해야하는 경우입니다.

예를 들면. Alice와 Bob이 작업 할 기능 브랜치가있는 프로젝트가 있습니다. 둘 다이 저장소를 복제하고 작업을 시작합니다. Alice는 처음에 기능의 일부를 완료하고이를 기본 저장소로 푸시합니다. 이것은 모두 좋고 좋습니다. Bob도 작업을 마쳤지만 작업을 올리기 전에 일부 변경 사항이 master에 병합되었음을 알았습니다. 깨끗한 트리를 유지하기 위해 마스터 브랜치에 대해 리베이스를 수행합니다. 물론, 그가이 리베이스 브랜치를 푸시하러 가면 거절 될 것입니다. 그러나 Alice가 이미 자신의 작업을 푸시했다는 사실을 깨닫지 못하고 그는 푸시-포스를 수행합니다. 안타깝게도 중앙 저장소에서 Alice의 변경 사항에 대한 모든 기록이 지워집니다.

--force-with-lease가하는 일은 우리가 예상하는 상태가 아닌 한 분기 업데이트를 거부하는 것입니다. 즉, 아무도 업스트림 지점을 업데이트하지 않았습니다. 실제로 이것은 참조가 해시이기 때문에 업스트림 참조가 우리가 기대하는 바인지 확인하여 작동하며 부모 체인을 값으로 암시 적으로 인코딩합니다.

다음 은 git push --force 및 git push --force-with-lease에 관한 좋은 게시물입니다.

---

신뢰할 수있는 및 / 또는 공식 출처에서 얻은 답변을 찾고 있습니다.

에 의해 언급 된 "비교 및 스왑" torek 의 의견 과에 그의 다른 대답은 firther에 의해하는 illsutrated되어 힘내 자체의 소스 .

후자는 리모트에 로컬 브랜치에없는 커밋이없는 경우에만 리모트로 푸시합니까?

이 기능은 commit 28f5d17 (2013 년 12 월, Git v1.8.5-rc0) 에서 도입되었습니다.

--force-with-lease 달리 지정하지 않는 한 현재 값이 합리적인 기본값과 동일하도록 요구하여 업데이트 될 모든 원격 참조를 보호합니다.

현재, "일부 합리적인 기본값"은 " 업데이트되는 원격지의 참조에 대해 보유한 원격 추적 분기의 값 "으로 잠정적으로 정의되며 이러한 원격 추적 분기 가 없으면 오류입니다.

따라서 "임대"는 다음을 의미합니다.

" force-with-lease": 리 기반 히스토리가 무엇이어야하는지 결정하기 위해 가져올 때 심판에 대한 임대를 받았다고 가정하고 임대가 중단되지 않은 경우에만 푸시 백 할 수 있습니다.

출처는 여전히 "cas"를 언급합니다.

• 이 옵션은 원래 " cas"( "비교 및 교체"의 경우) 라고 불 렸는데 , 너무 기술적 인 것이기 때문에 아무도 좋아하지 않는 이름입니다.
• 두 번째 시도에서는 "lockref"(개념적으로 잠금을 취한 후 밀어 넣는 것과 유사하기 때문에)라고했지만 "잠금"이라는 단어는 다른 사람이 밀어 넣는 것을 거부 할 수 있다는 것을 암시하기 때문에 싫었습니다.이 옵션이 작동하는 방식이 아닙니다.
• 이 라운드를 "임대시 강제"라고합니다.
  리 기반 히스토리가 무엇인지 결정하기 위해 가져올 때 심판에 대한 임대를 받았다고 가정하고 임대가 중단되지 않은 경우에만 푸시 백 할 수 있습니다.

따라서 : " git push --force-with-leasevs. --force"

" push --force-with-lease기본적으로 " 에서 언급했듯이 Git 2.13 (2017 년 2 분기)에서 언급 했듯이 백그라운드 프로세스 (예 : Git 플러그인이있는 IDE에서 찾은 프로세스)가 실행되는 경우이 옵션 --force-with-lease을 무시할 수 있습니다 git fetch origin.
이 경우 --force우선합니다.

---

서버의 수신 전 후크가 푸시를 수락한다고 가정하면 항상 성공합니다.

git push --force

진행하기 전에 특정 클라이언트 측 검사를 실행하는 반면 :

git push --force-with-lease

수동으로 특정 검사를 실행할 수 있습니다. "임대 확인"알고리즘은 다음과 같습니다.

1. 현재 지점을 파악하십시오.

2. 을 실행 git for-each-ref refs/remotes합니다. git 클라이언트가 현재 브랜치의 업스트림 상태에 해당한다고 생각하는 commit-id를 기록해 둡니다.

예를 들어, "foo"브랜치에있는 경우 "refs / remotes / origin / foo"와 연관된 커밋 ID를 기록해 두십시오.

3. 지금 업스트림 git 서버에서 원격 지점의 실제 커밋 ID를 확인하십시오.

4. 2 단계와 3 단계에서 추출한 commit-id가 일치하는 경우에만 "git push"를 진행하십시오. 즉, 로컬 git 클론의 업스트림 개념이 실제 업스트림과 일치하는 경우에만 진행하십시오.

여기에 슬픈 의미가 있습니다. git fetch"refs / remotes / origin / *"아래의 모든 참조를 최신 버전으로 업데이트하기 때문에이 명령 조합은 기본적으로 다음과 동일합니다 git push --force.

git fetch

# The command below behaves identically to "git push --force"
# if a "git fetch" just happened!

git push --force-with-lease

To work around this inherent weakness in git push --force-with-lease I try to never run git fetch. Instead I always run git pull --rebase whenever I need to sync with upstream, since git pull only updates a single ref under refs/remotes, keeping the "lease" of --force-with-lease useful.

---

Force-with-lease is not necessarily safe. It just works as Sylvie said. One note: In git a branch is just a pointer on a commit. And commits point to zero or more parent commits. Even if you changed the branch entirely with a hard git reset and a forced push or a push with - - force-with-lease without wanting it, that's not necessarily a big problem. You can use your local git reflog to see how your local tip on the branches (Where was HEAD at that time? ) has changed and reset and push the branch again. Then you only lose new commits on the remote branch, but even they might be restored by the team members.

참고URL : https://stackoverflow.com/questions/52823692/git-push-force-with-lease-vs-force