Subscribe to RSS

Highest score default Trending recent votes count more Date modified newest first Date created oldest first. Improve this answer. Alan Alan 1, 1 1 gold badge 13 13 silver badges 11 11 bronze badges. Sign up or log in Sign up using Google. Sign up using Facebook. Sign up using Email and Password. Post as a guest Name. Email Required, but never shown. Not the answer you're looking for? Browse other questions tagged git github branch or ask your own question. The Overflow Blog. How engineering teams at a large org can move at startup speed sponsored post. The fine line between product and engineering Ep. Moderation strike: Results of negotiations. Temporary policy: Generative AI e.

Force Push in Git - Everything You Need to Know

Linked 4. Related 2. Hot Network Questions. Question feed. If the server does not support atomic pushes the push will fail. Transmit the given string to the server, which passes them to the pre-receive as well as the post-receive hook. Path to the git-receive-pack program on the remote end. Usually, "git push" refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. This option overrides this restriction if the current value of the remote ref is the expected value. Imagine that you have to rebase what you have already published. You will have to bypass the "must fast-forward" rule in order to replace the history you originally published with the rebased history. If somebody else built on top of your original history while you are rebasing, the tip of the branch at the remote may advance with their commit, and blindly pushing with --force will lose their work. This option allows you to say that you expect the history you are updating is what you rebased and want to replace.

If the remote ref still points at the commit you specified, you can be sure that no other people did anything to the ref. It is like taking a "lease" on the ref without explicitly locking it, and the remote ref is updated only if the "lease" is still valid. A general note on safety: supplying this option without an expected value, i. If your editor or some other system is running git fetch in the background for you a way to mitigate this is to simply set up another remote:. Will fail unless you manually run git fetch origin-push. Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. Also, when --force-with-lease option is used, the command refuses to update a remote ref whose current value does not match what is expected. This flag disables these checks, and can cause the remote repository to lose commits; use it with care. Note that --force applies to all the refs that are pushed, hence using it with push.

This option enables a check that verifies if the tip of the remote-tracking ref is reachable from one of the "reflog" entries of the local branch based in it for a rewrite. The check ensures that any updates from the remote have been incorporated locally by rejecting the forced update if that is not the case. If both are specified, the command-line argument takes precedence. For every branch that is up to date or successfully pushed, add upstream tracking reference, used by argument-less git-pull[1] and other commands. For more information, see branch. These options are passed to git-send-pack[1]. A thin transfer significantly reduces the amount of sent data when the sender and receiver share many of the same objects in common. The default is --thin. Suppress all output, including the listing of updated refs, unless an error occurs. Progress is not reported to the standard error stream. Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified.

This flag forces progress status even if the standard error stream is not directed to a terminal. May be used to make sure all submodule commits used by the revisions to be pushed are available on a remote-tracking branch. If check is used Git will verify that all submodule commits that changed in the revisions to be pushed are available on at least one remote of the submodule. If any commits are missing the push will be aborted and exit with non-zero status. If on-demand is used all submodules that changed in the revisions to be pushed will be pushed. If on-demand was not able to push all necessary revisions it will also be aborted and exit with non-zero status. If only is used all submodules will be pushed while the superproject is left unpushed. A value of no or using --no-recurse-submodules can be used to override the push. When using on-demand or only , if a submodule has a "push. In this case, "only" is treated as "on-demand". Toggle the pre-push hook see githooks[5].

The default is --verify, giving the hook a chance to prevent the push. With --no-verify, the hook is bypassed completely. In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent. Git supports ssh, git, http, and https protocols in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use it. The native transport i. This syntax is only recognized if there are no slashes before the first colon. This helps differentiate a local path that contains a colon. For example the local path foo:bar could be specified as an absolute path or. These two syntaxes are mostly equivalent, except when cloning, when the former implies --local option. See git-clone[1] for details. See git-bundle[1]. To explicitly request a remote helper, the following syntax may be used:. See gitremote-helpers[7] for details.

If there are a large number of similarly-named remote repositories and you want to use a different format for them such that the URLs you use will be rewritten into URLs that work , you can create a configuration section of the form:. All of these also allow you to omit the refspec from the command line because they each contain a refspec which git will use by default. The URL of this remote will be used to access the repository.

Why would anyone want to force push?

The refspec of this remote will be used by default when you do not provide a refspec on the command line. The entry in the config file would appear like this:. Pushing to a remote affects all defined pushurls or to all defined urls if no pushurls are defined. Fetch, however, will only fetch from the first defined url if muliple urls are defined. The URL in this file will be used to access the repository. The refspec in this file will be used as default when you do not provide a refspec on the command line. This file should have the following format:. Push: lines are used by git push and Pull: lines are used by git pull and git fetch. Multiple Push: and Pull: lines may be specified for additional branch mappings. The output of "git push" depends on the transport method used; this section describes the output when pushing over the Git protocol either locally or via ssh. The status of the push is output in tabular form, with each line representing the status of a single ref.

Each line is of the form:. Git did not try to send the ref at all, typically because it is not a fast-forward and you did not force the update. The remote end refused the update. Usually caused by a hook on the remote side, or because the remote repository has one of the following safety options in effect: receive.

Git - Force my local master to be origin/master - Stack Overflow

See git-config[1]. The remote end did not report the successful update of the ref, perhaps because of a temporary error on the remote side, a break in the network connection, or other transient error. In the case of deletion, the name of the local ref is omitted. A human-readable explanation. In the case of successfully pushed refs, no explanation is needed. For a failed ref, the reason for failure is described. When an update changes a branch or more in general, a ref that used to point at commit A to point at another commit B, it is called a fast-forward update if and only if B is a descendant of A. In a fast-forward update from A to B, the set of commits that the original commit A built on top of is a subset of the commits the new commit B builds on top of. Hence, it does not lose any history. In contrast, a non-fast-forward update will lose history. For example, suppose you and somebody else started at the same commit X, and you built a history leading to commit B while the other person built a history leading to commit A.

The history looks like this:. Further suppose that the other person already pushed changes leading to A back to the original repository from which you two obtained the original commit X. The push done by the other person updated the branch that used to point at commit X to point at commit A. It is a fast-forward. But if you try to push, you will attempt to update the branch that now points at A with commit B. This does not fast-forward. If you did so, the changes introduced by commit A will be lost, because everybody will now start building on top of B. The command by default does not allow an update that is not a fast-forward to prevent such loss of history. If you do not want to lose your work history from X to B or the work by the other person history from X to A , you would need to first fetch the history from the repository, create a history that contains changes done by both parties, and push the result back. You can perform "git pull", resolve potential conflicts, and "git push" the result.

A "git pull" will create a merge commit C between commits A and B. Alternatively, you can rebase your change between X and B on top of A, with "git pull --rebase", and push the result back. The rebase will create a new commit D that builds the change between X and B on top of A. There is another common situation where you may encounter non-fast-forward rejection when you try to push, and it is possible even when you are pushing into a repository nobody else pushes into. After you push commit A yourself in the first picture in this section , replace it with "git commit --amend" to produce commit B, and you try to push it out, because forgot that you have pushed A out already. In such a case, and only if you are certain that nobody in the meantime fetched your earlier commit A and started building on top of it , you can run "git push --force" to overwrite it. In other words, "git push --force" is a method reserved for a case where you do mean to lose history.

Without additional configuration, pushes the current branch to the configured upstream branch.