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. /M [1]: https://github.com/mhagger/git-imerge -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: [email protected] jabber: [email protected] 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
pgpumsgplE6Qw.pgp
Description: PGP signature
