Hi All, I'm completely new to the project and I wanted to follow along for a bit before I jumped in an made any comments, but I I think I have some possible ideas on how to approach this branch name problem/question.. Like Dan said, always branch from develop, master is never touched until after a release branch has been cut and finished. I also think it is note worthy to say that the the feature tracking number from Jira should be placed in the commit message. The reason I say this is because once that branch is merged back to develop there will not be any tags that contain the feature branch's name. As in, there will not be a reference to the feature/GEODE-123 branch anymore. So after everything is all said and done, the only reference we have to a certain "feature" being finished is what is left in the commit messages. I hope this email made sense and I hope I can help out more in the future.
Let me know your thoughts! -Josh On Tue, May 26, 2015 at 5:17 PM, Dan Smith <[email protected]> wrote: > Definitely branch from develop - master shouldn't get touched until we > release. > > I think creating a JIRA for the feature request and mentioning it in the > branch name is a good practice. > > -Dan > > > On Tue, May 26, 2015 at 2:51 PM, Neil Stevenson < > [email protected]> wrote: > > > Hi, > > I have a patch ready to ship for Geode, two amended files and two unit > > tests > > > > Although the instructions are a little unclear, I'm assuming we branch > > from "develop". Not "master" I hope. > > > > If so, how should I name my branch ? Do we need a feature request first > ? > > > > Eg. is the branch "feature/GEODE-123" matching against a Jira > > > > > > The patch itself is fairly small, reinstating ".gfsh2rc" init file > > handling in $GEODE/bin/gfsh > > that disappeared in the transition from GF 6.6 to 7.0 > > > > Obviously this will need amendment once the "gfsh" naming issue > concludes. > > > > Neil > > >
