6 ms·

The advice here given to avoid using "master" branch for development, and advice to create non-default branch named "develop" (or variations thereof) is quite h

by watt 9y ago

The advice here given to avoid using "master" branch for development, and advice to create non-default branch named "develop" (or variations thereof) is quite harmful. If you must have a "release" branch or "stable" branch, ok, go for it, but leave the "master" for developing. Why? Strive to have sane defaults. Frankly, the idea that somebody must check out some extra special branch after cloning repo in order to start properly developing, is not sane.

brad0 9y ago
I'm assuming you think it's harmful because master is the branch committed to and pushed by default?
- watt 9y ago
  Yes, because master is the default implicit branch. (Now, in git is possible to designate other branch as default, but folks who follow the advice in article often are not experienced enough to do it.) I know a team that runs this branching model. It's quite surprising to hear statements "we never commit to master branch". "after cloning, always remember to switch to development branch". "when creating pull request, always remember if you used "development" as base". and then the mistakes eat up lot of cycles in the end.
  - madeofpalk 9y ago
    all they've done is just rename master.
_chris_ 9y ago
I find the idea that master is the default is exactly why it should not be the development branch. For open-source software, that's what people download and try to build -- it should always strive to be production ready.
- rleigh 9y ago
  People should be downloading actual releases. This could be release archives, or release tags. Version control is not primarily for consumption of releases, it's for participation in development, and I think the branching strategy should reflect that. Having the current development state be the default branch is entirely suitable for this purpose. I've always found the use of "develop" vs "master" quite jarring, and not even that helpful for an end user. master can change on a whim, while using actual release tags gives you something stable.
  - geezerjay 9y ago
    > People should be downloading actual releases. This could be release archives, or release tags. Yes, and those versions are represented by tags created on the master branch. Github automatically interprets tags created on the master branch as being releases, and even creates nice little tar files with the branch's contents. > master can change on a whim Actually, it can't. According to the Git workflow, the only thing committed to the master branch is either the contents of release branches or hotfixes.
- viraptor 9y ago
  You can have both. With the right tooling you can prevent direct push to master, but at the same time implement CI to which you can submit your branches to be merged to master. This way you can develop against master, you won't push garbage into it by mistake, and you can guarantee that each (first-parent path) commit on master passes the automated tests.
