Transcript - Open Office Hours December 2014

Grace Francisco: Good morning, good afternoon, and good evening. Welcome to our Dev Den Office hours. I'm Grace Francisco, one of your hosts. Let me introduce you to some of my fellow co-hosts here. Ian Buchanan, say hello.
Ian Buchanan: Hello.
Grace: We've got Nicola Paolucci.
Nicola Paolucci: Hey, good morning.
Grace: Sorry if I butchered your last name, Nicola. [laughs]

We've got Mr. Steve Smith. Hello, Steve Smith.

Steve Smith: Hi.
Grace: Then we have, of course, the lovely Timothy Pettersen.

[laughter]

Timothy Pettersen: Good morning.
Grace: All right guys, today we're talking all things Git. Before we get going, if you would like to ask us questions at any point in time, make sure you use that Q&A panel that's on the left-hand side there. Ask us at any moment that you feel, and we'll pick those questions as we go.

First up, we just finished a tour, which we called Getting Git Right Tour. The team just came back from Europe and North America. Let's just chat a little bit about what we found from these tours. What are your takeaways, guys? Nicola and Steve, you guys covered Europe. What did you notice about the developer communities there?

Nicola: It was very interesting, because every time we're on the road, you notice that there's a big difference in adoption, changing city by city, or country by country. One of the surprising things was in Helsinki everyone seemed to be already moved to Git for a couple of years, so we had much more advanced conversations then you usually do.

While in Copenhagen, it looks like the market of corporate teams and bigger teams moving to Git was just hitting the right spot, and a lot of people were keen to know a bit of the intricacies of moving teams to Git.

It was very interesting for me just to notice that not everyone everywhere in the world is already on the bandwagon. There are various differences in the stage of adoption. What surprised me from the Milan stop was that about half of the people were already using, when I asked, that were when I was there, which was very interesting to me.

It means even my fellow Italians are keeping up with this major trend. That was one of the things I noticed. What about you Steve?

Steve: Yeah, absolutely very much the same. There are different levels of adoption, so you get different questions. We are going to recap some of the good questions we got. Some people are asking about how you migrate, and how you would deal with difference situations.

Some people have already started to migrate, and are hitting little hiccups, or you want some clarification, or little things like why certain things are happening in [indecipherable 00:02:54] that are different from Subversion, tricky repositories need to be migrated, to local problems. You see how much migration had occurred in a given place by the sort of questions you got.

It was fun to talk to people and have different real-world issues and experiences coming back in different levels from different places. It was a very fun tour -- very, very fast, but very, very cool. Lots of really good energy and excitement around Git right now.

Grace: Tim and Ian, you guys just came back from the North America tour. Tell us a little bit about how that might be different from what happened in Europe.
Tim: It was interesting. Actually, it was kind of a similar experience. We hit Seattle, San Diego, Vancouver, and then Ian went on Montreal. It was really interesting to see the different levels of technology adoption and process adoption in the different cities.

Seattle really stood out as a big tech town. You've got Amazon, Microsoft, and Starbucks there. [laughs] Almost everybody in the audience was already using Git. I think there are one or two hands that didn't come up when we asked who'd already migrated to Git.

We also polled the audience a couple of times asking about different developer processes that they use. In Seattle, there was maybe 70 percent using continuous integration, and about 40 percent doing code review, typically through pull requests. As I mentioned before, everyone was already using Git. This was much higher than in any other cities we that saw.

In San Diego and Vancouver, maybe 40 to 50 percent were using some sort of continuous integration, and far less were using code review, probably 20 to 30 percent, which makes me think that there are probably a lot of people out there using Git, but potentially not using branches and pull requests for doing development.

