github workflow question

[Nate Lowrie]

I know this isn't a spree question, but with the recommended branch setup for spree extensions I think it applies.  I understand the rebase/pull request workflow for contributing to another authors extension.  However, I am wondering what the best practice is for pulling commits down to the stable branches of your own extensions. If I commit a particular bug fix on master and want to push only those select commits to the 1-1-stable, 1-2-stable, and 1-3-stable branches, would I cherry pick the commits and apply to the branches or is there another preferred way?

Regards,

Nate

[Ryan Bigg]

Cherry picking is generally how I pull across all the commits I need to the branches they should to into. I'd recommend that workflow.

 

--
 
 

[Washington Luiz]

Hey Ryan out of curiosity, can you tell why you Spree guys sometimes don't just push the merge button? I've noticed you always cherry pick the commits, sometimes even edit the commit message.

[Nate Lowrie]

On Thursday, January 24, 2013 6:25:27 PM UTC-5, Washington Luiz wrote:

Hey Ryan out of curiosity, can you tell why you Spree guys sometimes don't just push the merge button? I've noticed you always cherry pick the commits, sometimes even edit the commit message.

I think the cherry picking over merge is mainly to keep the commit history clean.  I know my first 2 pull requests were so ugly that they needed to be cherry picked because I wasn't using a rebase workflow.  Also, I know I often don't have commit messages properly formatted and cherry picking allows the upstream repo maintainer to do that.  Lastly, just doing a blind merge may result in a non-fast foward merge and you introduce an ugly commit message.

 

On Thursday, January 24, 2013 8:07:19 PM UTC-3, Ryan Bigg wrote:

Cherry picking is generally how I pull across all the commits I need to the branches they should to into. I'd recommend that workflow.

Thanks Ryan.  I think I will probably being doing a blog post shortly on recommended git workflows for spree extensions.

 

[Ryan Bigg]

Nate's description is pretty accurate.

The original reason was to not include the ugly merge commit that pops up. Since then, we've discovered other uses for it.

We rebase to keep the history clean and in 99.9% of cases this has been useful because we can compress PR commits into one and edit commit messages (and sometimes code) as we see necessary. The 0.1% where it's not been useful have been my topic branches where it's taken me HOURS to rebase master onto my branch. But not everything can be perfect.

Also, by clicking the merge button, it'll only merge it to one branch. More often than not, the pull requests are applied to more than one branch (master and 1-3-stable is the standard at the moment). We could ask people to submit multiple PRs, but the current workflow (rebase and cherry picking) is quicker than going through a web UI. I've also got some terminal functions to help me out with things.

I hope that explains it for you.

--