Five tips for CI-friendly Git repos

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 development workflow. Before I get into what our workflow looks like now, it's important to know where we came from.

10 years ago Linus Torvalds started writing code for a new distributed version control system on a Sunday and only a mere few days later, the world was given the gift of Git.

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.

Following the git 2.0.0 release two-and-a-half months ago we're being treated to a new minor version of git, 2.1.0, with a host of exciting new features!

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).

git is a fantastic choice for tracking the evolution of your code base and to collaborate efficiently with your peers. But what happens when the repository you want to track is really huge?

The Internet is full of articles on why you should not use Git submodules. I mostly agree, although I am not so harsh in my evaluation. As I explained in a previous post, submodules are useful for a few use cases but have several drawbacks.

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.

Nowadays applying a fix to a project is as easy as creating a fork - which conjures up a full remote copy of the project for you to hack on - selecting the file you want to change, pressing Edit and committing your fixes.

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.

Whether you use git on the command line or via a tool of choice like SourceTree; whether you host your code on Bitbucket Cloud or on Stash (now called Bitbucket Server) behind your company firewall, if you're like me - wink - when a new git release comes out it's always a party.

While we wait for the next major git release which will bring about some serious updates let's peel off the notes of the latest point release: 1.8.5 is upon us!

I know you are all busy with looting marathons in DayZ but bear with me. Something is worth checking out today. The latest git point release (1.9) has come out!

This major release of git has been brewing for a long time and I am excited to go on the hunt in the Changelog to find cool bits of awesomeness. As usual if you want to catch up with past git releases, I've been doing this exercise for a while, check them out: 1.8.2, 1.8.3, 1.8.4, 1.8.5, 1.9.