Ian: One of the things that I saw in the audiences, as I was polling for how long people were using Git, is that many people were not using Git for much longer than a year. Many of the practices they had were still carrying over from Subversion days. Much of the content that we were talking about, in terms of branching and the merged strategies, was really applicable for them so that they could keep adopting better Git practices.
Grace: Super. Before we go on to some of the questions that you guys were getting, I know that there's been a new release of Git 2.2.0. What's new with that release? Can you guys share that with the audience?
Tim: Oh, yeah, Git 2.2.0's huge. There's a bunch of new features, regular performance improvements, and some nice improvements to make the Git onboarding experience better. One example is they made Git-config run some sensible defaults, so it will automatically generate your username and email based on your current system setup, which is really handy.

You've also got a couple of workflow improvements. Git stash list, in particular, how do you display patches? If you haven't heard of the Git stash command, it's a super nice thing that Git offers over other version control systems. Let's you switch contexts really quickly, so you can switch up your workspace quite fast.

What I'm excited about in Git 2.2.0 is signed pushes. If you're not familiar with signing in Git, there's a bit of a myth with DBCS, where people were concerned about having all these different copies of repositories everywhere, and the fact that you can override author and commit metadata locally.

There's a security problem, because potentially people could spoof commits, but it actually has this really powerful and flexible security system called signing, where you can use a GPG key to sign your commit, to basically authenticate that you're the person who created it.

Git his supported signing tags and commits for a long, but Git 2.2.0 actually brings signed pushes questions to the table as well, which means you can actually guarantee that the person who pushed a particular branch or updated a tag or a branch is the person who they say they are.

If you're working in an environment where security is very important, like the finance industry, bio med, banking, or government, then this could be a big win, and potentially one of the last hurdles that need to be overcome before you can adopt Git in your organization.

Ian: One thing that's exciting to me is that in the previous life I was working with open source integrations, and wanted to publish the source code for those, as well as binaries. We got to using the Git archive command. In the 2.2.0 release, there is now support for...

[silence 00:07:32 - 00:09:07]

Nicola: ...will handle binary files, and the Git...
Grace: I'm sorry, Nicola. It looks like we somehow magically got muted. I've un-muted you. Can you just go through that one more time for the audience? Sorry about that.
Nicola: No problem. No problem. [laughs] The question was which recurring questions we get on tour. Which questions were interesting? I had mentioned that I often get a top three, top four of very similar questions.

One very common one is, "How do you handle binary formats, big binary files, when you use Git?" Unfortunately, there's no silver bullet that will solve all people's problems related to this. What I try to give is some pointers to try to tackle that issue.

The first answer I always give is, if you can, do not store binary files in Git. [laughs] If you can find an alternative way to store [indecipherable 00:10:07] your code with binary files, you should investigate that.

An alternative to that, there's a couple of tools that lay on top of Git, which have tried to tackle this complex problem. One fairly popular one is called Git-annex that allows you to store all your binary assets somewhere on a shared drive and only link the metadata related to the versions of the files into your Git repository. That is one of the ways.

Another way, which is slightly suboptimal, but could be a choice for some people, is separating your binary assets into a sub-module. This way, you allow your code to developers, who don't need access to the freshest and latest versions of the binary assets, to work independently in a bit more flexible and fast way. While people that need to be able to build those big assets work on them, they can have full burden of handling the binary files. [laughs]

There's a few other ways and a few other toggles that you can put in place, like creating a custom merge strategy that will allow you to do proper [indecipherable 00:11:22] merges of your proprietary file formats. I've written a little bit about it on the blogs at Atlassian.com. That's one way.

Another common one I get all the time is, "How do you handle dependencies between modules when using Git?" I wrote extensively about that. Our answer is trying to use a dependency management tool like Maven, Bower, or Bundler.

Whichever your tech stack, you are much better off using a solid solution that does dependency management, than using Git with some modules or sub-trees, which can get clunky quite quickly with that.

I don't want to take all the air time, so those are just a couple. I don't know if you guys have other recurring things that came up.

Grace: What about you, Steve?
Steve: One of the favorite ones that came to me on tour was on the most recent tour we started to introduce some low-level concepts, the fundamental building blocks of Git. We found that by understanding those fundamental building blocks -- very few and very, very simple at it's core -- [indecipherable 00:12:38] is actually very simple, conceptually.

