Development branches / Better code versioning

[pmhpereira]

Right now the master (and only) branch contains features that are incomplete, might change and/or contain lots of bugs that might break some stuff (I didn't test it, just a supposition).

It's difficult for a user to see the giant "Major WIP Update" commit and decide if he can update its current version of the code or not.

There should be finer control of what code is in development and what is ready to be released (i.e. using additional branches/tags and correct version control numbering).

Possible references: https://www.atlassian.com/git/tutorials/comparing-workflows/ (Git Flow works out-of-the-box with SourceTree)

[Seneral]

A very interesting read, I agree currently the management of the Repository goes to zero:( Do you have any suggestions transitioning to this workflow from what we have already? We could just continue with the new workflow, but then we'll still have the existing WIP stuff in the master branch...

[Seneral]

I just created a develop branch, which should be used for developing and branching from for now on. For the purpose of the UnityFunc #37 I also created the first feature branch:)

[Seneral]

I've just one question now. I enabled GitFlow in source tree and I have all the new branches in SourceTree pushed to the origin. But how can I work on seperate branches? I just have my original local copy on my drive now.

[pmhpereira]

You press "Git Flow" and select one of the options. When you want to pause development on that branch and do other stuff, you select one of the branches under Remote. To finish a branch, you select it, press "Git Flow" and then "Finish X".

[Seneral]

Thanks, selecting it from the remote was what I was looking for:)

[groud]

According to some documents, a good workflow consist in creating a new branch for each feature, containing a set of short commits, and then create a pull request for the other contributors to have a look. While the pull request is active, the contributor can push new commits in its branch, and they will automatically be updated into the Github correponding page. People can give some feedback on the code while it's wrote.

Once the code seems ok, we can merge the code into the master (or development) branch.

I think for the moment we could use that workflow and merge directly into the master branch. Till there is no real stable version yet, creating a development branch will just create a "copy" of the master branch. But when we choose to create a stable version (with clean code & all...), creating a development branch will be a good idea ! :)

[Seneral]

We actually do that right now, in two cases. First, the Action node where Kamigaku and me are collaborating. We work directly on a branch for this feature because we work together, so a pull request is not the best idea. We discuss on the issue and push directly to the branch instead. Second case is with the clipping for the bezier curves, pmhpereira has created a pull request directly to develop (extra branch not really needed) and we discuss it in the pull request while he can update to fix things. I think both cases are ok, atleast they have a workflow that matches their situations, if you understand what I mean:)

[groud]

Nice, that's perfect ! I think we should allways stick to this method: no commit at all should be directly done into the master branch. The master branch must stay a sequence of merges from other branches.

Is that ok for everybody ? :)

[Seneral]

Well, if it's a hotfix or something really small, it's enough to create a pull request and let the others review it first (for me too of course;) ), I think so atleast.