Are there significant differences between these 2 methods in git flow

user_1454454 0
Viewed 28

I often find I'm working on a gitflow feature branch, and I stumble across something that I later realise actually needs to be a small update to dev (e.g. a configuration change not connected with the feature, but is needed in all branches based on the current dev). But I've already saved the code, so git sees unstaged changes. I think I can resolve this in 2 ways:

  1. git stash, switch back to dev, git pop, commit, switch back to feature, rebase
  2. commit to feature, switch to dev, cherry-pick, switch back to feature

Option 2 feels somehow easier, especially if there are other 'feature-only' changes involved in the initial set of commits needed to deal with all the unstaged changes. It also means I can finish whatever I was working on in feature before stepping aside to put whatever it was back into dev.

But, I'm new to git, and gitflow in particular, so not sure what else might be lurking waiting to bite me later. Is option 2 above a decent way to deal with this scenario? Are there others that would be better for any reason?

git-flow git
1 Answers

I think the option 2 is cleaner. You probably want to do the rebase at the end if your feature branch is supposed to start from the latest dev branch.

Git stash is technically very similar to a real commit so there's not a huge technical difference between either options. You can use gitk to check how stashes look like compared to normal commits. The only important difference is that stash can save info about which changes were in the index and which changes were in the working directory only. If you feel that this information is worth keeping, stash is better.

Other than that, option 2 is enough and it can be extended to more complex cases better so if you learn to use it for this simple case, using the same method for more complex situations may be easier to handle.

An extra option would be to use rebase -i <the common ancestor for your current branch and the dev branch> and move the patch you want into dev as the first commit in your branch. The you can just fast forward the dev branch to that commit. This is a pretty nice method, too, because if you have 5 bugfixes this allows easily moving all those to start of your branch with one rebase. I mostly use this method only personally.

You can update the local dev branch without checkout like this (assuming it's a true fast forward):

git push . sha1-you-want:dev

This works because your push target repo can be current repo (.) and you simply push sha1-you-want as the new dev branch.

user_3344510
Related