If you understand those core concepts, a lot of things that are difficult and confusing about Git suddenly become very simple. People will come to me with tricky little problems that are particularly interesting, like cherry picking versus rebating versus merging and what exactly happens.

Even me and Nicola, when we're bouncing ideas back and forth for work, you kind of go back, "OK, let's look at the conceptual model. How does it fit together? Oh, right, of course. There's no actual merge, because it recognizes that by the common ancestor," or, "Oh, the parent changed, therefore the hash changed," little things like that.

It's more than we can go into in a talk like this, but do check out some of the videos from the Getting Git Right tour or the presentations. They should be available online, cover some of the conceptual ideas around it. It's fun to talk to people after they've heard this. Literally, you can see them go, "Oh, I get it now," always these tricky, little problems. Things that were hard become obvious. That was the coolest part for me.

Grace: Great. Ian and Tim, what kinds of things were you guys getting asked on the North America tour?
Tim: I actually got one of the most technical questions I've ever been asked at any event, particularly Getting Git Right. There was a gentleman who evaluated Git a few years ago, but had some troubles with performance with very large change sets, very large commits. Basically, he'd ended up having a large number of paths were being modified in the same commit, which is a bit of an anti-pattern.

Besides the point, Git wasn't really working out for his workflow, because of an interesting way that the Git index is structured. It used to be a single file that just sits in your Git directory, tracking all of the paths that have been changed. If you have a very large set of paths that have been modified, Git actually has to rewrite that index every time you make a modification, which can be a big performance problem.

It's actually something that changed in Git 2.1.0, where they built a new experimental index format where it creates a monolithic index file. But then, rather than rewriting the entire file when you make changes over a certain size, it actually creates a bunch of delta files that apply to that one.

It was really nice to get that question and be able to say, "Yes, actually Git 2.1 has potentially solved that problem for you." It's still experimental, but it's really cool to see that the Git core team are continually working on performance improvements like this, and thinking about all of those edge cases to improve Git support for different team workflows.

Grace: Cool. Ian?
Ian: One of the things that all of must have heard several times, since we had parts of the presentation that focused on how stash adds some value over Git itself, a lot of people wanted to know what's the difference between Bitbucket and Stash, especially with regard to the integration with JIRA and [indecipherable 00:15:31.24] , as we were demonstrating.

I think pretty much the simple story is that Bitbucket is in the cloud and is host solution. Stash is a behind-the-firewall, on-premise solution and, for the purposes of the integrations that we'd seen, were pretty much on parity there. Over time, we would expect that any future differences that people have noticed would converge and so is really the difference is in deployment models.

Grace: Tim and Steve, you guys just wrapped up a couple of webinars. You guys want to give us a little bit of an update on what you talked about, starting with Steve and some of the outcomes of that webinar?
Steve: Yep, absolutely. The webinar was really about Stash and Bamboo, and about the integrations that we now have enabled in Stash and Bamboo. It's really this idea of a feedback loop. For instance, Stash will feed forward information into Bamboo, and help it make coherent decisions, and yet create new branch plans and generally do a lot of things for you.

In return, Bamboo talks back to Stash and gives you a lot of information and metadata about the state of builds. In particular, "Are tests passing?" "Do you have coverage?" things like that can be passed back into Stash. When your doing pull requests you can use that information to automate a lot of things.

Pull requests and code reviews are an incredible tool. I've blogged about those recently about how we adopted it on the internal systems team for our own good, rather than for some sort of mandate from management or something like that.

It's more work intensive, so by using Bamboo's data to feed back into Stash, you can get Stash to do a lot of the work for you and warn you about potential problems in a pull request, without manually having to inspect, [indecipherable 00:17:26] short circuit some of the problems you might find.

Some questions came out as well. We can talk about a few of them here today. An almost classic for us was Jenkins. We got this lot on tour and we got this in the webinar as well, the comparison to Jenkins. I don't want to do a whole speech about feature comparison, but one thing that worked and was important for us on the internal systems, as a business development team, is we are a finance system.

