I like option 1 as well. In the case where a fix is to be put into both branches, will the developer be responsible for issuing 2 PRs / patches, one against each branch? This would help in the case that the PR/patch against 0.x won't merge cleanly into master; however the reviewer(s) would need to make sure there were no breaking changes as a result of the manual merge to master. An alternative is that the reviewer(s) do the forward-port, which I don't think is a good idea. However the reviewer would need to make sure the PR(s) are against the correct branch. For example, all current PRs would need to be "backported" to the new 0.x branch.
Also, I would think the PRs/patches need to be merged at the same time (or soon), to avoid regressions (i.e. a bug fix going into 0.x but getting forgotten/missed for 1.x). Thoughts? Thanks, Matt On Tue, Mar 29, 2016 at 10:26 AM, Joe Witt <joe.w...@gmail.com> wrote: > I too prefer option 1 > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <b...@jhu.edu> wrote: > > I agree with Tony on option 1. I think it makes sense for master to be > > the most "advanced" branch. New features will then always be applied to > > master, and optionally to other branches for older version support as > > applicable / desired. > > > > On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <trk...@gmail.com> wrote: > > > >> I like option 1 > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" <matt.c.gil...@gmail.com> > wrote: > >> > >> > Hello, > >> > > >> > With NiFi 0.6.0 officially released and our support strategy defined > [1], > >> > I'd like to revisit and propose some options for supporting both a 1.x > >> > branch and 0.x branch concurrently. We need an official place where > these > >> > efforts can be worked, contributed to, and collaborated with the > >> community. > >> > I've already created a 1.x branch as a temporary place for this > codebase > >> to > >> > live until we agree to an approach. > >> > > >> > Either option I'm proposing will require PRs/contributions/patches to > be > >> > applied to both branches as applicable. This means that the > contributor > >> or > >> > the reviewer will need to be able to apply the commits in both places > if > >> > it's necessary. For instance, framework code has already started > >> diverging > >> > from the current master so any framework change may not need to be > >> applied > >> > to both if the changeset is not applicable to the 1.x baseline. > >> > > >> > The only question at the moment is what master will refer to. > >> > > >> > 1) Create a branch for 0.x and allow master to become the 1.x baseline > >> > going forward. Future 0.x releases will be performed from the 0.x > branch. > >> > 2) Continuing working on the 1.x branch as is. Allow master to > continue > >> to > >> > servicing 0.x releases. Once a 1.x release is made, create the 0.x > branch > >> > and then allow master to service 1.x releases. > >> > > >> > In short, when do we want master to point to the 1.x baseline? When > >> should > >> > we create a branch where 0.x releases will be made from. Regardless, > >> > contributions will need to be performed to both places as applicable. > >> > > >> > Thanks. > >> > > >> > Matt > >> > > >> > [1] > >> > > >> > > >> > http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E > >> > > >> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin < > r.p.mis...@gmail.com> > >> > wrote: > >> > > >> > > I guess it will depend how much change is expected on the > maintenance > >> > > branches, > >> > > but if you want every change in the maintenance branch to go into > the > >> > > main-line branch then there is little difference from a conflict > point > >> of > >> > > view > >> > > between a series of cherry-picks and a merge. > >> > > > >> > > Either way, it is just another approach to consider. There’s more > than > >> > one > >> > > way to do it, and I suspect there isn’t any solution that makes it > >> > trivial. > >> > > > >> > > Cheers, > >> > > Richard > >> > > > >> > > > >> > > > On 27 Feb 2016, at 14:43, Aldrin Piri <aldrinp...@gmail.com> > wrote: > >> > > > > >> > > > On board with Tony's points. I think the realities of merging in > >> > > practice > >> > > > when that "breaking point" of sorts occurs will make the > complexity > >> and > >> > > > overhead quite difficult and maybe even more error prone than the > >> > cherry > >> > > > picking approach with some additional guidelines. When the > codebase > >> > > > drastically changes, the merge conflicts could be quite severe and > >> > > without > >> > > > a good knowledge of each part of the codebase involved during that > >> > > process, > >> > > > a committer may introduce regressions. > >> > > > > >> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <trk...@gmail.com> > wrote: > >> > > > > >> > > >> the reason I like applying patches to both lines is that once > code > >> > > begins > >> > > >> to diverge, cleanly merging into one codebase can be impossible. > >> > having > >> > > >> good practices for managing patches and where they apply is > >> paramount > >> > > for > >> > > >> success. > >> > > >> > >> > > >> I expect that divergence to happen with 1.x. I wanted to get in a > >> > battle > >> > > >> rhythm of sorts of managing multiple lines, even if the patches > >> COULD > >> > be > >> > > >> applied to both in the manner you described. > >> > > >> > >> > > >> Joe W and I did a wee bit of scrambling to ensure that tickets > >> marked > >> > > for > >> > > >> 0.5.1 had the right patches in the support branch, and some > didn't, > >> > so I > >> > > >> think "lesson learned". I do like in the apache infrastructure > that > >> if > >> > > >> commits have the appropriate ticket in their commit message, the > >> jira > >> > > will > >> > > >> have the list of commits and branches those commits were applies > to. > >> > > >> However, I think we may need to revisit commit message > "hygiene" if > >> > we > >> > > >> relied on this instead of more manual review. > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin < > >> r.p.mis...@gmail.com > >> > > > >> > > >> wrote: > >> > > >> > >> > > >>> Hi, > >> > > >>> > >> > > >>> On a couple of work projects we found that the approach of > >> > > cherry-picking > >> > > >>> commits can lead to an unnecessarily complicated history where > the > >> > same > >> > > >>> piece of work appears as multiple separate commits on different > >> > > branches. > >> > > >>> This can then make it hard to be confident that a bug fix has > been > >> > > >> applied > >> > > >>> to all relevant branches. We found that it works better to aim > to > >> > > commit > >> > > >>> changes to the lowest applicable branch, and then regularly > merge > >> > those > >> > > >>> branches to master. This approach is based on the git-flow > model ( > >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/ < > >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/>). > >> > > >>> > >> > > >>> Looking at the repo there are already a few commits that are > >> > duplicated > >> > > >> on > >> > > >>> master and 0.5.1. Using the model I suggest they’d only occur on > >> > 0.5.1, > >> > > >> and > >> > > >>> then that branch would get merged to master. > >> > > >>> > >> > > >>> Having the merge commits from the support branch to master > makes it > >> > > >>> explicit in the git history that all bug fixes (and associated > >> tests) > >> > > >> have > >> > > >>> been pulled through to master. > >> > > >>> > >> > > >>> Cheers, > >> > > >>> Richard > >> > > >>> > >> > > >>>> On 26 Feb 2016, at 06:59, James Wing <jvw...@gmail.com> wrote: > >> > > >>>> > >> > > >>>> Thanks, Joe, let me try rephrasing a few of those and see if > you > >> > > agree: > >> > > >>>> > >> > > >>>> 1.) Commits merged to master today are destined for the next > minor > >> > > >>> release, > >> > > >>>> currently 0.6.0, by default? > >> > > >>>> > >> > > >>>> By default, commits to master will be released in the next > major > >> or > >> > > >> minor > >> > > >>>> release. No commits are included in incremental/patch > releases by > >> > > >>> default. > >> > > >>>> > >> > > >>>> > >> > > >>>> 3.) How long will support/0.5.x be maintained? > >> > > >>>> > >> > > >>>> support/0.5.x will be maintained until the first of the > following > >> > > >> events: > >> > > >>>> a.) 0.6.0 is released (next minor release in major release > line) > >> > > >>>> b.) One year after 1.0.0 is released ("previous major release > >> lines > >> > up > >> > > >> to > >> > > >>>> one year since the last minor release (0.4.y, 1.5.y) in that > >> line") > >> > > >>>> > >> > > >>>> But additional support might be available by special request. > >> > > >>>> > >> > > >>>> > >> > > >>>> 4.) Where is compatibility-breaking code destined for a future > >> major > >> > > >>>> release stored? Is it visible anywhere? > >> > > >>>> > >> > > >>>> I suppose Jira tickets targeting the next major release > >> > > >>> could/should/would > >> > > >>>> (do?) push branches. That seems weak in the face of a probable > >> > > >> stampede > >> > > >>>> towards the fire exit of a major release, but it's a start. > I'm > >> not > >> > > >>> aware > >> > > >>>> of any great solutions here, certainly not for an open-source > >> > project. > >> > > >>>> > >> > > >>>> > >> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <joe.w...@gmail.com> > >> > wrote: > >> > > >>>> > >> > > >>>>> James, > >> > > >>>>> > >> > > >>>>> These are great questions to frame and test the model. So > let's > >> > > >>>>> attempt to address them agains the model. > >> > > >>>>> > >> > > >>>>> Here is the language for that model at this time: > >> > > >>>>> > >> > > >>>>> - We support the newest major release line (0.x, 1.x) and any > >> > > previous > >> > > >>>>> major release lines up to one year since the last minor > release > >> > > >>>>> (0.4.y, 1.5.y) in that line > >> > > >>>>> > >> > > >>>>> - When master has no releases we will backport any appropriate > >> > > changes > >> > > >>>>> (fix, feature, enhancement) to the previous major release line > >> > > >>>>> > >> > > >>>>> - Any security or data loss related fixes should be back > ported > >> to > >> > > all > >> > > >>>>> supported major release lines > >> > > >>>>> > >> > > >>>>> - Fixes, improvements, features will be applied to the next > >> release > >> > > >>>>> (minor or incremental) within a given major release line and > will > >> > > only > >> > > >>>>> be back ported on a case by case basis for fixes > >> > > >>>>> > >> > > >>>>> - In order to consider a patch for back porting to a previous > >> minor > >> > > >>>>> release line a request needs to be made to the developer or > user > >> > > >>>>> mailing list with a successful discussion and a release > candidate > >> > > >>>>> produced' > >> > > >>>>> > >> > > >>>>> So with those above let's review 1 through 5 in turn. > >> > > >>>>> > >> > > >>>>> 1.) Commits merged to master today are destined for the next > >> minor > >> > > >>>>> release, currently 0.6.0, by default? > >> > > >>>>> > >> > > >>>>> Master is for whatever is the most leading edge release line > >> > working > >> > > >>>>> toward the next release. At the time that a minor release > occurs > >> > > >>>>> against that release line then it branches off into a > >> support/x.y.* > >> > > >>>>> branch for any further efforts against it. > >> > > >>>>> > >> > > >>>>> 2.) Is master always open for merging new code, or are there > >> > > >>> restrictions > >> > > >>>>> before or after releases? > >> > > >>>>> > >> > > >>>>> I believe master would be always open for new code. From some > >> > point > >> > > >>>>> at which a release is considered feature complete then further > >> > > feature > >> > > >>>>> enhancements need to go on master as part of the next release > >> > effort. > >> > > >>>>> > >> > > >>>>> 3.) How long will support/0.5.x be maintained? > >> > > >>>>> > >> > > >>>>> The most recent minor release line of a major line will be > >> > supported > >> > > >>>>> for up to one year from whenever it was released where > support is > >> > for > >> > > >>>>> bug fixes for security or data loss related items. Releases > for > >> > > older > >> > > >>>>> minor lines should be considered on a case by case basis and > if > >> > > >>>>> requested. Otherwise the basic premise is the train is moving > >> > > >>>>> forward. > >> > > >>>>> > >> > > >>>>> 4.) Where is compatibility-breaking code destined for a future > >> > major > >> > > >>>>> release stored? Is it visible anywhere? > >> > > >>>>> > >> > > >>>>> It must be visible. It should be placed into a branch until > such > >> > > >>>>> time that it is ready to become the new master. That time > would > >> be > >> > > >>>>> when the next release will be for that line. When I think > about > >> > this > >> > > >>>>> against the stated model we could probably tweak the wording > to > >> > > better > >> > > >>>>> articulate that. I think it was what was meant with 'when > master > >> > has > >> > > >>>>> no releases we will backport...' but that is unclear. > >> > > >>>>> > >> > > >>>>> 5.) A critical data/security bug found after 1.0 would > eligible > >> to > >> > be > >> > > >>>>> backported only to the last minor release in the 0.x line, or > to > >> > all > >> > > >>> minor > >> > > >>>>> releases in the 0.x line? > >> > > >>>>> > >> > > >>>>> Only to the most recent minor release of any still supported > >> major > >> > > >>>>> line. However, the catch of 'case by case' determination for > >> older > >> > > >>>>> minor lines is still in play. Basically if someone requests > it > >> and > >> > > >>>>> can get enough momentum for it then it should be no problem to > >> > > produce > >> > > >>>>> such a release. > >> > > >>>>> > >> > > >>>>> Thanks > >> > > >>>>> Joe > >> > > >>>>> > >> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <jvw...@gmail.com > > > >> > > wrote: > >> > > >>>>>> I have some rhetorical questions for discussion of the > branching > >> > > >> model: > >> > > >>>>>> > >> > > >>>>>> 1.) Commits merged to master today are destined for the next > >> minor > >> > > >>>>> release, > >> > > >>>>>> currently 0.6.0, by default? > >> > > >>>>>> > >> > > >>>>>> 2.) Is master always open for merging new code, or are there > >> > > >>> restrictions > >> > > >>>>>> before or after releases? > >> > > >>>>>> > >> > > >>>>>> 3.) How long will support/0.5.x be maintained? > >> > > >>>>>> > >> > > >>>>>> 4.) Where is compatibility-breaking code destined for a > future > >> > major > >> > > >>>>>> release stored? Is it visible anywhere? > >> > > >>>>>> > >> > > >>>>>> 5.) A critical data/security bug found after 1.0 would > eligible > >> to > >> > > be > >> > > >>>>>> backported only to the last minor release in the 0.x line, > or to > >> > all > >> > > >>>>> minor > >> > > >>>>>> releases in the 0.x line? > >> > > >>>>>> > >> > > >>>>>> > >> > > >>>>>> > >> > > >>>>>> > >> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt < > joe.w...@gmail.com> > >> > > >> wrote: > >> > > >>>>>> > >> > > >>>>>>> Given the discussion has stalled i'd like to turn it more > >> toward > >> > a > >> > > >>>>>>> proposal as we're at a point now where we need to start > >> executing > >> > > >> some > >> > > >>>>>>> of these approaches. We're actually already seeing it take > >> form > >> > in > >> > > >>>>>>> the support/0.5.x branch and the master branch (which is for > >> > 0.6.0 > >> > > >> at > >> > > >>>>>>> this point). > >> > > >>>>>>> > >> > > >>>>>>> The proposal then for Git processes based on the other > thread > >> [1] > >> > > >>>>>>> where we outline a support model: > >> > > >>>>>>> > >> > > >>>>>>> - We will have a branch for each major release line > >> > > >>>>>>> > >> > > >>>>>>> - The branch designated 'master' will be for the latest > major > >> > > >> release > >> > > >>>>>>> line under active development > >> > > >>>>>>> > >> > > >>>>>>> - Commits against master should be evaluated for whether > they > >> > > should > >> > > >>>>>>> be cherry-picked to other still supported major release > lines > >> > > >>>>>>> consistent with the community support model > >> > > >>>>>>> > >> > > >>>>>>> - When a release occurs a signed tag will be generated and > the > >> > > >> version > >> > > >>>>>>> for that major line will be bumped to the next incremental > >> > release > >> > > >>>>>>> snapshot > >> > > >>>>>>> > >> > > >>>>>>> - The next commit on a given major release line that > requires a > >> > > >> minor > >> > > >>>>>>> version change should increment the minor version number and > >> > reset > >> > > >>>>>>> incremental to zero > >> > > >>>>>>> > >> > > >>>>>>> - Major version changes should only ever be prompted from > the > >> > > master > >> > > >>>>>>> branch and should only occur when a commit warrants changing > >> the > >> > > >> major > >> > > >>>>>>> version at which point a major release line branch should be > >> > > created > >> > > >>>>>>> off of master for the previous major release line > >> > > >>>>>>> > >> > > >>>>>>> [1] > >> > > >>>>>>> > >> > > >>>>> > >> > > >>> > >> > > >> > >> > > > >> > > >> > http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E > >> > > >>>>>>> > >> > > >>>>>>> Thanks > >> > > >>>>>>> Joe > >> > > >>>>>>> > >> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt < > joe.w...@gmail.com> > >> > > >> wrote: > >> > > >>>>>>>> I don't want to kill this thread. It is good to discuss > >> > specific > >> > > >>>>>>>> tooling/procedures. But I do want to get some consensus > >> > > discussion > >> > > >>>>>>>> around Tony's original intent (as I read it). So kicked > off a > >> > > >>>>>>>> discussion back at that level. > >> > > >>>>>>>> > >> > > >>>>>>>> > >> > > >>>>>>>> > >> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc < > trk...@gmail.com> > >> > > >> wrote: > >> > > >>>>>>>>> While I like gitflow, I can't say I like any of the > plugins > >> > that > >> > > >> are > >> > > >>>>>>> used. > >> > > >>>>>>>>> I have worked on some other projects (unfortunately not > open > >> > > >> source) > >> > > >>>>>>> that > >> > > >>>>>>>>> use a gitflow inspired workflow, without ever using a > plugin. > >> > > Nice > >> > > >>>>> side > >> > > >>>>>>>>> effect is that I believe this got me better at using git, > and > >> > > >>>>> generally > >> > > >>>>>>> we > >> > > >>>>>>>>> all got better at managing merge pain. > >> > > >>>>>>>>> > >> > > >>>>>>>>> On merge problems, I think the reason we're operating the > way > >> > we > >> > > >> are > >> > > >>>>>>> now is > >> > > >>>>>>>>> to avoid merge mayhem. I think the initial bar for a > patch is > >> > > "can > >> > > >>> be > >> > > >>>>>>>>> merged into master", and we have our friend Travis to make > >> this > >> > > >> even > >> > > >>>>>>> easier > >> > > >>>>>>>>> to know upfront. This greatly simplifies things. If a > bugfix > >> is > >> > > >>>>> "patch > >> > > >>>>>>>>> needs to be able to apply onto the current release in > >> progress, > >> > > >>>>> master, > >> > > >>>>>>> and > >> > > >>>>>>>>> several other versions we're supporting, with possibly > >> > > drastically > >> > > >>>>>>>>> different code", well then things get interesting. > >> > > >>>>>>>>> > >> > > >>>>>>>>> > >> > > >>>>>>>>> > >> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies < > >> > > >>>>>>> bimargul...@gmail.com> > >> > > >>>>>>>>> wrote: > >> > > >>>>>>>>> > >> > > >>>>>>>>>> The issue tracker > >> > > >>>>>>>>>> > >> > > >>>>>>>>>> > >> > > >>>>>>> > >> > > >>>>> > >> > > >>> > >> > > >> > >> > > > >> > > >> > https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues > >> > > >>>>>>>>>> might also prove useful in evaluating it. > >> > > >>>>>>>>>> > >> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies > >> > > >>>>>>>>>> <bimargul...@gmail.com> wrote: > >> > > >>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It worked > >> great, > >> > > >>>>> until > >> > > >>>>>>> it > >> > > >>>>>>>>>>> didn't. It would get into terrible, inexplicable, merge > >> > > >> problems. > >> > > >>>>> No > >> > > >>>>>>>>>>> one seemed to be maintaining it. > >> > > >>>>>>>>>>> > >> > > >>>>>>>>>>> There's a new offering in this dept: > >> > > >>>>>>>>>>> > >> > https://github.com/egineering-llc/gitflow-helper-maven-plugin. > >> > > >>>>>>>>>>> > >> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft < > >> > a...@adamtaft.com > >> > > > > >> > > >>>>>>> wrote: > >> > > >>>>>>>>>>>> One of the harder things with gitflow is using it in > >> > > >> combination > >> > > >>>>>>> with > >> > > >>>>>>>>>>>> maven. It's ideal that the tags and releases are > tracking > >> > > >>>>> closely > >> > > >>>>>>> with > >> > > >>>>>>>>>> the > >> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its own, doesn't > keep > >> > the > >> > > >> pom > >> > > >>>>>>>>>> version > >> > > >>>>>>>>>>>> updated with the git release names. > >> > > >>>>>>>>>>>> > >> > > >>>>>>>>>>>> Because of the general importance of keeping releases > and > >> > tags > >> > > >>>>>>>>>> synchronized > >> > > >>>>>>>>>>>> with the pom version, I think whatever we do, it needs > to > >> be > >> > > >>>>>>> approached > >> > > >>>>>>>>>>>> with tools that are available through maven rather than > >> from > >> > > >> git. > >> > > >>>>>>> The > >> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't directly > help > >> > > deal > >> > > >>>>> with > >> > > >>>>>>>>>> this > >> > > >>>>>>>>>>>> synchronization, since it's a git tool, not a maven > tool. > >> > > >>>>>>>>>>>> > >> > > >>>>>>>>>>>> I've been using, with reasonable success, the jgitflow > [1] > >> > > >>>>> plugin, > >> > > >>>>>>> which > >> > > >>>>>>>>>>>> does a reasonable job of following the gitflow model > for a > >> > > >> maven > >> > > >>>>>>>>>> project. > >> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI, because it > insists > >> > > that > >> > > >>>>> the > >> > > >>>>>>>>>> master > >> > > >>>>>>>>>>>> branch is strictly used for published release tags (as > per > >> > the > >> > > >>>>>>> strict > >> > > >>>>>>>>>>>> gitflow workflow). I just mention this, in reference > to > >> how > >> > > >> some > >> > > >>>>>>>>>> plugins > >> > > >>>>>>>>>>>> are tackling the gitflow and maven synchronization > issue. > >> > > >>>>>>>>>>>> > >> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/ > >> > > >>>>>>>>>>>> > >> > > >>>>>>>>>>>> > >> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry < > >> > > >>>>> thadgui...@gmail.com > >> > > >>>>>>>> > >> > > >>>>>>>>>> wrote: > >> > > >>>>>>>>>>>> > >> > > >>>>>>>>>>>>> Your on the right track / idea with Git-flow. Your > >> Master > >> > > >>>>> become > >> > > >>>>>>>>>> primary > >> > > >>>>>>>>>>>>> development of next release (with feature branches > off of > >> > > >> it).. > >> > > >>>>>>> while > >> > > >>>>>>>>>> you > >> > > >>>>>>>>>>>>> continue to have release branches that can have hot > fix > >> > > >> branches > >> > > >>>>>>> off of > >> > > >>>>>>>>>>>>> them. (don't use Master as your release branch ! - > bad > >> > > >>>>> practice ! > >> > > >>>>>>> ) > >> > > >>>>>>>>>>>>> > >> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it easy for > >> > everyone > >> > > >> to > >> > > >>>>>>>>>>>>> understand... just scroll it down to gain the > >> > understanding. > >> > > >> Its > >> > > >>>>>>> really > >> > > >>>>>>>>>>>>> that easy. > >> > > >>>>>>>>>>>>> > >> > > >>>>>>>>>>>>> http://danielkummer.github.io/git-flow-cheatsheet/ > >> > > >>>>>>>>>>>>> > >> > > >>>>>>>>>>>>> Most large projects have moved into using git-flow ... > >> and > >> > > >> tools > >> > > >>>>>>> like > >> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have > Git-flow > >> > > either > >> > > >>>>>>> built > >> > > >>>>>>>>>> in or > >> > > >>>>>>>>>>>>> plugin available now. If you want to live on the > command > >> > > >> line, > >> > > >>>>>>> then > >> > > >>>>>>>>>> that > >> > > >>>>>>>>>>>>> is handled easily by the instructions in the above > link. > >> > > >>>>>>>>>>>>> > >> > > >>>>>>>>>>>>> Thad > >> > > >>>>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry> > >> > > >>>>>>>>>>>>> > >> > > >>>>>>>>>> > >> > > >>>>>>> > >> > > >>>>> > >> > > >>> > >> > > >>> > >> > > >> > >> > > > >> > > > >> > > >> >
