강제로 "git push"로 원격 파일 덮어 쓰기

강제로 "git push"로 원격 파일 덮어 쓰기

---

병합 충돌을 처리하지 않고 로컬 파일을 푸시하고 원격 저장소에 저장하고 싶습니다. 내 로컬 버전이 원격 버전보다 우선 순위를 갖기를 원합니다.

Git으로 어떻게 할 수 있습니까?

---

다음을 사용하여 원격 리포지토리에 로컬 개정을 강제 할 수 있어야합니다.

git push -f <remote> <branch>

(예 :) git push -f origin master. 오프 떠나 <remote>및 <branch>설정 한 모든 현지 지사를 밀어 강제 --set-upstream.

다른 사람이이 저장소를 공유하는 경우 업데이트 기록이 새 저장소와 충돌하게됩니다. 그리고 변경 지점 이후에 로컬 커밋이 있으면 무효화됩니다.

업데이트 : 사이드 노트를 추가하겠다고 생각했습니다. 다른 사람들이 검토 할 변경 사항을 생성하는 경우 해당 변경 사항으로 브랜치를 만들고 주기적으로 리베이스하여 기본 개발 브랜치와 함께 최신 상태로 유지하는 것이 드문 일이 아닙니다. 다른 개발자에게 주기적으로 이런 일이 발생한다는 것을 알려 주면 무엇을 기대해야하는지 알 수 있습니다.

업데이트 2 : 시청자 수가 증가함에 따라 upstream강제 푸시를 경험 했을 때해야 할 일에 대한 추가 정보를 추가하고 싶습니다 .

리포지토리를 복제했고 다음과 같이 몇 가지 커밋을 추가했다고 가정 해 보겠습니다.

            D ---- E 주제
           /
A ---- B ---- C 개발

그러나 나중에 development분기에.이 rebase발생하면 다음을 실행할 때 다음과 같은 오류가 발생합니다 git pull.

개체 포장 풀기 : 100 % (3/3), 완료.
<repo-location>에서
 * 브랜치 개발-> FETCH_HEAD
<파일> 자동 병합
CONFLICT (콘텐츠) : <locations>의 병합 충돌
자동 병합에 실패했습니다. 충돌을 수정 한 다음 결과를 커밋하십시오.

여기에서 충돌을 고칠 수는 commit있지만 정말 추악한 커밋 기록을 남길 것입니다.

       C ---- D ---- E ---- F 주제
      / /
A ---- B -------------- C '개발

사용하는 git pull --force것이 매력적으로 보일 수 있지만 커밋이 좌초 될 수 있으므로주의해야합니다.

            D ---- E 주제

A ---- B ---- C '개발

따라서 아마도 가장 좋은 옵션은 git pull --rebase. 이렇게하려면 이전과 같이 모든 충돌을 해결해야하지만 각 단계에 대해 커밋하는 대신 git rebase --continue. 결국 커밋 기록은 훨씬 더 좋아 보일 것입니다.

            D '--- E'주제
           /
A ---- B ---- C '개발

업데이트 3 : Cupcake의 답변에서 언급했듯이--force-with-lease 옵션을 "안전한"강제 푸시로 사용할 수도 있습니다 .

"임대"로 강제 푸시하면 예상치 못한 원격 커밋이 원격에 새 커밋이있는 경우 강제 푸시가 실패 할 수 있습니다 (기술적으로 아직 원격 추적 브랜치로 가져 오지 않은 경우). 아직 알지 못했던 다른 사람의 커밋을 실수로 덮어 쓰고 싶지 않고 자신의 커밋을 덮어 쓰고 싶을뿐입니다.

git push <remote> <branch> --force-with-lease

--force-with-lease다음을 읽으면 사용 방법에 대한 자세한 내용을 알 수 있습니다 .

• git push 선적 서류 비치
• 힘내 : 빨리 감기를 무시하고 원본 [분기]를 이전 커밋으로 되 돌리는 방법은 무엇입니까?

---