jph 9y ago
> Leave the "master" for developing. IMHO do developing always on topic branches, never on master. This keeps master available for fully-working software, such as for the most-recent successful build using continuous integration, or for always-available deployment, or for external users, etc. To create topic branches, here are git alias commands that you can customize as you like for your git workflows: topic-start = "!f(){ b=$1; git checkout master; git fetch; git rebase; git checkout -b "$b" master; };f" topic-finish = "!f(){ b=$(git branch-name); git checkout master; git branch -d "$b"; git push origin ":$b"; };f" branch-name = rev-parse --abbrev-ref HEAD
- watt 9y ago
  What's the point of running CI on a branch that's effectively for tracking releases only? We run CI on master branch and fix any build breaks or regressions immediately. (That's the job of unit tests and integration tests.) In fact, if your team is smaller, you do release from master branch directly, just tag the release revisions. Then if you need to hotfix it, check out the tag, make a branch, cherrypick a fix to the branch, and do point release from the branch: problem solved. That's if the client running the (older) release version is large enough to justify releasing hotfix instead of doing fix to main stream and just asking to upgrade to latest release. Yes to topic branches. Yes to "cactus model" of rebasing the topic to master. No to the idea that you need extra long-lived "develop" branch in parallel to master.
  - sillysaurus3 9y ago
    I was researching some of this a few weeks ago, and there are many posts about tags being a bad idea. The arguments are that they have to be maintained separately and they lack context. But yes, master branch master race. Also related: "What are the problems with 'a successful Git branching model'?" https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ https://barro.github.io/2016/02/a-succesful-git-branching-mo... Speaking of bad ideas, anyone want to weigh in on merge commits? I've seen arguments in favor of using `git rebase` everywhere, both ways, and to never squash commits. This makes `git bisect` usable, since you never run into a situation where it points to a massive commit as the problem. On the other hand, that seems pretty terrible from a `git log` perspective, since many commits are WIP. But maybe it's not a big deal. My bigger concern is that merge commits provide real context: whenever you merge a topic branch into master, it seems to make sense to have a merge commit for that entire operation. But wouldn't that cause `git bisect` to always point to that merge commit rather than one of the smaller commits?
balladeer 9y ago
I don’t think this article gives advice to not use master for development but rather what it means is: 1. master must only have stable, tested, and production (not production “ready”) code and nothing else 2. If something in production breaks the hotfix should go into master and strive to achieve step 1 In fact this is really a good model. Keeps development streamlined and disciplined. This has nothing to do with breaking the idea of having sane git defaults. In fact it’s a sane utilisation of defaults. Non default branching is a necessity anyway. Default branch usually means just a master branch and committing directly into master, I believe, would lead to disaster. If one has to create branches it should be done for lifestyle steps below production.

by watt 9y ago

brad0 9y ago

I'm assuming you think it's harmful because master is the branch committed to and pushed by default?

watt 9y ago
Yes, because master is the default implicit branch. (Now, in git is possible to designate other branch as default, but folks who follow the advice in article often are not experienced enough to do it.) I know a team that runs this branching model. It's quite surprising to hear statements "we never commit to master branch". "after cloning, always remember to switch to development branch". "when creating pull request, always remember if you used "development" as base". and then the mistakes eat up lot of cycles in the end.
- madeofpalk 9y ago
  all they've done is just rename master.

_chris_ 9y ago

I find the idea that master is the default is exactly why it should not be the development branch. For open-source software, that's what people download and try to build -- it should always strive to be production ready.

rleigh 9y ago
People should be downloading actual releases. This could be release archives, or release tags. Version control is not primarily for consumption of releases, it's for participation in development, and I think the branching strategy should reflect that. Having the current development state be the default branch is entirely suitable for this purpose. I've always found the use of "develop" vs "master" quite jarring, and not even that helpful for an end user. master can change on a whim, while using actual release tags gives you something stable.
- geezerjay 9y ago
  > People should be downloading actual releases. This could be release archives, or release tags. Yes, and those versions are represented by tags created on the master branch. Github automatically interprets tags created on the master branch as being releases, and even creates nice little tar files with the branch's contents. > master can change on a whim Actually, it can't. According to the Git workflow, the only thing committed to the master branch is either the contents of release branches or hotfixes.
viraptor 9y ago
You can have both. With the right tooling you can prevent direct push to master, but at the same time implement CI to which you can submit your branches to be merged to master. This way you can develop against master, you won't push garbage into it by mistake, and you can guarantee that each (first-parent path) commit on master passes the automated tests.

jph 9y ago

> Leave the "master" for developing. IMHO do developing always on topic branches, never on master. This keeps master available for fully-working software, such as for the most-recent successful build using continuous integration, or for always-available deployment, or for external users, etc. To create topic branches, here are git alias commands that you can customize as you like for your git workflows: topic-start = "!f(){ b=$1; git checkout master; git fetch; git rebase; git checkout -b "$b" master; };f" topic-finish = "!f(){ b=$(git branch-name); git checkout master; git branch -d "$b"; git push origin ":$b"; };f" branch-name = rev-parse --abbrev-ref HEAD

watt 9y ago
What's the point of running CI on a branch that's effectively for tracking releases only? We run CI on master branch and fix any build breaks or regressions immediately. (That's the job of unit tests and integration tests.) In fact, if your team is smaller, you do release from master branch directly, just tag the release revisions. Then if you need to hotfix it, check out the tag, make a branch, cherrypick a fix to the branch, and do point release from the branch: problem solved. That's if the client running the (older) release version is large enough to justify releasing hotfix instead of doing fix to main stream and just asking to upgrade to latest release. Yes to topic branches. Yes to "cactus model" of rebasing the topic to master. No to the idea that you need extra long-lived "develop" branch in parallel to master.
- sillysaurus3 9y ago
  I was researching some of this a few weeks ago, and there are many posts about tags being a bad idea. The arguments are that they have to be maintained separately and they lack context. But yes, master branch master race. Also related: "What are the problems with 'a successful Git branching model'?" https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ https://barro.github.io/2016/02/a-succesful-git-branching-mo... Speaking of bad ideas, anyone want to weigh in on merge commits? I've seen arguments in favor of using `git rebase` everywhere, both ways, and to never squash commits. This makes `git bisect` usable, since you never run into a situation where it points to a massive commit as the problem. On the other hand, that seems pretty terrible from a `git log` perspective, since many commits are WIP. But maybe it's not a big deal. My bigger concern is that merge commits provide real context: whenever you merge a topic branch into master, it seems to make sense to have a merge commit for that entire operation. But wouldn't that cause `git bisect` to always point to that merge commit rather than one of the smaller commits?

balladeer 9y ago

I don’t think this article gives advice to not use master for development but rather what it means is: 1. master must only have stable, tested, and production (not production “ready”) code and nothing else 2. If something in production breaks the hotfix should go into master and strive to achieve step 1 In fact this is really a good model. Keeps development streamlined and disciplined. This has nothing to do with breaking the idea of having sane git defaults. In fact it’s a sane utilisation of defaults. Non default branching is a necessity anyway. Default branch usually means just a master branch and committing directly into master, I believe, would lead to disaster. If one has to create branches it should be done for lifestyle steps below production.