We had strict requirements regarding how code is deployed and particularly a separation of duties concept that says that only the people who are building the system or are producing the build plans cannot be the people who are releasing the code at the end of the day. The developers can't release the code. There must be a separation of duties.

In Bamboo, there is first-class support for this kind of fine-grained permission and workflows. This concept of deployment environment to understand that you have a development environment, a production environment, staging environment. You might need different rules regarding who can deploy to where. Bamboo has first-class support for that.

That's one of the major reasons why...Obviously we went with Bamboo because it ours but, at the end of the day, that really solved a lot of problems for us and made life a lot easier during the migration to a continuous deployment pipeline.

Tim, any thoughts?

Tim: Yes, in terms of Bamboo, there was a couple of other webinars that I ran as well which you might just recap quickly. There was one a couple of months ago where I just spoke about Git workflows, specifically used by SAS teams. We covered a whole bunch of different topics, focusing on, first of all, why you must use Git after developing SAS in the first place.

We talked a little bit about what makes a SAS workflow different from a traditional application development workflow. My message talked a little bit about the merge strategies and pull request workflows used inside Atlassian, how you can apply a continuous integration and continuous deployment techniques with Git to get the most out of your SAS workflow. I'll post a link to that webinar in just a second.

More recently, I said I did a second webinar on JIRA and Stash integration, showing some of the awesome stuff that the Atlassian Fusion team, which is the team working on building integrations between our various products, has built on top of JIRA and Stash.

One of these is the JIRA development panel that came out last year, which gives you all of the context of your development work inside JIRA, which is really a convenient way of getting more context about a particular issue.

More recently, in JIRA 6.6.3, we released automatic issue transitioning, which is a godsend for product managers. Basically, it means that developers no longer have to keep their due issues up to date. Instead, they'll be automatically updated from Stash, whenever a developer makes a change to the repository.

The main reason I put together that webinar was to show off the new feature that's coming out early next year in JIRA 6.4, which, if you haven't heard about it yet, is the version tab panel. What's really cool about the tab panel, is it actually makes the release process easier by showing you potential problems with your upcoming release.

In fact, I might just see if I can share my screen and give you a quick example of what that's going to look like. Bear with me, I'm fairly new to this Google Hangout thing. Here we go.

This is just a couple of screen grabs from the webinar. Basically, the new version tab panel, which is currently live in JIRA OnDemand, and also available behind the firewall, if you enable a certain feature flag. I'll tweet out exactly what that flag is in a moment.

Inside JIRA, you now have the context of all of your development artifacts related to a particular release. You can see here, we've got a couple of warnings that it's giving us. The first is that there's a failing build associated with an issue, which potentially shows you that if you perform a release at this moment, you might be shipping [indecipherable 00:21:34] product to your customers. This is the super important insight into your code that would potentially be hard to figure out otherwise

We also have some other deeper integrations here. You can say that there are a couple of issues that are marked as closed, that actually I have some un-reviewed code in there. Because we have [indecipherable 00:21:52] and pull requests, typically every line of code is checked by at least two other developers at Atlassian, before it gets sent to our customers.

Again, that's something we'd want to address before we ship it to our customers. That's coming up in JIRA 6.4. If you are into automating workflow and just getting insight into your release process, I highly recommend checking that out.

They were quite well-attended webinars, and there are quite a few questions that we got, which I unfortunately didn't have enough time to answer during the webinar itself. I'm currently writing a recap blog on that. But, just to cover a couple now, I have a few questions here.

One of the biggest questions that I got is that people love the idea of the Stash and JIRA integration, but they wonder whether it's possible to integrate other issue trackers into Stash and get that same JIRA experience. Whether you could do the reverse and integrate other repository hosts into JIRA, if you're using something else to integrate your Git repositories.

The answer is kind of a yes and no. Both Stash and JIRA have very in-depth plug-in systems. It's been one of our development philosophies at Atlassian for a long time to make sure all of our products were as extensible as possible, so you can customize and them to your workflow.

