You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by Jonathan Hurley <jh...@hortonworks.com> on 2016/09/26 13:11:22 UTC
Git Feature Branches
Hi Apache developers,
I put together a simple wiki page outlining the strategy for using feature branches which I think will help us keep our trunk branch stable as we move forward with new development: https://cwiki.apache.org/confluence/display/AMBARI/Git+Feature+Branches
Please have a look and feel free to provide feedback or edit it. The goal was to keep it simple and introduce committers to the feature branch workflow.
We should all adopt this practice for both new features as well as non-feature changes which could potentially destabilize trunk.
Re: Git Feature Branches
Posted by Robert Levas <rl...@hortonworks.com>.
Thanks for the clarification. I like the toast example. ;)
Rob
On 9/26/16, 9:51 AM, "Jonathan Hurley" <jh...@hortonworks.com> wrote:
Hi Rob,
I don't think an epic is necessarily required. Cases where the changes are complex or could destabilize the trunk but don't span more than a few JIRAs probably don't need an Epic. For example, I see you've been working on adding Kerberos authentication to Ambari (awesome!) ... In this case, you might not have needed an epic if the work was only going to span a few different JIRAs. Since it did deal with logging into Ambari, a mistake here could render Ambari unusable, so its good to make your changes in a feature branch to test.
With that said, using an epic to track and group child JIRAs certainly helps with the organization. In the case where you have an epic, yes, you are correct. The child JIRAs would be the commits you see on the feature branch. And when you successfully merge back into trunk, you can close the epic.
For example, let's say you had an Epic where Ambari needs to make toast. You'd have this in JIRA:
AMBARI-1 - Implement Toast Making
AMBARI-2 - Slice Bread
AMBARI-3 - Buy Toaster
AMBARI-4 - Magic
AMBARI-5 - Unit Tests for Making Toast
You feature branch would be called branch-feature-AMBARI-1 and would contain these commits:
AMBARI-2 - Slice Bread
AMBARI-3 - Buy Toaster
AMBARI-4 - Magic
AMBARI-5 - Unit Tests for Making Toast
When you merge back in, each child JIRA appears on trunk. The master Epic, AMBARI-1, does not, and can now be resolved.
> On Sep 26, 2016, at 9:38 AM, Robert Levas <rl...@hortonworks.com> wrote:
>
> Jonathan…
>
> Thanks for the wiki page. This is great. Before reading it, I was a bit confused on how feature branches work.
>
> Based on the content of your wiki page, it seems like a feature branch should be related to an Epic and then all commits to that branch should be related to child JIRAs of that Epic. Would this be a good approach to take, or would the additional Epic create too much unnecessary overhead?
>
> Rob
>
>
> On 9/26/16, 9:11 AM, "Jonathan Hurley" <jh...@hortonworks.com> wrote:
>
> Hi Apache developers,
>
> I put together a simple wiki page outlining the strategy for using feature branches which I think will help us keep our trunk branch stable as we move forward with new development: https://cwiki.apache.org/confluence/display/AMBARI/Git+Feature+Branches
>
> Please have a look and feel free to provide feedback or edit it. The goal was to keep it simple and introduce committers to the feature branch workflow.
>
> We should all adopt this practice for both new features as well as non-feature changes which could potentially destabilize trunk.
>
>
Re: Git Feature Branches
Posted by Jonathan Hurley <jh...@hortonworks.com>.
Hi Rob,
I don't think an epic is necessarily required. Cases where the changes are complex or could destabilize the trunk but don't span more than a few JIRAs probably don't need an Epic. For example, I see you've been working on adding Kerberos authentication to Ambari (awesome!) ... In this case, you might not have needed an epic if the work was only going to span a few different JIRAs. Since it did deal with logging into Ambari, a mistake here could render Ambari unusable, so its good to make your changes in a feature branch to test.
With that said, using an epic to track and group child JIRAs certainly helps with the organization. In the case where you have an epic, yes, you are correct. The child JIRAs would be the commits you see on the feature branch. And when you successfully merge back into trunk, you can close the epic.
For example, let's say you had an Epic where Ambari needs to make toast. You'd have this in JIRA:
AMBARI-1 - Implement Toast Making
AMBARI-2 - Slice Bread
AMBARI-3 - Buy Toaster
AMBARI-4 - Magic
AMBARI-5 - Unit Tests for Making Toast
You feature branch would be called branch-feature-AMBARI-1 and would contain these commits:
AMBARI-2 - Slice Bread
AMBARI-3 - Buy Toaster
AMBARI-4 - Magic
AMBARI-5 - Unit Tests for Making Toast
When you merge back in, each child JIRA appears on trunk. The master Epic, AMBARI-1, does not, and can now be resolved.
> On Sep 26, 2016, at 9:38 AM, Robert Levas <rl...@hortonworks.com> wrote:
>
> Jonathan…
>
> Thanks for the wiki page. This is great. Before reading it, I was a bit confused on how feature branches work.
>
> Based on the content of your wiki page, it seems like a feature branch should be related to an Epic and then all commits to that branch should be related to child JIRAs of that Epic. Would this be a good approach to take, or would the additional Epic create too much unnecessary overhead?
>
> Rob
>
>
> On 9/26/16, 9:11 AM, "Jonathan Hurley" <jh...@hortonworks.com> wrote:
>
> Hi Apache developers,
>
> I put together a simple wiki page outlining the strategy for using feature branches which I think will help us keep our trunk branch stable as we move forward with new development: https://cwiki.apache.org/confluence/display/AMBARI/Git+Feature+Branches
>
> Please have a look and feel free to provide feedback or edit it. The goal was to keep it simple and introduce committers to the feature branch workflow.
>
> We should all adopt this practice for both new features as well as non-feature changes which could potentially destabilize trunk.
>
>
Re: Git Feature Branches
Posted by Robert Levas <rl...@hortonworks.com>.
Jonathan…
Thanks for the wiki page. This is great. Before reading it, I was a bit confused on how feature branches work.
Based on the content of your wiki page, it seems like a feature branch should be related to an Epic and then all commits to that branch should be related to child JIRAs of that Epic. Would this be a good approach to take, or would the additional Epic create too much unnecessary overhead?
Rob
On 9/26/16, 9:11 AM, "Jonathan Hurley" <jh...@hortonworks.com> wrote:
Hi Apache developers,
I put together a simple wiki page outlining the strategy for using feature branches which I think will help us keep our trunk branch stable as we move forward with new development: https://cwiki.apache.org/confluence/display/AMBARI/Git+Feature+Branches
Please have a look and feel free to provide feedback or edit it. The goal was to keep it simple and introduce committers to the feature branch workflow.
We should all adopt this practice for both new features as well as non-feature changes which could potentially destabilize trunk.
Re: Git Feature Branches
Posted by Jonathan Hurley <jh...@hortonworks.com>.
One follow-up note about using feature branches. We're all going to be doing more and more merging with this workflow. As such, it's important that we try to minimize incidental merge conflicts. The biggest offender is when IDEs have different rules for organizing imports. It can wreak havoc on the merge process.
It would be great if all developers could check to ensure that:
- You have "Use *" unchecked so that all imports are explicitly stated.
- The order of imports is:
java
javax
org
com
If during a code review, you see that the IDE has changed the imports incorrectly, please flag it as an issue before the patch can be committed.
Thanks!
- Jonathan
> On Sep 26, 2016, at 9:11 AM, Jonathan Hurley <jh...@hortonworks.com> wrote:
>
> Hi Apache developers,
>
> I put together a simple wiki page outlining the strategy for using feature branches which I think will help us keep our trunk branch stable as we move forward with new development: https://cwiki.apache.org/confluence/display/AMBARI/Git+Feature+Branches
>
> Please have a look and feel free to provide feedback or edit it. The goal was to keep it simple and introduce committers to the feature branch workflow.
>
> We should all adopt this practice for both new features as well as non-feature changes which could potentially destabilize trunk.