On Thu, Oct 10, 2013 at 03:41:03PM -0700, Eric Fowler wrote:
> I am a git newbie but have used other SCMs.
> I have two branches, master and X. Both have changes, both have been
> committed. X has a lot of refactoring changes, master has a few bug
> fixes I don't want to lose. 
> I want to merge X into master. But I'm chicken. What if the merge
> fails and leaves me with broken code? There is a deadline coming up
> and that would be disastrous.

Remember, you can always revert after a normal merge by rolling back
the heads of each branch.

> So I want to know exactly what I have to do merge, *knowing* that I
> can easily get to *exactly what I have now*. 

This makes little sense since "exactly what you have now" are two
branches that differ.  I assume you want something that contains a mix
of the changes with the same behaviour as you have now ;)

> What are the steps? Will 'git checkout master; git merge X
> --no-commit' do it? 

There's no strict requirement to not commit, just don't push the merge
changeset until you've verified that everything is as it should be.
If need be you can always amend the merge changeset.

You might want to have a look at the [imerge command][1], it took me a
bit of thinking to understand the theory behind it, but once I started
using it it's made merges a bit easier.


[1]: https://github.com/mhagger/git-imerge

Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe               http://therning.org/magnus

The British have "the perfect temperament to be hackers--technically
skilled, slightly disrespectful of authority, and just a touch of
criminal behavior".
     -- Mary Ann Davidson, Oracle's Security Chief

Attachment: pgpumsgplE6Qw.pgp
Description: PGP signature

Reply via email to