Theoretically, you could integrate other issue trackers into Stash and other repository hosts into JIRA. However, the depth of the integration that we have between two of them is something that's taken our fusion team a significant amount of time and investment to build. While you can integrate other products into workflow to get that same experience, it would be a significant investment and something that you should evaluate carefully before jumping into.

Another good question that I got from that particular webinar was whether it's possible to distribute Git commit hooks with Stash. This is a question that's actually come up at Getting Git Right a couple of times as well, because we do talk a little bit about commit hooks, which are basically the plug-in system for Git.

Commit hooks are not a problem, but something that doesn't have a really good solution as yet. Commit hooks are things that developers have to install locally in repositories. Being a distributed version control system, there's no way that you, as an administrator or a team lead, can enforce that your developments are running certain commit hooks.

In terms of distributing and syndicating hooks, the best solution that we've come up with at Atlassian is actually check those hooks into your repository, and then basically symlink them into your Git hooks directory.

We've tried a few different approaches, like attaching them to project pages, Wiki pages, and putting them into our developer guides, but that simple concept of putting them in your repository means that they get syndicated with the repository. The only manual step your developer has to do is just symlink them into that directory. That seems to be the most practical way we've come to approach that particular problem.

Nicola: If I may project it, if you don't trust that people are going to actually symlink them by themselves, if you just apply it to your build commands, so that they check that the links exist. That can enforce it out of the box without having to go on every developer's desk. [laughs]
Tim: Absolutely yeah. [laughs] As well, another step is that any commit hook that is vital to your build process, you should absolutely enforce that on the server as well, in our [indecipherable 00:25:12] or an update hook. People will quite often write lint tests, and check-style tests to run locally as part of commit hook, but that should always be a convenience thing rather than an enforcement of the policies that you apply to your build.
Nicola: You're sharing your screen by the way.
Tim: Oh.

[laughter]

Grace: Steve, you want to talk a little bit more about the webinar you ran, and some of the questions that you were asked?
Steve: Yeah, absolutely. Another one that came up again comes back to permission, is a lot of questions about can pull requests be approved by a member of the group? Can you have separate groups of people who are allowed to approve pull requests, versus people who are submitting pull request, or creating branches?

Another one that came up is can you control a master branch at regular intervals during a release-critical period? The answer, of course, is yes. This is really what Stash delivers above and on top of Git. Git doesn't really have much of a permissions concept in and of itself. It has a couple of really cool things, like Tim mentioned, like signing, but they're really ways of authenticating history.

In the terms of a day-to-day workflow basis, there's no real concept that committer A can only commit to Branch A, and it's only certain people who can merge to the master. This is where Stash comes in and where it adds this layer of authentication and permissions on top of the Git workflow, which is one of those things that the open source world does not need so much. It works quite differently, but enterprise really needs these sorts of slightly different and more controlled workflows in many cases.

That's pretty much it. If you need complex permission systems, if you need something layered on top of Git that provides an extra layer of management, of course I would recommend Stash.

Grace: Great. So guys, tell me a couple of things. What else is coming up in Git, and if you were to have a crystal ball, what would you predict might come out of Git in the future?
Tim: It's an interesting question.

[laughter]

Tim: One of the things that seems to come out in every Git release are performance improvements, which I think is fantastic. Particular since GitHub obviously dominated the market in terms of fast version control.

It's kind of one of their biggest things -- performance to feature -- but it's great to see they are continuing to build out that performance, improve the way that they restore data on disk and the way that they improve your indexing performance and your [indecipherable 00:27:57] protocols, always in a backwards compatible way, of course.

If I were going to make one predication, I would guess that Git is going to get faster. It's also interesting, if you follow the Git mailing list, they're very militant on making sure that new features that get written don't affect the existing performance.

Another prediction, or an anti-prediction, is that Git is not one of those things that going to end up with feature bloat. Anything that does get added typically goes through a very stringent quality control process, and there's always a lot of discussion around whether we actually need this particular feature.

So, yes, I expect it to get faster and faster

