
Five advanced Git merge techniques - DanielRibeiro
http://blog.ezyang.com/2010/01/advanced-git-merge/
======
kemayo
`git pull --rebase` is very useful if you use git with an authoritative remote
repo, treating your own repo as having disposable history.

In fact, you can make it the default! Just do: `git config --global
branch.autosetuprebase always` and every branch you create from now on will be
set up to rebase without needing the manual `--rebase`.

Existing branches you can switch by doing: `git config branch.[branch-
name].rebase true` in the repo.

~~~
trust-me
Ufff, I must be doing something very wrong. Once in a while rebase continue
will just fail with cryptic error messages and nothing but a hard reset will
let me continue using the repository. Never had a problem with regular git
pull.

~~~
X-Istence
What are the cryptic error messages?

The only one that I know if is the message stating that the commit is empty
...

In that case simple use git rebase --skip, to skip applying that patch. That
tends to happen when after you fix the "merge" conflict after replaying a
patch and the changeset is empty.

------
perlgeek
Maybe a bit off-topic, but still on the topic of git and merge conflicts:

Soon I will have to do a pretty big merge, with so many conflicts expected
that I don't know if I can resolve them in one day. So usually when I have
such a non-minimal task, I create a branch for it. Is there any sensible way
to do a merge in a branch, and resolve the conflicts on a file-by-file base,
with separate commits for each one?

Or maybe some other way to break down many merge conflicts into several small
pieces?

(We have a heavily patched version of an open source project at $work, and
whenever there is a new upstream release, merging is a huge pain. We do try to
contribute some of our changes back to upstream, but many changes are simply
too specific to go upstream).

~~~
flocial
Doing a big git pull frequently leads to trouble. The rerere command might be
particularly useful for recurring conflicts.

[http://notes.envato.com/developers/rebasing-merge-commits-
in...](http://notes.envato.com/developers/rebasing-merge-commits-in-git/)

<https://news.ycombinator.com/item?id=2874968>

<http://git-scm.com/2010/03/08/rerere.html>

~~~
perlgeek
The conflicts aren't recurring, there are just many of them :(

------
johnpaulett
rerere (`git config --global rerere.enabled true`) is a useful configuration
that allows you to record the merge resolution. Especially useful when
rebasing a branch several times to follow upstream or when working with a
long-lived feature branch that you wish to ensure applies cleanly. It makes
following rebases / merges much quicker.

<http://git-scm.com/2010/03/08/rerere.html>

[https://www.kernel.org/pub/software/scm/git/docs/git-
rerere....](https://www.kernel.org/pub/software/scm/git/docs/git-rerere.html)

------
npsimons
Number five (rebase instead of merge) is what we started doing shortly before
we started using Gerrit. If you've ever gotten sick of seeing all those
"merging" commit messages in git, it's worth trying.

------
crazydiamond
So when I create a new branch, do stuff and want to merge back to master, I
should rebase instead ? (assuming nothing else was done such as pushing
elsewhere etc).

~~~
trust-me
Yeap, the advice here is that you should use `pull --rebase` instead of
`pull`. What that does is it eliminates the merge commit to the "central"
branch (e.g. on github). That is it fakes the history to look as if you
started to work on a branch with all the commits applied and so there were no
merges necessary.

~~~
oelmekki
I suppose you are talking about making pull requests for an upstream
repository owned by someone else (typically : making a pull request to an open
source project), in which case you ask to merge your master in their master ?

When working on a repository where you make a pull request from a feature
branch to master in the same repos (typically : your company private repos), I
would rather merge the feature branch in master rather than rebasing it, at
least to know at which point a dev work has been merged.

The same logic stand, though. If developer has used several branches to build
her feature, I don't want to know about it : she must rebase them instead of
merging them.

Additionally, I like pull requests to master branch to be in a single, well
documented commit. So I encourage developers to make a lot of small commits,
then use `git rebase -i` to squash them into a single commit with a long and
detailed commit message (the one-line previous commit messages being used to
write a changelog). Using github, this has the advantage that the commit
message of a single commit pull request is automatically pre-filled as pull
request message.

