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.
Git or SVN? How Nuance Healthcare chose a Git branching model?
Dealing with Maven dependencies when switching to Git
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.
Git: Automatic Merges With Server Side Hooks (For The Win!)
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.
Git Forks And Upstreams: How-to and a cool tip
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.
What's new in Git 2.1
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!
Core Concept, Workflows And Tips
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.
Git team workflows: merge or rebase?
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).
Pull request proficiency: Fetching abilities unlocked!
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.
Git and project dependencies
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.
Simple Git workflow is simple
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.
Use Git even if your team doesn't: git-svn tips and tricks
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.