branching model

[bernardoaraujor]

Let's agree on a branching model. I propose this https://nvie.com/posts/a-successful-git-branching-model/

@oopsmonk + @strahinjagolic + @djordjeglbvc + @vlad-ns wdyt?

[bernardoaraujor]

however this article suggests merging feature branches into develop via CLI, which is not ideal.

every merge into develop must be done via Pull Requests on Github for proper review.

same goes for merging release branches into master, as well as hotfix branches (if we ever end up doing them)

[oopsmonk]

tbh, the model might too complex and it might slow down the pace at this moment. we can simply have master only or master plus dev.

[strahinjagolic]

I'm not sure that we need release and hotfix branches. I think that master can serve the purpose of the release branch, since it will be a stable branch. We can create a dev branch from master and from dev each developer can create a new branch for current feature or bugfix. I also agree that merging should be cared out via Github for the review purposes.

[djordjeglbvc]

I don't think this model is too complex, we are already using feature branches (branch per issue), master right now serves purpose of develop, but as soon as we go public, I think it would be a good idea to separate master and develop. Master in proposed model gets updated only with each release which is considered stable, and also I think it is good idea to have a separate branch for each release to keep things tidy and for reference. And we continue using develop as we are using master right now.

@strahinjagolic hotfix and release aren't single branches, new ones are created for each release and hotfix. How many of releases we will have depends on a release pace defined for a project (planned). Hotfixes are like releases, but unplanned (eg. critical big bug is found, which must be fixed and pushed to new minor release).

Using this model, I think the only change to a pace compared to a way we are currently doing things will happen around releases, when there will be both tasks which would go only to release branch, or to both release and develop branches.

[bernardoaraujor]

I think it's a general consensus to have a separation between master and develop, so I'm creating develop right now.

I would agree with @oopsmonk and @strahinjagolic in regards to hotfix plus release, since we are still in such an early stage in the project. Once we get closer to a more mature stage where thinking about an actual release workflow starts making more sense, we can resume the discussion around these two branches.

So the remaining open topic is feature branches. @djordjeglbvc seems to be in favour of using them, while @oopsmonk seems to prefer not to.

@oopsmonk how would you suggest we handle not having feature branchs? Something like working on tasks on forks and creating PRs to develop?

[oopsmonk]

I assume feature is implemented by an individual developer at this moment, a feature could be a PR from developer's branch. having a feature branch will be good if we have more developers work on the same feature. I agree with @djordjeglbvc that having a branch on each release.

[bernardoaraujor]

so I guess that brings us to the question:

@vlad-ns will we have a scenario where two developers are working on the same feature branch?

otherwise let's standardize the fork approach proposed by @oopsmonk , where PRs are submitted into develop. and in the future we can discuss a strategy for release branches, and potentially hotfix.

[djordjeglbvc]

If two developers are working on same feature, they could both push to same developer's branch from which pull request is created, I think. We all have access to forks created from iotaledger/access by default, so that wouldn't be an issue. I assume here that developer's branch is created on developer's fork, to leave original repository clean.