The Artima Developer Community
Sponsored Link

Java Buzz Forum
Trust the merge and branch simplification musings

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Mathias Bogaert

Posts: 618
Nickname: pathos
Registered: Aug, 2003

Mathias Bogaert is a senior software architect at Intrasoft mainly doing projects for the EC.
Trust the merge and branch simplification musings Posted: Feb 25, 2014 11:47 AM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by Mathias Bogaert.
Original Post: Trust the merge and branch simplification musings
Feed Title: Scuttlebutt
Feed URL:
Feed Description: tech gossip by mathias
Latest Java Buzz Posts
Latest Java Buzz Posts by Mathias Bogaert
Latest Posts From Scuttlebutt


Our recent webinar featuring product rock stars Jens Schumacher and Ken Olofsen gave a great overview of git workflows. Branching workflows go from bare and simple, to complex, robust, and defensive. What is the level of complexity and safeguard needed by your organization? This post covers the compromise between nimbleness and robustness, with some guidelines to choose your own git adventure and lessons learned inside Atlassian. The aim of this article is to give you the insight and tools you can use to decide how to choose the most effective branching model for your team. Guiding thoughts Trust the merge Stay away from branching model extremes. Simplify and flatten branch hierarchies when possible Consider how your development process and your tooling impact the branching model decisions Trust the merge The first step in choosing the optimal branching model is to trust the merge. I mention this for teams that have only recently adopted git; If you’ve passed this step and have embraced the merge, skip this paragraph. While in older systems you could be brought to extreme measures – like avoiding merges at all costs or hire a special team to take care of the merge hell – turns out merges are a non-event in git. This is due to several key things: Because branches are very cheap and fast, git encourages short-lived branches and fast integration. Merges are local in git, hence the result of a merge is often immediate. git knows the ancestry of your branches and only merges the commits that are relevant instead than the entire work-tree flat. This generally results in less conflicts. You have a plethora of merge strategies at your disposal. Because of this you will love to merge and by converse you will also love branching. Branching and merging become so easy that some teams end up with the opposite problem, they go overboard with them. So as with all in life, maintain a balance and don’t overdo it. Stay away from branching extremes If you look at branching models at large – pre- and post-git advent – you see they sit on a spectrum that goes from simple to layered. Extremes can be problematic. Let me show you a few stops on the branching continuum and why you might want them or not. Single branch extreme Memory of subversion past: one branch to rule them all. For years software teams (myself included) worked with just one branch, the trunk, in good or bad weather, with finished on unfinished features, with working or broken builds. This process used to work and it works still today. But it’s not the most efficient anymore. The one branch world we loved to hate and we grew up with and some of us still use, looks like this: Teams fresh on git adoption or teams that want to retain their workflow might try to reproduce the same feel. Even though the trunk in git-speak is now called master you can work with a single branch in git, it looks like this: Everyone works on master, nobody works on branches and every single developer uses rebase to keep up-to-date with the latest changes. This is very close to an old style trunk-only subversion branching model. It’s not uncommon for me to hear modern teams that – yes – […]

The post Trust the merge and branch simplification musings appeared first on Atlassian Blogs.

Read: Trust the merge and branch simplification musings

Topic: Use Java annotation deprecated the right way Previous Topic   Next Topic Topic: Programming Language Job Trends Part 1 – February 2014

Sponsored Links


Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use