Please also clarify the following scenario: I’m working on a fix for branch-2.6, and when I’m done, I need to merge to trunk.
What is the flow? - Create a fork - Commit to branch-2.6 (on my fork) - Commit to trunk (on my fork) - Create pull request to bring changes to both branches? Or - Create a fork - Commit to branch-2.6 (on my fork) - Create pull request - Commit to trunk (on my fork) - Create pull request This is exposing my git n00bness On 1/4/18, 11:32 AM, "Attila Doroszlai" <[email protected]> wrote: > * Since this new flow model requires a branch for a commit, we should enforce a naming strategy. These short-lived feature branches for commits must be easy to find and remove. We should also make the community aware that once you have had your pull request merged, you should get rid of your branch. As for branch naming conventions, I haven't thought through it very much, but perhaps simply the name of the associated JIRA, such as AMBARI-12345. Correct me if I'm wrong, but the branch to be merged should be created in your own fork, not in the apache/ambari repo. Otherwise non-committers would not be able to create pull requests. I think this eliminates the need to coordinate branch naming, although some convention or pattern would be helpful anyway. -Attila