Grace: Super.
Nicola: There is something that I saw. It's not specifically related to Git road map, but it was very interesting. One of our colleagues, Stefan Saasen, who's an architect on the Stash team, spent a few weekends rewriting the entire Git clone command in Haskell. He has this really long, 30,000-word article, where he breaks how Git stores data, and rebuilds it from scratch using Haskell. It was yesterday in "Hacker News," funnily enough, because it's actually a year-old article, but I found it very interesting.

Just in the last Getting Git Right tour, as Steve was mentioning, we wanted to give people a sense of the low-level infrastructures of Git. Once you understand the low-level infrastructures, you have a much clearer picture of what's happening.

If you guys are interested in having a really deep dive into how Git generates the pack files and the networking protocols, it's a very interesting read. You don't really need to know a lot about Haskell to follow that article. It will give you a lot of insight into low-level mechanics of the...

Ah, there you go. I see Tim has already posted the link in the chat, so you guys are encouraged to check that one.

Steve: To even expand a little bit more on that, one of the questions that comes up occasionally you see on Stack Overflow, and you have these conversation sometimes even inside company like, "You're learning a new language. What you do?"

You want to learn the language, you don't quite know what you're going to do. I used to say BitTorrent. I don't mean the full BitTorrent client. I mean, to be able to read, parse, and write a BitTorrent file. It's one of the things, it's a spec you can fit in your head. You don't need to go and re-examine the spec every time. It's a really simple thought map.

Nowadays, if somebody asked me that, I would say Git. You [indecipherable 00:30:41] the full network stuff, and the pack file is a bit of a complex idea. But the core concept of Git, you can write something that reads and writes a Git repository in a few days, in a weekend. It teaches you a lot about the language, and the Git spec fits in your head.

Once you understand it, it's very, very powerful. I would do a basic closure implementation. You know closure, it's a list form of JVM -- very, very cool. I used a Git implementation, very quick, just read some repository writes. Of course, you writes some files. It's really not bad. I've got pages of code,

It's a great way to learn a new language if you're trying something out. It's a great little [indecipherable 00:31:26] to internalize Git. As I say, once you internalize Git, Git becomes more, a very, very natural way to work, and you realize the full power of it.

Tim: Oh, yeah. I absolutely agree with that. There's one of those light bulbs that go on after you've been working through with Git for a little while. Then you read an article about the DAG, or the Directed Acyclic Graph, that is kind of the core of the Git data model, and you're like, "Oh my God! Everything makes sense."

All these commands you've been using for so long and of struggling with it, like your Git reset, Git rebase, Git cherry-pick, all of those can be described as operations on that DAG, which makes everything a lot easier.

I've just posted a couple of articles. There's one called "Git for Computer Scientists," which I really recommend and another one from Scott Chacon's book, "Pro Git," which he's just written a new release of. He's got a great section on Git Internals, which talks about Git from the plumbing layer, all the way up to the porcelain layer.

It explains how those everyday commands you're using with Git actually operate. If you haven't read those yet, it'll take you a couple of hours and it'll change the way that you use Git as a version control system and make your experience much more pleasurable.

Nicola: If you guys are interested, I don't know what you guys think. If you've got questions, I could share the slides of this five-minute deep dive into data structures.
Participants: That's a great idea, yeah, absolutely.

[crosstalk]

Nicola: Let's do it. I will try to share the screen.

This is one of the slides we've been sharing during the Getting Git Right Tour. If you just memorize this, you will get the easy understanding of some of the low-level concepts of Git. I don't know how you guys want to do it.

Can you guys see my command line now? When you initialize a Git repository, Git basically generates a couple of empty folders. If you start adding a text file to the index, ready to be committed, what Git compresses the file, generates a unique ID for it. It uses the first two letters of the generated the SHA-1 cryptographic hash as a folder, so that you can spread the files across multiple folders. And that's it.

It's compressed, gives it a unique ID, and then done. Once you then commit this change to your repository, you end up having three objects. One is the blob that represents the piece of content you just added. The other data structure is the tree, which represents the content of a folder with all its pieces of content. It's a recursive data structure, so its tree can point to other trees. In the end, the commit object points to a tree object. It's very basic, very simple, but this simplicity actually allows for great power.

