views:

106

answers:

3

Hi guys,

I've got two branches--master and development. Development contains a few completed new features and a couple unfinished modifications--nothing's committed yet, though. Master hasn't changed since the creation of the dev branch. I want to commit the completed features to dev and merge those back into the master branch for deployment, but leave the unfinished modifications on dev uncommitted for now.

Incidentally, there aren't any files that span both categories (e.g. nothing was changed/added as part of a new complete feature that was later modified to be part of an as yet incomplete feature).

My gut instinct is that I should manually add all the implicated files in the finished feature set to the git queue, commit those to dev, and then switch branches to master and do a merge...will that save my work on uncommitted features in the dev branch? Or is this one of those situations that calls for stashing? If so, what's the right order to do things?

Thanks a lot!

Justin

+1  A: 

You can use stash there to keep local mods and go master for merge.

But, if the features are unrelated, I'd commit everything to dev, rebase -i to put the uncompleted feature on top of everything, and then get the id of the last completed commit.

Then from master just do git merge last-completed-commit-id and thats all.

EDIT: with rebase -i you can interactively reorder commits, so if they are independent you shouldn't have a problem there, just git rebase -i HEAD~5(for 5 commits) and reorder lines.
This of course won't work if your commits are not independent and need to be one after each other

Arkaitz Jimenez
I'm not sure I entirely understand what you mean by rebase-ing in this context--could you clarify? My understanding of rebase is that it's usually for bringing a development branch up to speed with changes made independently on a master branch, by importing the new version of the master and then rolling out the changes from development on top. How would I use it in this context?Thanks!
justinbach
A: 

Have a look on stash and some examples how to use it here. Personally I would just commit the dirty branch and then merge with the previous version. Committing is cheap in git, the intention behind is to commit frequently.

sebastiangeiger
+4  A: 

I think the simplest solution, without any tricks, would be:

  1. Use git add <file> for all files which contain changes about finished (ready) feature.
    Sidenote: even if your changes were intermingled, you would be able to use git add --interactive to select which parts of changes you want to have in next commit.

  2. Optionally test your changes that you have now prepare in the index:

    $ git stash --keep-index
    $ run tests
    $ git stash pop
    
  3. Make a commit from changes prepared in the index (which contain changes which are ready)

    $ git commit
    

    (I personally use git commit -s for automatic signoff, but that depends on practices used by your project)

  4. Stash away changes which are not ready yet

    $ git stash save
    
  5. Checkout 'master' branch, and merge in 'dev' branch (this should result in fast-forward):

    $ git checkout master
    $ git merge dev
    
  6. Go back to 'dev' branch, and unstash your changes

    $ git checkout dev
    $ git stash pop
    

You would be able to do that without using git stash, by relying on the fact that 'master' branch should fast-forward and directly manipulating 'master' branch via git update-ref command. I wouldn't recommend it, though.

Jakub Narębski