강제로 밀고 싶다

기본적으로 원하는 것은 원격 브랜치를 덮어 쓰기 위해 로컬 브랜치를 강제로 푸시하는 것입니다.

If you want a more detailed explanation of each of the following commands, then see my details section below. You basically have 4 different options for force pushing with Git:

git push <remote> <branch> -f
git push origin master -f # Example

git push <remote> -f
git push origin -f # Example

git push -f

git push <remote> <branch> --force-with-lease

If you want a more detailed explanation of each command, then see my long answers section below.

Warning: force pushing will overwrite the remote branch with the state of the branch that you're pushing. Make sure that this is what you really want to do before you use it, otherwise you may overwrite commits that you actually want to keep.

Force pushing details

Specifying the remote and branch

You can completely specify specific branches and a remote. The -f flag is the short version of --force

git push <remote> <branch> --force
git push <remote> <branch> -f

Omitting the branch

When the branch to push branch is omitted, Git will figure it out based on your config settings. In Git versions after 2.0, a new repo will have default settings to push the currently checked-out branch:

git push <remote> --force

while prior to 2.0, new repos will have default settings to push multiple local branches. The settings in question are the remote.<remote>.push and push.default settings (see below).

Omitting the remote and the branch

When both the remote and the branch are omitted, the behavior of just git push --force is determined by your push.default Git config settings:

git push --force

• As of Git 2.0, the default setting, simple, will basically just push your current branch to its upstream remote counter-part. The remote is determined by the branch's branch.<remote>.remote setting, and defaults to the origin repo otherwise.

• Before Git version 2.0, the default setting, matching, basically just pushes all of your local branches to branches with the same name on the remote (which defaults to origin).

You can read more push.default settings by reading git help config or an online version of the git-config(1) Manual Page.

Force pushing more safely with --force-with-lease

Force pushing with a "lease" allows the force push to fail if there are new commits on the remote that you didn't expect (technically, if you haven't fetched them into your remote-tracking branch yet), which is useful if you don't want to accidentally overwrite someone else's commits that you didn't even know about yet, and you just want to overwrite your own:

git push <remote> <branch> --force-with-lease

You can learn more details about how to use --force-with-lease by reading any of the following:

• git push documentation
• Git: How to ignore fast forward and revert origin [branch] to earlier commit?

---

Another option (to avoid any forced push which can be problematic for other contributors) is to:

• put your new commits in a dedicated branch
• reset your master on origin/master
• merge your dedicated branch to master, always keeping commits from the dedicated branch (meaning creating new revisions on top of master which will mirror your dedicated branch).
  See "git command for making one branch like another" for strategies to simulate a git merge --strategy=theirs.

That way, you can push master to remote without having to force anything.

---

git push -f is a bit destructive because it resets any remote changes that had been made by anyone else on the team. A safer option is {git push --force-with-lease}.

What {--force-with-lease} does is refuse to update a branch unless it is the state that we expect; i.e. nobody has updated the branch upstream. In practice this works by checking that the upstream ref is what we expect, because refs are hashes, and implicitly encode the chain of parents into their value. You can tell {--force-with-lease} exactly what to check for, but by default will check the current remote ref. What this means in practice is that when Alice updates her branch and pushes it up to the remote repository, the ref pointing head of the branch will be updated. Now, unless Bob does a pull from the remote, his local reference to the remote will be out of date. When he goes to push using {--force-with-lease}, git will check the local ref against the new remote and refuse to force the push. {--force-with-lease} effectively only allows you to force-push if no-one else has pushed changes up to the remote in the interim. It's {--force} with the seatbelt on.

---

works for me git push --set-upstream origin master -f

---

Simple steps by using tortoisegit

GIT giving local files commit and pushing into git repository.

Steps :

1) stash changes stash name

2) pull

3) stash pop

4) commit 1 or more files and give commit changes description set author and Date

5) push

참고URL : https://stackoverflow.com/questions/10510462/force-git-push-to-overwrite-remote-files