If you go back to the chart I was showing you, you'll see that there's a Git indexes content. It doesn't really track files, even though it stores the file names as a metadata in the tree object. That's not the core. Git actually handles blobs of content, tracks blobs of content.

The way the history is preserved is by chaining commits. Every commit object has a reference to its parent, and this is how Git creates this chain of commits. This is a very simple concept. You get all the flexibility and the power of Git. Maybe I'll stop here.

I'll show you a few more things. That's a very quick high-level description of...

Grace: Git as you know is a very powerful tool, as Nicola was talking about. That same powerful tool can also rapidly get someone into trouble. Can we talk a little bit about what you guys have been hearing about the biggest issues, in terms of adoption, barriers to entry for actually picking up Git in an organization, and what you guys would recommend in terms of overcoming some of those challenges?
Nicola: There's one thing, I don't know if you guys [indecipherable 00:35:48] , you can interject. I'll tell you a story of a guy who came to me in Helsinki.

He said, "We were convinced. We read a lot about Git. We decided to completely go with a new project using Git. It's a big eight-person team, we didn't know Git at all, and we started using it. We were using Subversion before. We had a terrible time. Nothing worked. We spent hours trying to understand why things weren't working. The history was always corrupted."

What they ended up doing is one of the recommendations that we give, but they had to struggle a month before they went back. They went back using Git as a Subversion, using rebase and just a single branch master. If you use rebases and a single master branch, you basically replicate more or less how you have been working for many years maybe with Subversion.

That's a reasonable first step to get everyone on a new platform and trying to understand all the new concepts, the new metaphors. Unfortunately, these guys tried to jump head on into full Git-distributed workflows and feature branch development. If you don't train your team, and if you don't have somebody who can act as a champion for this transition, you might run into trouble, because the concepts are fairly different.

My recommendation to these guys and to people that are maybe in the face of [indecipherable 00:37:20] Git is start slow and make sure you have a champion or somebody who's a bit more familiar with Git at the start. Maybe hold some brown bags or some tutorials. Create a cheat sheet for simple commands and simple workflows of update, commit, through the application.

Then, after a while, when people are acquainted with the simple procedure, you can start to adopt the other core practices of distributed version control, that is, feature branching, code reviews, and pull requests. If you give it a span of a few months, you will be able to, step by step, adopt all the policies, all the workflows, and then you will not go back afterwards.

[laughter]

Nicola: In our experience, once the transition was made, even though there might be difficulties and some resistance at the beginning, no developer wants to go back after a few months once the power of feature branching...that's one thing.
Tim: Absolutely. That's something that we were thrown into a little while ago at Atlassian. Atlassian -- shock, horror -- used to office version hosting as a product, as part of our JIRA OnDemand Suite. We decided after a little while that that wasn't the best business model in the world. Subversion was on decline, and hosting Subversion repositories is a pretty painful business.

We ended up migrating all of our customers. We gave them an option. They could migrate to Bitbucket, they could migrate to Git hosting locally in their own organization, or they could migrate to hosting Subversion locally in their own organization.

We gave them three options, but almost everybody took the opportunity to migrate to Git. As part of that, we had to ramp up our Git migration expertise. A lot of the patterns that Nicola was just talking about, we've actually documented on our Git macro site.

I've just posted a link in the chat. If you go to Atlassian.com/Git and have a look at the migration section, we've taken all of the patterns, tools, and scripts that we used to migrate all of those customers, codified them so they're easy to consume, and then I put them on our site.

If you're one of those not few people -- there are still significant number of Subversion users out there -- using Subversion and you're thinking of migrating to Git, I'd definitely check it out.

Grace: One thing I often hear when we're out at shows and events is there are developers that start playing around with Git, and they fell in love with it right away, which is fantastic. But, they're a real large organization, and they've got higher-level executives or managers they've got to convince.

