Comments for Lasse's Bloghttp://wordpress.schuirmann.eu
Let's write good code!Wed, 06 Dec 2017 03:57:18 +0000hourly1https://wordpress.org/?v=4.8Comment on A Git Workflow for Humans by Naveen Kumar Sangihttp://wordpress.schuirmann.eu/2016/09/a-git-workflow-for-humans/#comment-275
Wed, 06 Dec 2017 03:57:18 +0000http://wordpress.schuirmann.eu/?p=432#comment-275It does now. ✌
]]>Comment on whoami by EuroPython: The EuroPython Podcast Episode 1 | Adrian Tudor Web Designer and Programmerhttp://wordpress.schuirmann.eu/whoami/#comment-271
Sat, 30 Sep 2017 19:24:24 +0000http://schuirmann.eu/?page_id=13#comment-271[…] also had Lasse Schuirmann from coala.io. Here is how he describes […]
]]>Comment on GSoC 2017 Starts by Links 1/6/2017: KDE Plasma 5.10, Qt 5.9 Released | Techrightshttp://wordpress.schuirmann.eu/2017/05/gsoc-2017-starts/#comment-246
Thu, 01 Jun 2017 00:48:56 +0000http://wordpress.schuirmann.eu/?p=448#comment-246[…] GSoC 2017 Starts […]
]]>Comment on Google Code In at coala by Links 14/2/2017: Linux Lite 3.4, GNU Health 3.0.6 | Techrightshttp://wordpress.schuirmann.eu/2017/02/google-code-in-at-coala/#comment-234
Tue, 14 Feb 2017 16:57:39 +0000http://wordpress.schuirmann.eu/?p=443#comment-234[…] Google Code In at coala […]
]]>Comment on A Git Workflow for Humans by Aigars Mahinovshttp://wordpress.schuirmann.eu/2016/09/a-git-workflow-for-humans/#comment-200
Wed, 21 Sep 2016 14:53:13 +0000http://wordpress.schuirmann.eu/?p=432#comment-200Gerrit is pretty good for forcing reviews on master and it also has nice plugins on Jenkins for automatic triggering of build for every review request and getting back a Verified +1 when that build succeeds of -1 when it fails. It also has things like rules who can give Reviewed +1 and +2 and bunch of other cool stuff. There are drawbacks, however: it more or less forces you to merge your commits into one before review and it mandates using a commit-msg hook along with a custom push command so that it can create its own Change IDs instead of commit ids which change when you amend a commit.
]]>Comment on A Git Workflow for Humans by Philip Van Hoofhttp://wordpress.schuirmann.eu/2016/09/a-git-workflow-for-humans/#comment-197
Thu, 08 Sep 2016 20:04:08 +0000http://wordpress.schuirmann.eu/?p=432#comment-197Bit silly to inflate the name master for what it is and abandon the name develop. In the gitflow branching strategy your feature branches get merged to develop. The master branch is only for releases. Releases get merged to both develop and master. That means that on master you only get released code. Not just reviewed, but released code. The difference between released and reviewed code is that released code is also tested.

That suddenly clears up the reason behind why calling it develop: untested code is code in development. Thus the branch name develop. Feature branches are alpha code, far, very far, from having been tested properly. You are merging your feature branches right into master. At what point will your testers test?

Testers’ time is valuable too. You don’t want to waste their time with your feature-branch merges. They need a way to get test and retest releases, and they need a way to test what you are going to release before it is released.

In gitflow you also use the difference between develop and master to release hotfix releases. You can easily take the release from master as a branch, fix it there, get it tested, and then merge both develop and master with it (after having made the tested hotfix release). This way the feature-branch merges happily keep on going on in develop, and the hotfix release (which must be vastly, vastly more stable than the flippidyflop new stuff of the developers) is not influenced by “new stuff”. Yet you have a clean way to bring it to both the stable world (master) and the development world (develop).

The main point for developers to start with is therefor develop. Not master. Master is for the people making releases or picking up the role of making releases if they are developers. Most developers are simply too crazy to be given that responsibility. Especially for software that matters. Not tested = not in master.

Respect for a branch named master has nothing to do with it.

Finally, feature branches are for sharing. If you claim ownership of a feature branch by adding your name to it, you are not going to make your personal branch attractive to co-workers to join you on working together on the feature. What you are proposing are personal branches, not feature branches. Good for solo developers. Not good when in a team.

]]>Comment on A Git Workflow for Humans by Fobarhttp://wordpress.schuirmann.eu/2016/09/a-git-workflow-for-humans/#comment-196
Thu, 08 Sep 2016 11:07:23 +0000http://wordpress.schuirmann.eu/?p=432#comment-196For a Git workflow you need to be a git 😉
]]>Comment on A Git Workflow for Humans by Links 7/9/2016: Sony Microsoft Bundling Case, Torvalds’ ‘sh*t-for-brains stupid patch’ | Techrightshttp://wordpress.schuirmann.eu/2016/09/a-git-workflow-for-humans/#comment-195
Wed, 07 Sep 2016 20:49:36 +0000http://wordpress.schuirmann.eu/?p=432#comment-195[…] A Git Workflow for Humans […]
]]>Comment on A Git Workflow for Humans by sils1297http://wordpress.schuirmann.eu/2016/09/a-git-workflow-for-humans/#comment-193
Wed, 07 Sep 2016 12:27:07 +0000http://wordpress.schuirmann.eu/?p=432#comment-193It doesn’t support approvals and the rebase workflow in general. CI stuff works well I think.
]]>Comment on A Git Workflow for Humans by Marius Gedminashttp://wordpress.schuirmann.eu/2016/09/a-git-workflow-for-humans/#comment-192
Wed, 07 Sep 2016 12:18:17 +0000http://wordpress.schuirmann.eu/?p=432#comment-192Curious: which of those features are missing from GitLab Community Edition?
]]>