SIRIUS
SIRIUS copied to clipboard
electronic-structure
keep master branch only
@simonpintarelli @mtaillefumier @AdhocMan
Guys! How about keeping master branch only. It will be updated only through pull requests. On your local git clone you will do
git checkout -b feature_xyz
git push -u upstream feature_xyz
and here you will open a pull-request from feature_xyz branch to master. The master branch will always be up-to-date with recent developments.
it is fine by me and would simplify a lot handling new versions etc... And remove confusion for the user. So I am all in with a twist. Right now the versioning mechanism we have a little bit confusing because incrementing the minor version might involve large changes of code in master. To avoid that, i would suggest to create a branch for each version (for instance 6.4) and put all small corrections in that branch (+master) so all changes in that branch are bug fixes (or small added functionalities in the interface). Basically it would mean 6.4.1 is the same code base (no code refactoring unless very small) but with some minor corrections.
In any cases, I think this proposition is good.
On 1/22/20 2:45 PM, Anton Kozhevnikov wrote:
@simonpintarelli https://github.com/simonpintarelli @mtaillefumier https://github.com/mtaillefumier @AdhocMan https://github.com/AdhocMan
Guys! How about keeping |master| branch only. It will be updated only through pull requests. On your local git clone you will do
|git checkout -b feature_xyz git push -u upstream feature_xyz |
and here you will open a pull-request from |feature_xyz| branch to |master|. The master branch will always be up-to-date with recent developments.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/electronic-structure/SIRIUS/issues/464?email_source=notifications&email_token=AHAE5JMEMPXG4SV2GUZYO7LQ7BEYZA5CNFSM4KKGA5BKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IH6Q2XA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHAE5JJASQ5553BG5SVLAJLQ7BEYZANCNFSM4KKGA5BA.
I just came across desribing a model using a devlop branch: https://nvie.com/posts/a-successful-git-branching-model/ This might be a good workflow to follow.
In that article everything is reasonable except for the marginal difference between develop and release branches. They are really identical because whatever you add to the release branch, you immediately want to merge into the current develop. Thus, I would like to propose a slightly simplified process:
Once we merge the develop into master, we bump the version of the code in develop and start working on the next release. When we merge, we use --no-ff flag as suggested in the article.
Hadn't seen this issue before, so let me share a few thoughts.
I have never really understood the use for the develop branch in the successful-branching-model-article. If it's supposed to be a shared branch, things have to necessarily work already for it to make sense, so why can't it be in master? That simplifies releasing new versions and makes it clear where the latest code is and where to submit PRs to. For stable code people can just checkout a certain tag, right?
Also the successful branching model does not really deal with maintaining older minor versions of the software (hot fixes don't apply to 'master' only if you maintain multiple versions). I would agree with @mtaillefumier that it's useful to keep release branches around named release-<major>.<minor>, so that it's easy to create backports for bugfixes that have been merged into the master branch. In some projects people keep an open PR around that keeps track of all the commits in master that can be backported (e.g. https://github.com/JuliaLang/julia/pull/35825), that can be done by cherry-picking the relevant commits from master. So, you would merge such a pr into the release-<major>-<minor> branch, and then afterwards tag v<major>.<minor>.<patch+1>.
In short: develop in master (so prs target master by default), when starting to release a new major version, create a release-<major>-<minor> branch, sometimes you cherry-pick some bugfix-commits on master (kinda like hot-fixes) and open a PR to one or more older release-<major>-<minor> branches, tags are created inside those release-<major>-<minor> branches.
The develop branch can be useful for instance when you refactor things that touch the core of the code but you do not have enough test coverage of the new code. I am facing this right now with CP2K which does not have a develop branch (they also have this clean linear history policy, no comments) so any pull request with "incomplete feature" will automatically affect everyone, something you do not necessarily want to do. For the rest, I am fine with any scheme that is reasonable.
To be also noted. The linux kernel does not have official devel branch but they have a separate linux-next repository that mimic the devel branch to some extend.
Yeah, I see it can be useful, but I don't immediately see the difference with just keeping a pull request open for a bit longer instead of directly merging it into master.