Open georg-jung opened 3 years ago
Probably quite a read but it'd be great to know what you think about this @mikimn 😅.
You have some good points, which I might consider at a later time to adopt. The main focus now is to give the current maintainers (students) a strict development policy which they can follow, and since GitFlow is what we are teaching, this is what should be adopted here for now. Since 2 developers are currently actively working on this, I see it as beneficial to have the extra "overhead" that the GitFlow branching model offers. This also allows me to define a unified methodology as per grading requirements, etc..
Releasing is going to be a future issue for this model which I will not worry about currently. I will consider this and leave this issue open for future discussion.
I opened this to discuss how we want to organize this repo's git workflow in the future. Let's start with a brief description of the relevant topics:
git-flow
master
always contains the most recent, live, production versiondevelop
contains the latest version of the code that is not necessarily production readyrelease/*
-branches are created to stabilze a version before release (based ondevelop
)hotfix/*
-branches are like therelease/*
-ones but based onmaster
master
(never fromrelease/*
)NBGV
master
is comparable to whatdevelop
is in git-flowrelease/v*
-branchesfeature/*
branches as needed/if wanted. They are not touched in any way by NBGV or it's branching mindset. One might use them when creating a bigger feature/planning a PR/.... One might not use them when updating the README, introducing minimal changes etc.release/v1.2
would be a typical release branch. A typical version built from there could be1.2.12
(the 12th commit after work on the1.2
version family started). A hotfixed one would be1.2.13
. See their docs for details.Relevant differences
master
vs release fromrelease/v*
.What we currently do
master
anddevelop
like in git-flow.release/v*
like in NBGV.release/v*
.hotfix/*
branches would be possible but never occured yet. Not sure if they ever will. One might add a commit to a release branch too.Problems
contentfulCommit# < workflowCommit#
is a sign of bureaucratization.feature/contributing-guidelines
from develop, not master.IMHO
develop
and amaster
in parallel provides this project with any relevant value while it complicates things quite much. Given that we probably never do hotfixing, release schedules, release stabilization etc., it's just about moving branches around without changing code. This seems error prone to me.What I propose
master
(as in the NBGV section above), deletedevelop
release/v*
branches, usefeature/*
branchesor on develop and then merge into master.feature/*
branch. Apply minor bugfixes etc. directly onmaster
.