You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dear all,
a nice discussion with @zbeekman and @rouson is started here about which workflow model adopt to develop FOODiE. I created this room for not polluting the other, this topic being interesting too.
Workflow, what?
The topic simply concerns the approach we will use to develop FOODiE in a collaborative way, obviously using Git and GitHub. Presently, FOODiE has an official GitHub repository owned by our group where I pushed my commits, but all of you (I hope) will push yours, thus it could be useful to agree on a common workflow.
My approach
Currently, I use the Driessen's branching model (by means of gitflow help) for my local developments and pushing only the master branch on the FOODiE GitHub repository. Essentially, my local workflow is based on a hopefully sane branching approach: I work on the develop branch where I create new branch for each new feature; when a feature is correctly implemented its branch is merged into the develop one; when a set of features have been implemented into the develop branch it is merged into the master and finally pushed to GitHub remote. Besides, I use branch also for hot-fixes and releases.
Zaak's approach
Zaak, if I understand right, prefers the forking that should be more light than the previous one. There is no formal branching naming model for driving the implementation of new feature or fixing bugs, etc... In few words, just fork, branch as you like, push your branches and merge pull requests (maybe I am wrong, I have not deeply read the forking model documentation).
My first thought
The gitflow and forking models are not in contrast: I think we can use both at the same time. I suppose I can (locally) continue to chain up my chaotic development approach on a sane gitflow branching model, while I can (remotely) still collaborate with you by means of a more light and flexible forking model.
Well known workflow models
Besides the Zaak's consideration and mine, it can be useful to review the models that others smart developers use. From thisatlassian tutorial, well known workflow models are:
Dear all,
a nice discussion with @zbeekman and @rouson is started here about which workflow model adopt to develop FOODiE. I created this room for not polluting the other, this topic being interesting too.
Workflow, what?
The topic simply concerns the approach we will use to develop FOODiE in a collaborative way, obviously using Git and GitHub. Presently, FOODiE has an official GitHub repository owned by our group where I pushed my commits, but all of you (I hope) will push yours, thus it could be useful to agree on a common workflow.
My approach
Currently, I use the Driessen's branching model (by means of gitflow help) for my local developments and pushing only the master branch on the FOODiE GitHub repository. Essentially, my local workflow is based on a hopefully sane branching approach: I work on the develop branch where I create new branch for each new feature; when a feature is correctly implemented its branch is merged into the develop one; when a set of features have been implemented into the develop branch it is merged into the master and finally pushed to GitHub remote. Besides, I use branch also for hot-fixes and releases.
Zaak's approach
Zaak, if I understand right, prefers the forking that should be more light than the previous one. There is no formal branching naming model for driving the implementation of new feature or fixing bugs, etc... In few words, just fork, branch as you like, push your branches and merge pull requests (maybe I am wrong, I have not deeply read the forking model documentation).
My first thought
The gitflow and forking models are not in contrast: I think we can use both at the same time. I suppose I can (locally) continue to chain up my chaotic development approach on a sane gitflow branching model, while I can (remotely) still collaborate with you by means of a more light and flexible forking model.
Well known workflow models
Besides the Zaak's consideration and mine, it can be useful to review the models that others smart developers use. From this atlassian tutorial, well known workflow models are:
The vote is started
Post your detailed opinions and your current workflow, please :-)
The text was updated successfully, but these errors were encountered: