Closed ShuffleBugs closed 9 years ago
Should the development branch always be called "master" or is "development" fine for that? Is there any problem with having "master" as the non-default branch, to be used for releases?
"master" is just traditional and is the default for git and github. Github does make it possible to change the default behavior of its interfaces: https://github.com/Loreinator/Shuffle-Move/settings/branches
Making "master" the main development branch could make it easier for collaboration with people already familiar with their git flow, e.g., git fetch origin master
Having a separate development branch is totally fine especially if the goal of master is to have it kept in a shippable state. This just makes the github automation of closing issues delayed until development is merged into master, so there's no need to manually close issues.
I suppose the question is would you prefer issues to be autoclosed when they land on Development or when merged to master?
Honestly, I wasn't even aware of that automatic closing feature. I think I'll go with the setup:
Two branches:
"master": for development, auto-closing to make development faster/more seamless.
"released": for the latest release, the point that Jenkins looks at for building a new release for me - since they are slightly different in naming than development builds.
Thanks for the pointers, I'll do the switch over tonight when I have faster access to my Jenkins server (home connection is 60-80KiB/sec so it takes a few seconds to load pages, but is instant at home).
Thanks for the tips, the new scheme is:
master: For all development released: The branch that spawns releases, allowing an easy way to browse the current state in the 'latest' program.
Typically development happens on the master branch. Github integration has some nice features when things land on master, e.g., auto-close issues and default pull request target. You can track releases with tags or a separate release branch(es).