* cbd350d 23:26:19 +0200 Init commit (Kai Yuan)Īs the slog output shows, we've squashed the last four commits into one new commit, f9a9cd5. Now here's what we'll see if we check the Git commit log once again: $ git slog Successfully rebased and updated refs/heads/master.
If we save the change and exit the editor, Git will do the rebase following our instructions: $ git rebase -i HEAD~4ġ file changed, 1 insertion(+), 1 deletion(-)
#Git rebase force push how to
There's a detailed guideline on how to control each commit and commit message in the commented lines that follow.įor example, we can change the pick command of commits into s or squash to squash them: So, this is what we should run: git rebase -i HEAD~4Īfter we execute the command, Git will start the system default editor (the Vim editor in this example) with the commits we want to squash and the interactive rebase help information:Īs we can see in the screenshot above, all four commits we want to squash are listed in the editor with the pick command. For example, git push origin +feature will force a push to the feature branch. It's worth mentioning that force push to a public repository could be a dangerous operation, as it may overwrite others' commits.įurther, when we really want to do a force push, we should make sure only to force push the required branch.įor example, we can set the fault property to current so that only the current branch will be pushed/force-pushed to the remote repository.Īlternatively, we can force push to only one branch by adding a “+” in front of the refspec to push. Moreover, if we've squashed already pushed commits, and we would like to publish the squashed result, we have to do a force push. So, in this case, these are the last four commits: * ac7dd5f. If you must do a forced push to a branch with other contributors, try to coordinate with them so that they do not have to deal with errors.It's worth mentioning that when we say “the last X commits,” we're talking about the last X commits from the HEAD. With enough looking at the reflogs the other user’s work can be recovered, but it can lead to a lot of wasted time. This may cause the person to have unexpected errors. If another person had pulled the branch before the forced push, his/her git pull or git fetch will have errors because the local history and the remote history are diverged. Note: git push -force - and even -force-with-lease for that matter - can be a dangerous command because it rewrites the history of the branch. This avoids inadvertently overwriting someone else’s recent push. This can be solved with a git push -force, but consider git push -force-with-lease, indicating that you want the push to fail if the local remote-tracking branch differs from the branch on the remote, e.g., someone else pushed to the remote after the last fetch. Sometimes you need rewrite history with a rebase, but git push complains about doing so because you rewrote history.
0 kommentar(er)
