Strategy For Keeping Git Feature Branches Up to Date

Question

I like to keep my feature branches up to date with develop. Is there anything wrong with frequently doing "git merge --no-ff develop". And then at the end, running "git flow feature finish feature1". These feature branches are shared (which means it is possible that someone else could be working on it, or that I'm developing out of it at my computer at home), mostly because I like knowing that they are backed up somewhere else. If they weren't shared, would consistently rebasing be preferred?

Or is it better to not keep your feature branches up to date and just merge everything in at the end?

Afroasiatic

Answer 1

If your branches aren't public, updating via rebase is the best method. If they are public, it's better to just merge them at the end (rather than consistently merging changes into them). Both strategies keep a simple, clean commit and merge history.

Clan

Just so I don't lose what someone else said, in regards to frequently merging and having a dirty merge history, "if you want, just before you finish the feature branch, you can rebase back onto developer. This will strip out all of the merge commits". Would that solve keeping a clean commit and merge history? – Afroasiatic

@RonGarrity: Yeah, you could do that, too. – Clan

When you have long-running branches not keeping them up to date spells disaster. That being said, I don't have anything better to contribute with ... As long as you publish your work you cannot (should not) rebase it, and then ugly merge commits is the only way. – Gabbert

Answer 2

Yes, I think consistently rebasing would be the preferred method. And git-flow currently has a command that serves this purpose (not sure if this command was around when the question was asked): git flow feature rebase <featurename>.

Jeter

This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. – Eventful

I don't see how this isn't an answer to the question, just because it's short and sweet. The author asked, "If they weren't shared, would consistently rebasing be preferred?" I think by posting git-flow's dedicated command for this very thing, it's obvious I'm saying "Yes, this command in particular." But OK, I'll update it to be more explicit. – Jeter

Answer 3

This is how I adapted git-flow for a more powerful version:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

ymmv depending on how granular your work is.

Longitudinal

Thanks. I don't really get this, though: "They should be integrated into an integration branch almost as often as you commit to them." What if management decides to nix a feature you've been working on for a week? What would happen to the integration branch? Or is the integration branch something completely separate from the "develop" branch which is described in "Git Flow a Successful Branching Strategy"? – Afroasiatic

integration and qa "branches" are throw away-able. You use them for a purpose and don't track history there. The feature branches can be remerged with the one you don't want excluded. That's the point of the write up I did. Some people asked about similar things in the comments. – Longitudinal