Safer branching

#1

Post by gitdude » Thu, Oct 06, 2016, 6:07 PM UTC

Safer branching
blog.bitbucket.org

Re: Safer branching

#2

Post by josho » Thu, Oct 06, 2016, 6:20 PM UTC

Nope.

My command line git workflow should not require working through a GUI.

Now, if this was added as some git hooks, enforcing the policy from both the command line and GUI then I'd be impressed (and excited).

Re: Safer branching

#3

Post by eridius » Thu, Oct 06, 2016, 6:25 PM UTC

josho wrote: post #2

Nope. My command line git workflow should not require working through a GUI. Now, if this was added as some git hooks, enforcing the policy from both the command line and GUI then I'd be impressed (and excited).

What would be nice is automatically attaching git-notes to commits indicating whether or not they passed CI. That said, I haven't looked into git-notes for a few years, so I'm not sure if they ever made it easy to sync them without a bunch of manual configuration.

Re: Safer branching

#4

Post by kannonboy » Thu, Oct 06, 2016, 6:28 PM UTC

josho wrote: post #2

Nope. My command line git workflow should not require working through a GUI. Now, if this was added as some git hooks, enforcing the policy from both the command line and GUI then I'd be impressed (and excited).

Comic author here. For the command-line I use a post-checkout hook to display the build status of a commit whenever I switch commits:

https://bitbucket.org/tpettersen/bitbucket-build-status-hook

That way if I update master before starting on a new feature, I get a notification if the tip of master is broken (or still building).

Re: Safer branching

#5

Post by guptaneil » Thu, Oct 06, 2016, 6:33 PM UTC

If your company is large enough that somebody can be stuck on a problem somebody else knows the answer to (i.e. pretty much any company with more than ~10 people), you should not be committing directly to master. All commits should be submitted via a pull request that passes your CI and code review (and ideally QA review too) before being merged to master.

Re: Safer branching

#6

Post by kannonboy » Thu, Oct 06, 2016, 6:38 PM UTC

guptaneil wrote: post #5

If your company is large enough that somebody can be stuck on a problem somebody else knows the answer to (i.e. pretty much any company with more than ~10 people), you should not be committing directly to master. All commits should be submitted via a pull request that passes your CI and code review (and ideally QA review too) before being merged to master.

Absolutely. An alternative title for the comic would be "For the love of branch permissions". The second developer in the comic is doing the right thing by creating a feature branch.

However even in a strict branching workflow, there's still a chance you'll have genuine integration failures when two branches are merged, even if they independently pass the tests.

Re: Safer branching

#7

Post by jmakeig » Thu, Oct 06, 2016, 6:40 PM UTC

This is a cultural problem not a technical one. The social contract in a dev team should strictly enforce no cowboy commits to master…ever. If Bob thinks that’s OK, there are more issues than a UI warning is going to solve.

Re: Safer branching

#8

Post by alblue » Thu, Oct 06, 2016, 7:54 PM UTC

josho wrote: post #2

Nope. My command line git workflow should not require working through a GUI. Now, if this was added as some git hooks, enforcing the policy from both the command line and GUI then I'd be impressed (and excited).

That's pretty much what Gerrit does. Works with any git client, since it's just dealing with pushes, and can. E configured to merge automatically or with a manual nudge once the tests pass. And you can do this all through the command line; no GUI needed.

Re: Safer branching

#9

Post by rkeene2 » Thu, Oct 06, 2016, 8:18 PM UTC

My automated build/test server adds a tag (build-pass) to commits that pass the build and another tag (tests-pass) to builds that pass all tests.

So, instead of branching from trunk I would branch from tests-pass and that would be guaranteed to have been tested and pass, e.g.,:

$ fossil branch new my-new-feature tests-pass

I even added some CSS to make this look fancy: http://www.rkeene.org/viewer/tmp/fossil-with-tests.png.htm

Re: Safer branching

#10

Post by dmitry-k » Thu, Oct 06, 2016, 8:55 PM UTC

guptaneil wrote: post #5

If your company is large enough that somebody can be stuck on a problem somebody else knows the answer to (i.e. pretty much any company with more than ~10 people), you should not be committing directly to master. All commits should be submitted via a pull request that passes your CI and code review (and ideally QA review too) before being merged to master.

Couldn't agree more. In RhodeCode (https://rhodecode.com) we use Pull Requests with a voting system. Interested reviewers are added automatically, depending on the repository and the changes being made.