I'm the only one in my organization who's making commits with the following message:
Merge remote-tracking branch 'origin/develop' into develop
Not sure what I'm doing to cause them, but I'd like to stop.
What command am I issuing to create this commit, and what is the proper command I ought to be using to not produce it?
git pull is probably creating the commit. If you make a local commit and then run git pull after someone else pushes a commit up to the repository, Git downloads the other developer's commit and then merges it into your local branch.
You could use git pull --rebase to prevent this from happening in the future, but rebasing has its perils, and I recommend avoiding pull altogether.
Instead, I encourage you to follow this usage pattern:
# download the latest commits
git remote update -p
# update the local branch
git merge --ff-only @{u}
# if the above fails with a complaint that the local branch has
# diverged:
git rebase -p @{u}
git remote update -p downloads all of the commits in the remote repositories and updates the remote tracking branches (e.g., origin/master). It does NOT touch your working directory, index, or local branches.
The -p argument prunes deleted upstream branches. Thus, if the foo branch is deleted in the origin repository, git remote update -p will automatically delete your origin/foo ref.
git merge --ff-only @{u} tells Git to merge the upstream branch (the @{u} argument) into your local branch but only if your local branch can be "fast forwarded" to the upstream branch (in other words, if it hasn't diverged).
git rebase -p @{u} effectively moves the commits you've made but haven't yet pushed on top of the upstream branch, which eliminates the need to create the silly merge commits you're trying to avoid. This improves the linearity of the development history, making it easier to review.
The -p option tells Git to preserve merges. This prevents Git from linearizing the commits being rebased. This is important if, for example, you merged a feature branch into master. Without -p, every commit on the feature branch would be duplicated on master as part of the linearization done by git rebase. This would make the development history harder to review, not easier.
Beware: git rebase might not do what you expect it to do, so review the results before pushing. For example:
git log --graph --oneline --decorate --date-order --color --boundary @{u}..
I prefer this approach over git pull --rebase for the following reasons:
-p (--preserve-merges) option to git rebase in case you need to rebase an intentional merge (e.g., merge of an already-pushed feature branch into master).git up instead of git pullTo make it easy to do the above, I recommend creating an alias called up:
git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'
Now all you need to do to bring your branch up to date is to run:
git up
instead of git pull. If you get an error because your local branch has diverged from the upstream branch, that's your cue to rebase.
git pull --rebase?Running git pull --rebase is equivalent to running git fetch followed by git rebase. This attempts to fast-forward to the new upstream commits, but if that's not possible then it will rebase your local commits onto the new upstream commits. This is usually OK, but be careful:
git pull --rebase does not give you an opportunity to examine the commits before incorporating them. Depending on what changed upstream, it's quite possible that rebase is the wrong operation—a rebase --onto, merge, reset, or push -f might be more appropriate than a plain rebase.--preserve-merges to the rebase operation, so any intentional merge of a feature branch will be linearized, replaying (and thus duplicating) all of the feature branch commits.git pullIf you haven't yet pushed a merge commit created by git pull, you can rebase out the merge commit. Assuming you haven't made any intentional merges (e.g., merging an already-pushed feature branch into your current branch), the following should do it:
git rebase @{u}
The above command tells Git to select all of the non-merge commits reachable from HEAD (the current commit), minus all the commits reachable from @{u} (which is shorthand for "the upstream branch", i.e., origin/master if HEAD is master), replay (cherry-pick) them on top of the upstream branch, and then move the current branch reference to point to the result of replaying the commits. This effectively moves the non-merge commits onto the most recent upstream commit, which eliminates the merge created by git pull.
If you have an intentional merge commit, you don't want to run git rebase @{u} because it will replay everything from the other branch. Dealing with this case is substantially more complicated, which is why it's good to use git up and avoid git pull altogether. You'll probably have to use reset to undo the merge created by pull and then do git rebase -p @{u}. The -p argument to git rebase hasn't worked reliably for me, so you might end up having to use reset to undo the intentional merge, update your local branch to @{u}, and then redo the intentional merge (which is a pain if there were a lot of hairy merge conflicts).
-p. I avoided recommending it before because it's not needed very often and its behavior is not well documented. –
Alcestis git branch --set-upstream. See man git-rev-parse for a description of this and other magic. –
Stairwell git remote update -p and git fetch? –
Patriapatriarch git remote update -p is the same as git fetch --all -p. I got in the habit of using git remote update -p back when fetch didn't have the -p option. –
Alcestis git pull —rebase and doing git merge --ff-only @{u} after git remote update -p? –
Swadeshi git pull --rebase does not prune deleted upstream branches, and (2) if there is a divergence (fast-forward not possible), git pull --rebase will rebase, while git merge --ff-only @{u} will simply exit with an error, giving you the opportunity to rebase or merge (or rebase --onto or reset or push -f or...) as appropriate –
Alcestis -p/--preserve-merges is deprecated and you should use -r/--rebase-merges now. –
Adroit git fetch
git rebase origin/master
That should do it. Or if you want to continue to use pull
git pull --rebase
You can also setup that branch in your config to rebase automatically, or be setup like that automatically for any other future tracking branches you make. Then you can go back to just using
git pull
More on this in the "pull with rebase instead of merge" section of this page:
Merge remote-tracking branch 'origin/develop' into develop
It's a git pull that merged origin/develop (remote changes) into develop (local changes) and we had a lot of problems because of those, loosing code and all.
So now our workflow prevent any problems with git pull merging and keep things simple. Basically it's like a rebase but by merging branch, easily doable in the most basic gui. Others changes are always merged into yours so in case of conflict you only fix what affect the lines you changed! And only your changes appear in the final commit.
Yeah it look like a bit of a hassle, changing branch, pulling and all. But if you look at rebase doc, they warn against using it in shared branch. So you'll end up creating the same X branch then git fetch origin develop and git rebase origin/develop and you still need to merge that rebased X branch back onto the shared branch develop, so the same amount of work.
Normally if there was remote change at step 5 and specially if there was conflict at step 6. You need to test again and it take time, so that's why you go back to step 4. There is a race condition doing step 8 and 9, but it's really a corner case where someone else push right before you.
© 2022 - 2024 — McMap. All rights reserved.
git pull --autostash --rebasework for you @Johnjohn? – Corallite