But you resolve this locally, by updating your (unpushed, local) commit(s) to account for the new history. If there is a conflict because your change and a new commit from origin both changed the same line in the same file, this can result in a merge commit that you need to resolve.
#Gitkraken how to rebase update#
If your change and the new commits from origin aren't touching the same lines or files, then the update is seamless. It will only ever modify your local unpublished commits to account for new commits from the origin branch. "git pulll -rebase" will not ever rewrite history from the origin repository. If "git pull -rebase" succeeds without reporting a merge conflict, then it's tantamount to having executed the command with "-ff-only". If you really want to use actual branches for some reason, that's fine, but "merge master into master" commits are an anti-pattern that if I ever see in a Git repository I'm working on or responsible for, results in me having a conversation with the author about how to use Git correctly. When do you ever want a "git pull" that's not a rebase? That generates a merge commit saying "Merge master into origin/master" (or something similar) which is stupid. Has the project not changed the CLI for compatibility reasons or something? I don't think it's sane behavior for "git pull" to do anything else besides rebase the local change onto the upstream branch, so I'm surprised it's not the command's default behavior. You can achieve this in your global Git configuration by setting "pull.rebase" to "true". I actually thought "git pull" did "git pull -rebase" by default (this may be what you get from running `git -configure` without modifications?), but maybe I've just been configuring it that way. There are configuration settings to make "git pull" rebase by default, and I'd recommend always turning that on that default (which may be by why the person above omitted it from his pull command). The command you want is "git pull -rebase".
0 kommentar(er)