What are the top things you would want to empower that developer with, so they can easily have that conversation with those leaders, get them to consider adopting Git in the organization?

Steve: One thing that worked very strongly inside Atlassian was that we started using Git SVN. Git SVN basically acts as a gateway. It will go out to your Subversion repository, pull it down, and you can then work in a Git workflow, locally. Only when you would normally do to commit to Subversion, [indecipherable 00:40:33] get pushed up to Subversion [indecipherable 00:40:33] repository.

You get a lot of the advantages of the rebasing capabilities -- commits and workflows that clean up your history, and only then push that up. As a developer, that requires no special permissions from anyone. This is how we rolled out Git internally for many people.

We start using Git SVN. People learned how to use Git natively, without actually having to modify your core infrastructure, or even your core workflows. You could actually get your feet wet without diving into deep end. Then, when the migration did come, it made life a lot easier. The developers had a bit more of a conceptual model and they knew the commands.

You try and jump from a pure Subversion workflow, as Nicola mentioned, straight into a pure Git workflow with all features, you're probably going to have some confusion. But, if you've been dabbling around the edges in a safe environment, getting [indecipherable 00:41:31] launches of Git but not necessarily having to go all the way in, you'll find adoption occurs organically inside the company.

At that point, you can say, "Well, people are actually already using this. They already understand it. We can now start some test migrations with a little bit more confidence."

Nicola: In addition to that, which is a very nice, very smooth way to transition, our take is that adopting Git has a big economic advantage for companies, for software things, because it allows you to release software faster and with higher quality.

The main reason for it is that you can split up new developments in isolated branches, and only merge those changes back when they're done, tested, and reviewed. That means that your stable lines of code, your production branches, stay stable. You get less performance, less production issues. You allow developers to work in parallel, in isolation, without downtime much more. This creates a speed of development that is very, very measurable.

Those are just a couple of things that also make sense economically from the budget perspective. Adopting Git means you're shipping software faster and the quality is higher. That's what we're trying to say when we try to convince management to migrate to Git.

Tim: Absolutely. One of our other Atlassians, a relatively famous Atlassian, Sven Peters, who does a lot of traveling and speaking about development workflows and the way we do development at Atlassian, ran a couple of surveys at some Java conferences last year. It was JavaZone in Norway, September 2013 and Devoxx in Belgium in November 2013.

He asked a whole bunch of questions about the workflows and Git adoption. He came back with some interesting, quantitative results that suggest that Git is going to rapidly improve, dramatically, the way that you do development at your organization.

I might just share my screen quickly. I've got some slides from a presentation I did at the summit last year, which illustrate that quite nicely. What we're looking at here is a graph of Git versus centralized version control, versus release speed.

What's really interesting to see here is that teams that release very rapidly, people who are releasing their software everyday -- likely SAS teams, where they're doing a deploy to a service that they host on the Internet -- are rapidly moving towards Git. This is probably because of the stability you can get in your release process if you use feature branching in Git, and just for the speed of the tool itself.

This is probably a little bit unrelated. Well, it is related to Git adoption, because we're really talking about pull requests. Another interesting finding here was that teams implementing code review actually release faster, as well.

The reason I think this is a super interesting result is because quite often one of the reasons people don't adopt code review is because they think it's going to take too much time from the development team. This is actually a counterintuitive result, because we can see that people who're using code review, which is a process that takes a non-zero amount of time are actually releasing faster.

Again, I suspect this is SAS services, who need to make sure that when they do a release the services are going to stay up. The fact that they have other people improving the quality of their code by doing code review -- probably it's lightweight code review through pull requests -- means that they've chosen to adopt code review.

The results of that survey are something we're going to be writing up in the near future and publishing. Stay tuned for that.

Grace: We're almost out of time here. I want to thank my co-hosts, or I'll say ta, in none of the local vernacular here, for helping and writing some great tips on Git.

Thank you to the audience for joining us. We'll be posting the recording of this shortly. Have a great week and g'day from Sydney.

Nicola: Good day.

[laughter]

Grace: G'day!