-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
keep master branch only #464
Comments
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
<#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: |
In that article everything is reasonable except for the marginal difference between Once we merge the |
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 In short: develop in master (so prs target master by default), when starting to release a new major version, create a |
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. |
@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 doand here you will open a pull-request from
feature_xyz
branch tomaster
. The master branch will always be up-to-date with recent developments.The text was updated successfully, but these errors were encountered: