This is a guest post from Matt Shelton at Nuance Healthcare. This is the first post in a series about his team moving from Subversion to Git, why they did it, and what we encountered along the way. Matt is also speaking on this topic at Atlassian Summit 2015. This series will feature everything he couldn’t say in his 30 minute talk, with more context.
So we're moving to Git and we like git-flow. Now what? Let's test it all out! My team is great. They threw together a hit list of developer workflows in Confluence, all based on what we had been doing as a team and all of the weird things they thought we might have to do in the future. Then, in a project structure mirroring our own (but with no code in it - just a pom.xml), tried every workflow.
We're moving to Git, and we figured out how to use git-flow and Maven together in an efficient devleopment workflow. Before I get into what our workflow looks like now, it's important to know where we came from.
I've been doing a bit of traveling lately on the second leg of the Getting Git Right tour. It's been a blast meeting so many devs from around the world. It's been particularly incredible to see how much git adoption has grown amongst attendees in the few months since we did the first leg of the tour. When we presented in July, almost all attendees raised their hand when we asked "Who's using git?".
Enterprise DVCS Workflows are settling and patterns are consolidating. The flexibility git gives teams is so broad that even within a single company different teams might use different approaches to code sharing and collaboration.
There are tons and then some useful guides on how to keep your
forks updated against the
upstream repositories (and if you're wondering why you would want to use forks in an enterprise setting, check out a few reasons here). In this blog I will introduce you to few aspects of how forking interacts with
upstream: the basics, the gotcha's, and an cool tip. To top it off I will then make you very jealous, or very eager, the choice is yours. Interested? Read on.
Including submodules as part of your Git development allows you to include other projects in your codebase, keeping their history separate but synchronized with yours. It's a convenient way to solve the vendor library and dependency problems. As usual with everything
git, the approach is opinionated and encourages a bit of study before it can be used proficiently. There is already good and detailed information about
submodules out and about so I won't rehash things. What I'll do here is share some interesting things that will help you make the most of this feature.
The question is simple: In a software team using
git and feature branching, what's the best way to incorporate finished work back to your main line of development? It's one of those recurring debates where both sides have strong opinions, and mindful conversation can sometimes be hard (for other examples of heated debate see: The Internet).
While Mercurial has a well defined (albeit internal) API that can be used to write extensions that extend the functionality of Mercurial, git's extension model follows the Unix philosophy of composing small, simple programs to achieve a similar effect. What that means is that git "extensions" can be written in any language and by following a few simple rules it's still possible to add commands that appear as if they were built-in.
Consider the following questions. How do you handle project dependencies with
git? Our project is made up of multiple inter-dependent repositories. Currently we
manage those with
svn:externals. What's the best way to handle those with
git? How do you split a very big repository in smaller components using git? These are some examples of the most asked questions we got at the European leg
of our recent Getting Git Right tour.
Many teams have already migrated to
git and many more are transitioning to it now. Apart from training single developers and appointing Champions to help with the adoption it is imperative to pick a nice and simple code collaboration practice that does not complicate things too much. With
git one can definitely conjure very complicated workflows, I've seen them first hand.
git is an advanced tool. It features a philosophy that is dear to my heart: to treat developers as smart and responsible folks. This means that a lot of power is at your fingertips. The power to also shoot yourself in the foot - arguably with a titanium vest on - but shoot yourself nonetheless.
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.
Before joining Atlassian, I'd been working on various projects that still used Subversion (SVN) as their version control system. I had moved to Git already years before, and I wanted to keep using it as much as possible.
I love scouring the release notes of my favorite tools for hidden (or not so hidden) gems. It's a little bit like Christmas every time. I get that nice feeling of anticipation and curiosity when new versions are released of my faithful OSX open source window manager Slate, on Rails, Django, CoffeeScript and of course Git and many others.