DevOps Zone is brought to you in partnership with:

Consultant with over a decade of experience in build and release engineering, configuration management, and process design, with a focus on discovering business and engineering requirements and meeting those needs to get products shipped. Paul is a DZone MVB and is not an employee of DZone and has posted 24 posts at DZone. You can read more from them at their website. View Full User Profile

The Ship Show: Branching, Merging, and Octopi (Oh My!)

09.20.2013
| 3350 views |
  • submit to reddit

With the explosion in popularity and usage of Git and its distributed version control brethren, developers finally have cheap, easy, local branching. But branching is pointless without merging, and many organizations are finding that Git's free-for-all merge process can leave your organization with (mostly by being totally silent on the subject) code that is error-prone and doesn’t scale, and may even destroy content! As you search for the perfect branching model, questions like “should we use fast-forward merges or merge commits?”, “when do we rebase (if ever)?” and “what repository structure should we use?” are bound to crop up, along with “can’t we just use Git flow?” Join the panel as they grab a razor and a yak and talk:

Branching, Merging, and Octopi (Oh My!)

Join J. Paul Reed, aka @SoberBuildEng, Youssuf El-Kalay, aka @buildscientist, EJ Ciramella, aka @eciramella, Sascha Bates, aka @sascha_d, and Seth Thomas, aka @cheeseplus plus the last couple of weeks in News & Views and a Tool Tip!

Download Episode 27, or any of our previous shows!

Show Links/Notes

Tool Tip

Paul reviews Storm, a tool to “manage your SSH like a boss!”

Join Us!

What branching and merging models do you like? Which ones do you despise?

Or do you just hope you don’t have to worry about any of it?

Join the discussion!


Published at DZone with permission of Paul Reed, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)