ultimate git workflow - seoul 2015

NOTES:

This file is set to a 16:9 aspect ratio, which works for Summit Preview Day, Training Day, and Summits Session Talks.

Make sure youve downloaded and loaded the fonts, which should have come with this presentation file. The fonts are: Helvetica Neue

Some page template will have notes with instructions to the right of the art board.

You shouldve also received an Assets file with icons and graphic assets and color palette. Updated meeple avatar graphics are coming soon.

This deck has been made slightly darker than average because the projector will lighten everything by 10 or 15% and add a little extra contrast. If you create new assets, keep this in mind.This presentation deck is designed as a canvas for you to craft your stories.

The best presentations are focused on connecting to the audience by enhancing and punctuating your stories rather than describing it with text.

With this in mind, the presentation template is filled with slides for using images, videos, screenshots, and large punchy text.

While we did include a few slides with small text and bullets we hope you only use those sparingly when necessary and avoid creating SLOCUMENTS (noun: the combination of document style prose on a presentation slide).Slocuments force your audience to multi-task by reading and listening at the same time this typically results in a drop in engagement.

Go on and create the best presentation of your lives!Read me

Tim Pettersen Developer Provocateur Atlassian @kannonboyThe business case for GitSoftware-as-a-Service EditionThe ultimate workflow

NOTES:

Your main title goes in the large blue font.

If you have a title that naturally splits into a subtitle, use the smaller green font for the subtitle. If not, delete the subtitle

PHOTO

1. Place your photo at around the same size as the example photo

2. (Keynote users:) Move your photo onto the blue shape below Select both photo and shape and then choose Mask with selected shape from the menu. Double click the photo to edit the scale and crop position.

Tim Pettersen, Developer Provocateurusing a different VCS, but thinking about moving to git using git, but feel like you dont have an optimal workflowjust like talks about git and workflowsThough the focus of this talk is SaaS, most of the talk applies to general development workflows, so you dont have to be a SaaS developer to get something out of it.

The business case for GitSoftware-as-a-Service EditionThe ultimate workflow

NOTES:



PHOTO



who here knows what a version control system is?who has used git?Youre in the right place if youre using git, but feel like you dont have an optimal workflowjust like talks about git and workflowsThough the focus of this talk is SaaS, most of the talk applies to git and general development workflows, so you dont have to be a SaaS developer to get something out of it.

The business case for GitThe ultimate workflow

Tim Pettersen Developer Provocateur Atlassian @kannonboy

NOTES:



PHOTO



Welcome to the Ultimate Git Workflow. Today I will be showing you the techniques that we have developed at Atlassian to work with Git.

How many people here are currently using Git?Subversion? Hg?


NOTES:

If you want to divide your talk into chapters, use this slide for Chapter titles

Welcome to Getting Git Right.

Great to see so many people excited about learning Git.

Tim PettersenDeveloper Provocateur@kannonboy

NOTES:


Im a developer provocateur from Atlassian.

NOTES:


Why am I here talking about Git? Because Im one of the two developers who started Stash at Atlassian. So I spent a good two years of my life as a core developer on our Git hosting product and another 18 months speaking and blogging about Git and Git workflows. I wont be talking too much about Stash during this session, but feel free to ask me about it in the questions :)Any Stash users in the Audience?

Who knows?

NOTES:


Who here has heard of Atlassian?

Facts

800+ Developers

NOTES:


For those of you who dont know much about Atlassian, we have an engineering team that is over 800 developers. We specialize in Java, Python and web technologies like HTML5, CSS and Javascript. We have a fairly hefty contingent of mobile and desktop application specialists too.

1800+ Nerds

Facts

NOTES:


These 800 developers are part of a global team of 1800 software nerds. Including supporters, product managers, designers and business types.

working on 9+ products

Facts

NOTES:


We have 9 core products, all focused on making life better for developers and software development teams.

Every team now uses Git for version control.

Tools

happy developers &productive teams

Ship software faster & smarter

Atlassians tools are designed to make software development teams collaborate and develop software more effectively.

Collaborate transparentlyCommunicate effectivelyDevelop and work asynchronously, in a way that fits your team

Our mission is to make developers happier and development teams more productive. We use all of our tools internally and are continually improving them to let us ship software to you, faster and smarter. Which hopefully lets you ship software to your customers, faster and smarter.

Ship software faster & smarter

happy developers &productive teams

Which is also why we love Git. Weve found that Git is a tool that not only makes us happier and more productive as individual developers, but also more productive and efficient as a software team. Git has let us redesign our development workflows and has dramatically improved the way that we develop and ship software.

WHY GIT?THE ULTIMATE WORKFLOWPULL REQUESTSINTERMISSIONThe ultimate workflow

MERGE STRATEGIESCONTINUOUS INTEGRATIONCOLLABORATION MODELSWHY STASH?

NOTES:

If its important for the audience to remember where they are in the chapter sequence and see forward / backward, use this slide for chapter titles. Move the white lozenge style to whichever section youre introducing

Collaboration models If we have time left.

WHY GIT?THE ULTIMATE WORKFLOWPULL REQUESTSINTERMISSIONMERGE STRATEGIESCONTINUOUS INTEGRATION

COLLABORATION MODELS

NOTES:

If its important for the audience to remember where they are in the chapter sequence and see forward / backward, use this slide for chapter titles. Move the white lozenge style to whichever section youre introducing

CI If we get time. The activity well be running during the intermission is of variable length.

Why?

NOTES:


version control sensation thats sweeping the nationDevelopers love:* speed* offline* distributed - good collaboration* created by Linus Torvalds, the dude who wrote Linux

VCS marketshare 2015Source: Black Duck https://www.openhub.net/repositories/compare

9%47%38%

2%

NOTES:


And theres a certain peer pressure aspect to using Git too. When you look at the statistics,

Though Mercurial is a pretty great version control system.

VCS trends (since 2010)

-16%-13%+27%+0.75%

Source: Red Monk http://redmonk.com/sogrady/2013/12/19/dvcs-and-git-2013/

NOTES:


Source: Atlassian Git Survey 2013release speed: git vs centralized

NOTES:


One of the reasons these companies are adopting Git is because it speeds up their time to release. More on this later.

1000 participants at JavaZone in Norway (September 2013) & Devoxx in Belgium (November 2013)13% of git users shipped daily3% of SVN27% weekly git18% weekly SVN

Speed, speed, Speed

Git doesnt just speed up releases, its also blazingly fast to use. Gits speed is one of the reasons why developers love it so much. It is an entirely different experience to using something like subversion - commands return instantly and branches that have been active for months are merged in the blink of an eye.

Summary:You have to experience this!Git doesnt get in your wayGit doesnt have to talk to a server (Dont elaborate much yet)VCS speed changes your behaviorGit is fast, even with Linuxs 15M LOC

Full text:So speed then. Git is well know for it and you have to experience it to true understand the importance of this.

What I mean by that is that it doesn;t get in your way. Gone are the days where you had to wait a minute to svn-checkout a different revision and wait for everything todownload from the server. Or wait for anything you ask svn while it goes back to the server.

Slowness gets in your way and it changes your behavior. You avoid doing things. You avoid switching back and forth between revisions and thats bad.

Even on huge code bases like the 17 million lines of code in the Linux kernel, Git is incredibly fast and rarely will you be able to even blink before a command returns.

Everything is local

Summary:First trick: Everything is localYour copy is identical to the serverIn centralized system, almost every operation needs networkFAST!

Full text:The biggest trick behind all this is that in Git everything happens locally.

In Git you always get a full copy o the entire history of the project onto your local machine. What you have locally is identical to whats on the server. So Git never has to reach out over the network to talk to a central server the way svn and cvs do.

Everything the server can do, your local machine can do and that makes a real difference. Svn really suffers from this centralized design where almost everycommand needs to go out over the network and that is immediately noticeable.

Yes, means you can work on the plane, but just the extra speed is the biggest win.

Author (A) - Written in C by Linux kernel and filesystem developers

Summary:Second trick: well written software!Linus himselfMaintained by exceptional hackersBitbuckets own occasional implementations cant match

Full Text:The other half of the secret is Gits own implementation. Git is almost entirely written in C by the people who also wrote the Linux kernel.

It was Linus Torvalds himself who wrote the first version of Git that had to be capable of handling the big code base of Linux and its since been maintained by likeminded and exceptionally skilled hackers. And as kernel devs, they know the tricks of the trade better than anyone.

I can attest to that by the way. Working on Bitbucket, we have on occasion needed to implement custom code that mimics functionality of a particular Git command.

Now we have some pretty smart people on the team that understand Git inside out, but weve never ever been able to match the efficiency and speed of native Git.

This is my proof, this is a chart that shows you how faster are operations done with Git compared in this case with subversion.

This result in Git operations are incredibly fast, even for code bases that are tens of millions of lines of code. This is my proof, this is a chart that shows you how faster are operations done with Git compared in case with subversion.

The charts are similar with other centralized version control systems.

But what if my repo is big?

446k lines of code added13The Linux kernel 3.13 release had 15+ million LOC1,339 contributors4

212,000 non-merge commitssource lwn.net

There is a myth that git doesnt scale to large repositories.

Summary:How does it scale? Linux is benchmarkSVN tendency to create one repo for everything

Full text:How does it scale? Pretty well actually and the Linux kernel again provides a bit of a benchmark. Few projects are as big and actively worked on as the kernel.Chances are your projects are well below these numbers.

Theres another thing that works in our favor here and that is that in distributed version control systems there is a strong tendency to put every individual project in its own repository. This in contrast to subversion where teams typically have a single repository that contains all the source code of completely independent projects and this makes Git much more scalable.

atlassian.com/git

Migrating soon?

Everything is available at our git site: atlassian.com/gitTutorials to assist your developers.Suggested workflows for different types of projects.Migration tools and strategies.Other git resources, including statistics and ammunition to make the business case to your managers that Git is not only good for developers, its good for business.

But what if my repo is big?

http://tinyurl.com/bigrepos

Great blog! How to handle big repositories with git

Plug Nicolas blog.

Also mention big binary file problem, and how nicola has some tips to address it.

The Ultimate WorkflowBranching

NOTES:


upcoming Release ?Can we still fix a bug for theFeatureIs the code for thatcomplete?

for the current version?HotfixHow do we do a

ReviewedHas everyonethe code for this feature ?

A good workflow should be able to direct a team of software developers on how to create and maintain a codebase. A great workflow should let you answer certain important questions about your codebase, at any point in time.

If I had to fix a bug today, where would I commit code to ensure it makes the next release?I can see that code has been committed for a feature, but how do I know if it is code complete?How do I fix a critical bug in already released code, and perform a maintenance release? And can I do this quickly?Once Ive fixed that critical bug, how do I know if its production ready; other developers have signed off on it, and its ready to release?

Git workflow?Whats the bestI dont know!

Id love to be able to tell you that theres a perfect workflow that will solve all of your problems. A one size fits all solution that will get your team up and running with git in no time.

The reality is more complicated. Different software teams have different requirements.

+ different teams+ different productsdifferent cultures= different workflows

Git workflow?Whats the best

Different companies have different cultures. Are you like a silicon valley startup, moving fast and breaking stuff? Let the users find the bugs and well get a hotfix deployed before they can refresh the page? Or are you more conservative? Do you work banking, or finance, or biotech, where a single bug could cost millions, or even patients lives.

What kind of product do you work on? Is it a mobile or desktop application? Or a monolithic SaaS app? Do you maintain multiple versions or do you force users to upgrade with each release?

How big is your team? Are you a solo developer, or are you a large group? Are you a single rockstar developer backed up by external contractors? Do you let tech writers and designers commit to your codebase?

All of these factors contribute to the workflow that will be most effective for your team.

DesignWorkflowsyour own

Fortunately, Git is flexible enough to cater for any workflow that you can dream up.

Im not going to prescribe a particular workflow, but I will show you some of the elements that comprise an efficient workflow, and show you a couple of the workflows that weve adopted at Atlassian.

IssuesCode

There are two fundamental components to a software project, a set of issues that need to be implemented. And the code that implements the features described in those issues.

JIRA-456

JIRA-123

JIRA-123

JIRA-456

IssuesCode

If youre using Subversion and have a traditional linear workflow for your repository, youre just creating new commits one on top of the other in a line. In SVN parlance, this series of commits is known as the trunk of your repository.

This linear approach can make it hard to tell what state the code is in. You might be able to tell that a developer has started work on a particular issue but its difficult to tell whether it is feature complete or if they have more changes to commit.

BrokenBuildsEverybody is affected

Photo: Resolute

NOTES:

Photos that fill up the entire screen have a great visual impact.

commit interleaving:if someone breaks the build, everyone has to stop committingthis is stressful and embarrassing for the developer, huge audience watching you fix something. when I last worked with SVN we had a red fire wardens hat you had to wear until you fixed it. *** PUT ON THE HAT ***also means everyone has to stop work until it

Code freezes suck

Photo: LA (Phot) Kelly Whybrow / MODCodeFreeze

NOTES:


broken builds mean you have to go into a code freeze. code freeze means you stop committing code and generally become unproductivewith a broken build, the code freeze is lifted when the unfortunate developer fixes the build

JIRA-456

JIRA-123Linear workflow

Commit interleaving causes another problem.

Cant be released right now

Half-bakedFeatures

NOTES:


commit interleaving: hard to tell whether a particular feature is finishedhard to release, have to ask developers whether each feature is ready to ship

Code freezes suck

Photo: LA (Phot) Kelly Whybrow / MODCodeFreeze

Photo: Jason AuchCodeFreeze

Idle developerAnother

NOTES:


performing means you have to go into another code freeze. with a release, the code freeze can take days while the release manager (often a developer) runs around asking everyone if their features are ready

JIRA-456

JIRA-123Linear workflow

So there has to be a better way, right?

feature/JIRA-123

stable master branch

isolated feature work

masterBranching workflow

Git feature branches take care of this problem nicely. The trunk branch in git is usually called master. Instead of committing straight to master all development work is done on an independent branch. Once the code is finished, reviewed and all the tests are passing it gets merged into master. This keeps unstable changes isolated from the master branch. This means if I break the build on my branch - Im not blocking other developers. No more red hat of shame! *** REMOVE HAT ***And has the nice side effect that master only contains code that is ready to ship, so it is _always_ releasable.

feature/JIRA-30-user-avatars branch type

issue key

description

Branch per issue

Branch type: feature, bugfix or hot fix(Hotfix is for already released code that we need to release and deploy quickly)Issue keyShort description of issueGood convention - allows a developer to quickly see what issue a branch addresses on the command line or in other tools, like Stash

bugfix/JIRA-31-oauth-npe branch type

issue key

description

Branch per issue


hotfix/JIRA-32-wtf-ie8-srsly branch type

issue key

description

Branch per issue


perBranch all the thingsBranchfeaturebugdoc change

The technique we use at Atlassian is to create a new branch for every piece of work that we do.

Why branch? Isolation

Stability Traceability

We love feature branching because they provide:isolation: a developer is free to experiment on their own branchstability: the master branch remains stable and can be used for releases, and to create new feature branchestraceability: knowing that all of the work done on a branch relates to a single feature lets you think about your codebase in terms of FEATURES.

Traceability Whats shipping? git branch --merged git branch --no-merged Whats left to do?

If you use feature branching, you can easily determine which features will ship in the next release by using the merged and no-merged flags with the git branch command.

Why not

?


Atlassian BitbucketWorkflowSaaS Workflow

NOTES:


Lets take a look at the first workflow I want to show you today. Workflow that Atlassian uses to develop Bitbucket. Bitbucket is a SaaS application, that is, we run Bitbucket on our own servers - we dont ship the application code to our customers. If you also have a software-as-a-service model this workflow may work for you.

feature/JIRA-123

masterIntegration Failures

feature/JIRA-456

stable master branch

Un

But working in isolation means you can run into integration problems with your branches.

Two branches that work independently, may have problems when they are merged together.

And again, weve broken the build and caused a code freeze - on with the hat! *** DON HAT ***

develop

master

feature/JIRA-123

Integration Failures

feature/JIRA-456

To ensure master is always stable, we can introduce an integration branch where the tests must pass before we merge it to master. We often call this branch develop.

This guarantees master remains green - so developers can always create their feature branches from master. This means were no longer blocked by a red build on master - so no code freeze!

develop

master

feature/JIRA-123

Integration Failures

feature/JIRA-456

Continuously deployedto Staging

Continuously deployed to Production

This also lets us do continuous deployment to our staging and production environments. The develop branch is continuously deployed to our Staging environment.

Then, when were ready to push to production, we merge develop into master.

develop

master

Hotfixes

Usually, we create feature branches off develop. Sometimes if something breaks in production, we need to get a fix deployed as quickly as possible.

In this case we create a hotfix branch.

develop

master

Hotfixes

develop

Hotfixes

hotfix/JIRA-1911

master

Once the branch is ready, we merge it to develop first for testing.If the fix is successful, we then merge it directly into master for deployment to production.

We cant merge develop into master at this point, because it has some work that we dont want to ship to production just yet.

Atlassian StashWorkflowMobile, desktop &on-premise serversoftware

NOTES:


Used by the Atlassian Stash team.Unlike Bitbucket, it is software that is shipped to the customer and installed by them on their server.Unlike Bitbucket, we support multiple stable versions of Stash, so the software-as-service workflow no longer works. So we need a different workflow.

Multiple Product Versions

feature/JIRA-30

master

v 1.2

v 1.1

NOTES:


Say were the Stash team and were about to release Stash version 1.2. Towards the end of the release cycle well create a branch named 1.2 which will contain all of the code that we intend to release. Creating a branch like this means we can start testing and hardening the code for the 1.2 release. Developers who are hardening the code merge their branches into 1.2, while developers who are working on features for a future release of Stash can merge their branches into master, without effecting the stability of the 1.2 release.

master

v 1.2

v 1.1

bugfix/JIRA-41


NOTES:


But what happens if we find a critical bug after weve released 1.2? First we create a bugfix branch off our stable 1.2 branch.

master

v 1.2

v 1.1

bugfix/JIRA-41


NOTES:


Then we fix the bug. Once weve the code has been reviewed and our CI tests are passing, we merge the bugfix branch back into 1.2. Now we can release version 1.2.1 and get it out to our customers.

master

v 1.2

v 1.1

bugfix/JIRA-41


NOTES:


Then we fix the bug. Once weve the code has been reviewed and our CI tests are passing, we merge the bugfix branch back into 1.2. Now we can release version 1.2.1 and get it out to our customers.

But were not finished, we also have to merge our stable 1.2 branch (which also contains our fix) into master. This ensures that future releases will also contain our bugfix.

master

v 1.2

v 1.1

bugfix/JIRA-45


NOTES:


But what if we found a bug in an even earlier version of Stash? Its much the same process, but we create our bugfix branch off the earliest version that we want to introduce the fix in. In this case, its 1.1.

master

v 1.2

v 1.1

bugfix/JIRA-45


NOTES:


Then we merge it all the way forward to our master branch. This means that the next 1.1.x version, the next 1.2.x version and the next major release will all have our code changes in it.

You can repeat this for as many stable branches as you want to maintain.

master

v 1.2

v 1.1

bugfix/JIRA-45


NOTES:




master

v 1.2

v 1.1

bugfix/JIRA-45


NOTES:




master

v 1.2

v 1.1

bugfix/JIRA-45

boring work


NOTES:


One problem with this workflow is that the forward merging is tedious and (like most tedious activities that humans are forced to do) prone to human error.

So we decided to automate this in Stash.

Automatic mergeshttps://bitbucket.org/durdn/automatic-merge-hook

with a Git hook

NOTES:


The first method is with a git hook. You can think of git hooks as gits plugin system. They can be used to trigger behavior when certain changes happen to your repository, either on the client or on the server.

One of our developers has written a server-side update hook that will forward merge branches for you, according to an ordered list of branches.

Automatic merges

with Stash

NOTES:


Alternatively if youre using Stash, it has forward merging baked right into it. Provided you use semantic versioning, Stash will automatically detect and suggest forward merges when you attempt to merge a Pull Request.

Merge Strategies

So Ive talked a lot about branching. Lets look at the different ways you can merge those branches together.

What is a merge?

Merge commitdevelopfeaturemerges keep the context of the features commits

A merge occurs when you weve been working on a branch for a while and you get to the point where you feature is finished and its ready to get applied to the mainbranch, the stable version of your project. This process is merging and it leads to a new commit being created on the main branch that unifies the changes from bothsides.

git knows the ancestry12The merge is localpowerful merge strategies3merge is better in git

Summary:Merging is important for all VCSesShould not be avoided. Branching makes teams productive.Git branching > SVN brachingSVN braching is cheap, merging is notExplain points on slide

Full text:The ability for a version control system to perform merges is incredible important. After all, for every branch you create, you end up having to perform a merge. And that is not something you should avoid. Branching makes teams much more productive.

Its often said that gits merging implementation is better than that of other version control systems and is certainly true for svn. The comparison with svn is kind ofinteresting.

Svn has always claimed branching as one of its core strengths. Branching is cheap it claims. And it is. But if you cant merge just as easily, then its just not as interesting.

So lets touch on a few reasons why Git is better.

First off, like almost everything else, merging is a local operation and does not require communication with a server. Which makes it substantially faster than centralized systems, especially on larger repositories.

Secondly, Git has access to the entire history of the branches it needs to merge and it uses that to figure out at what point the branches start diverging. The common ancestor commit. Using just these three pieces of information it can work out what happened on each branch and therefor how to combine them. 3 way?

Its important to realize that Git does not replay the commits on the feature branch against the main branch. It doesnt even look at the contents of any commit other than the latest and so even merging very old and active branches is very fast.

Now there is no guarantee that everything can always be merged automatically and depending on what happened to both branches, there can still be merge conflicts that require manual intervention. However here Git has another trick up its sleeve. Changes that appear to be conflicting at first sight, can sometimes be resolved by looking carefully at the ancestry and a series of fairly complex merging algorithms have been developed over time. Git takes advantage of this by making its merging algorithms pluggable and so over time it has become even better at merging.

merge? no worries

The result of all this is that in most cases, merges become so simple that you forget theyre even happening. In fact, most of the time, Git will merge fully automatically for you and so aside from the automated commits that appear in the timeline, youd never even realize they were occurring.

git rebase: Rewrite history safely

Now lets look at a slightly more advanced way to combine branches together: a command thats unique to Git called the rebase.

featuredevelopWhat is a rebase?

Its a way to replay commits, one by one, on top of a branch

Summary:Explain scenario with pulls from upstream branchExplain rebasing solution with manual patches

Full text:Rebasing can be a little hard to understand at first and Im going to try to explain it using a common scenario.

Imagine youre working on a long lived feature branch. It contains days or weeks worth of commits, but youre not ready to merge it just yet. Its not finished. In themeantime, development on master also continued and you want to use those changes. Maybe a bug has been fixed and you need that fix on your branch.

So far weve talked about merging feature branches into the main branch, but our branch isnt finished yet. Now instead we can do the reverse. We can merge the main branch into our feature branch! Note that this does not affect the main branch. It stays where it is. We just pull its changes into our branch. This creates an automated merge commit on our branch. We then continue development.

After doing this a few times, we see a pattern of normal commits, interleaved by merge commits. Thats no big deal, except that if we want to see everything we did on our branch since its creation, we see not only our own work, but also that which was pulled in from master. Work that is completely unrelated to our feature.

Rebasing addresses this problem. Say were at the point where we need to pull in master. Imagine we would export the work we did on our branch as a patch. Just a file we store on the side for a while. We then delete our commits and the branch. Next, we go to the tip of the master branch and we create a new branch off of it. Then we apply our patch file onto the new branch. This restores our work, but now its based off of the current version of master. And we didnt need to create a merge commit.

This is essentially what git does when you rebase. It automates what would otherwise have been a huge amount of manual labor.

developfeatureWhat is a rebase?

preserving the order of commits

Summary:Rebase to avoid merging feature branch into master

Full text:You can also do this when you are ready to merge your branch into master. Instead of letting Git create a merge commit, you can instead tell it rebase all your featurecommits directly onto the master branch. Replaying them one by one as it were.

This way you can effectively merge your changes in without creating any actual merge commits.

What is an--interactive rebase?Its a way to replay commits, one by one, deciding interactively what to do with eachrewordfixuppicksquashedit exec

pick: leaves a commit intactreword: lets you change a commit messageedit: pauses the rebase process and lets you change the code in the commitsquash: combines multiple commits into a single commit, and concatenates the commit messages togetherfixup: is the same as squash, but just uses the latest message instead of combining themexec: lets you run shell commands in between rebase commands. One common use case is to use it to run tests to make sure you didnt break anything during the rebase!

CUSTOMARY WARNING!rebase rewrites history!Treat this power with great care. Only rewrite history of local branches or

Speaking of breaking things. Whenever I talk about a rebase, I need to give you a customary warning. Rebase rewrites the history of your code base. You should only use it carefully and on branches that you haven't shared with anybody.

Rewriting history

master

alice/master

bob/master

Original AND rewritten commit are now in history!

If you rewrite public history in git, you can end up with the same commit multiple times in your history. Or you can end up with changes that you thought you deleted re-applied when somebody else pushes.

Say the last commit on master is a shiny new postgres adapter that Bob has written to use postgres in the app. Say Bob decides that he wants the app to use mysql instead. Instead of creating a new commit, he replaces the postgres commit by rewriting it thinking that no-one would ever find it useful. When Alice pulls, shell be prompted to merge, and well end up with two different database adapter implementations in the code base!

DONT REWRITE PUBLISHED HISTORY

(dont push --force to a shared branch)

So remember, dont rewrite history on shared branches!

feature/JIRA-123

masterMerge Commit

Now you know what a merge commit and a rebase are, so lets look at three popular ways to move changes between branches.

Theres a traditional merge commit - creates a commit with two parents.

feature/JIRA-123

masterRebase (Fast-forward)

You can rebase on to master, where you recreate the commits of your branch on top of your master branch.

We dont like this at Atlassian because you lose information about whether features were originally developed on isolated branches.

feature/JIRA-123

masterRebase (Squash)

And then theres the squash, where you rewrite all the changes on your branch as a single commit on top of master.

We dont like this because you lose interstitial information about your history - and sometimes miss the subtle development of a bug.

Merge CommitRebase (FF)Rebase (Squash)No merge commitsVerbose historyEasy to readCan be more difficultto trace changesWhich should I use?Ugly historyFull traceabilityHard to screw up

mostly

some

In summary..

Intermission!

https://extranet.atlassian.com/display/[email protected]/Questions+for+Business+case+for+git+intermezzo

Trivia!

If I rebase my branch on to master, a merge commit is created.TrueFalse

Is the git server is down a valid excuse for developers to engage in a sword fight?FalseTrue

Which hashing algorithm does git use for generating commit IDs?SHA-1MD5

What is a SourceTree?a git GUItoolthe root dir of a git repo

If you combine the original names of the products JIRA Agile and JIRA Capture what would you have?GreenFireBlueHopper

What was the internal Atlassian codename for Stash?Caviar, child of FishEyeForge, child of Crucible

The git checkout command can be used to check out an existing branch.TrueFalse

The git checkout command can be used to create a new branch.TrueFalse

The git checkout command can be used to check out a file.TrueFalse

And Git is supposed to follow the unix philosophy of individual commands that do "one thing well"..

The git checkout command can be used to create a new tag.FalseTrue

What is the purpose of the .gitignore file?ignore files with certain namesignore different line endings

It is impossible to store an empty directory in a git repository.TrueFalse

The git DAG (which stores refs, trees and blobs) stands for..Directed Acyclic GraphData Agnostic Graph

In git, what is a merge with more than two parents called?OctopusHydra

Creating a new branch from a 40 megabyte working copy will take how much disk space?40 bytes40 megabytes

What is a shallow clone?a clone with limited historya clone with no submodules

What is a bare clone?a clone with no working directorya clone with no branches or tags

The git 1.0.0 release was tagged in which year?20052006

At Wed Dec 21 00:01:00 apparently, which makes me think the timestamp was forged.

Which flag can you pass to the git merge command to make it try harder to detect moved segments within changed files?--patience--tolerance

The first git commit message by Linus Torvalds reads: Initial revision of gitthe information manager from hellbye-bye Bitkeeper

What was the internal Atlassian codename for Stash?Caviar, child of FishEyeForge, child of Crucible

What command is executed on a git server when you push changes over SSH?git-receive-packgit-upload-pack

It is possible to have more than one root commit in a git repository.TrueFalse

What hexadecimal character does the SHA of the root commit of the git project end with?01

TIE-BREAKER

What does this SHA refer to? 4b825dc642cb6eb9a060e54bf8d69288fbee4904an empty treean empty blob

n. kola taQuality

what does quality mean? its not a furry Australian marsupial drinking boiled leaves

quality code is code with: - low bugs - performant - low technical debt - easy to maintain

all sorts of things can help quality: testing, static analysis tools, code coverage reports, but I think the most important is..

CodeReview

NOTES:


Code Review!

How many people are doing code review?

Code review: why?Better code - this one is obviousTeach your co-workers - and learn from them Lower your bus factor - remove single points of failure

NOTES:


Sometimes developers avoid doing code review because they think it will slow them down. However, our research shows that teams who do code review actually release software faster!

Reviews and releasesSource: Atlassian Git Survey 2013

NOTES:


Sometimes developers avoid doing code review because they think it will slow them down. However, our research shows that teams who do code review actually release software faster!

Better Code

Shared Knowledge

TeamOwnership

NOTES:


Better code - different experience, different knowledge, different specializations

Shared knowledge - back on Crucible .., technologies specific to a stack, patterns specific to a team

Team ownership - has anyone here ever shipped a bug?

G = 1

R+1 Developer guilt

NOTES:


TeamOwnership

NOTES:


NOTES:


Code review

NOTES:


Pull requests

NOTES:


Pull requests

NOTES:


Pull requests

review before merging

NOTES:


Peer Review

You see your code. You see which lines got removed in red and which lines got added in green. Then you can add in-line comments and discuss the code.

10 tips for better pull requests

bit.ly/10-pr-tips

(from Mark Seemann a.k.a @ploeh)

1. make it small

bit.ly/10-pr-tips

2. do one thing4. avoid reformatting

Pull requests should be a lightweight process. If you make sure the pull request diff relates only to a single issue, it is easier for the reviewer to reason about why you have changed something.

Similarly, reformatting existing code is just noise - create a new pull request if you want to do this. Remember - do just one thing.

bit.ly/10-pr-tips

3. watch your line width

Git, like all other version control systems, outputs diff information by line by default. If you have really long lines, reviewers will spend a lot of time scrolling around in their browser.

5. make sure the code builds

bit.ly/10-pr-tips

6. make sure the tests pass7. add tests

Make sure your code works and is tested, before you create the pull request. Some teams will also use a code coverage tool to check that the %age of the codebase covered by tests doesnt drop on a feature branch. Stash actually helps you out here by displaying the build status of the commits inside the Stash UI.

8. document your reasoning

bit.ly/10-pr-tips

9. write wellobviouscodecodecommentscommitmessagePRcomments>>>

10. avoid thrashing

bit.ly/10-pr-tips

NOTES:


Marks 10th point is to avoid thrashing. Thrashing is where a reviewer doesnt like some of the work that youve done and asks you to remove it , and you create a new commit removing the work. You now have three extra commits that dont do anything useful! Instead you could consider using an interactive rebase to remove those commits.

But remember - dont do this on a shared branch.

11. avoid flamewarsPhoto: MANOJTV

NOTES:


But I have two

But theres also another form of thrashing thats good to avoid. Sometimes developers might disagree on the best way to implement something. Dont let your pull request comments look like youtube comments! As a general rule of thumb, if a comment thread gets deeper than 5 levels of comments, its time to try something else. Often talking to the person in real life will be a more efficient way to reach a resolution. At Atlassian we also sometimes respectfully resort to architects to have a final say when there is a contentious decision to be made.

12. set a team policy

NOTES:


One final tip is to make sure that you agree as a team how you want to approach pull requests.

We dont need Code Review we have continuous integration!WELL INTENTIONED (BUT INCORRECT) DEVELOPER

NOTES:

This can be used for quotations, testimonials, tweets, etc.

Move the quotation marks depending on your text length so that it appears like this example

Also move the name attribution depending on text lenth so that its like this example

Pull requests

NOTES:


Pull requests

human judgement needed?

what-evs

bad API decision

O(n!) algorithm

technical debt

NOTES:


Client-side hooks Server-side hooksContinuous IntegrationCode Reviewkola ta

So weve discussed many different aspects of software

AWARENESS

LEADSPROSPECTSSALES

NOTES:


AWARENESS

LEADSPROSPECTSSALES

NOTES:


Client-side hooks (checkstyle, lint, unit tests)Server-side hooks (you cant trust devs)Continuous Integration(too long to run locally)Code Review(last stop before prod)bugs your team writes

bugs that you ship

NOTES:


Client-side hooks (checkstyle, lint, unit tests)Server-side hooks (you cant trust devs)Continuous Integration(too long to run locally)Code Review(last stop before prod)$$$$$$$$$$

NOTES:


Photo: Steffen Heinz

NOTES:


http://commons.wikimedia.org/wiki/File:Bon_toutou.png

Continuous Integration

NOTES:


So now lets talk about how git can magically improve the quality of your code.

Building master & develop

develop

master

NOTES:


Weve talked about building master and develop

Comic: Randall Munroe http://xkcd.com/303/

NOTES:


branching also brings another advantage. in fact - this next thing has saved me literally weeks of time since we moved to git

Comic: Randall Munroe http://xkcd.com/303/Im running the tests

NOTES:


branching also brings another advantage. in fact - this next thing has saved me literally weeks of time since we moved to git

automatically triggered

Building branches

masteralways build master

NOTES:


The conventional wisdom for continuous integration is to always build your master branch, but as I mentioned earlier, we like to build feature branches too so we can make sure features are working before theyre merged into master.

Ideally, your CI server is configured to automatically detect when a new branch is pushed and build it.

NOTES:

The browser size can vary a bit, the idea is that it is always centered andruns off the bottom edge

Use Chrome browser

1 tab open, unless tabs help illustrate

Browser extensions & bookmarks bar is hidden

Is the branch green?

We also show the status of the commit you can create a branch from in the Stash UI.At first, developers are like creating branches on the server? Thats crazy! This little green tick means that the tip of branch you are creating a branch from is green. this is important, because it stops you from confounding build breakages

Confounding build breakages

master

NOTES:


imagine developer who is a little too cool for schoolcommits directly on master to fix a bug in your authentication systemaccidentally breaks a testno worries, commits a fix and the build is green again

Confounding build breakages

bugfix/JRA-1

master

NOTES:


but there is a problemimagine another developer comes in to fix a bug in the data access layer, and does the right thing and creates a branchtheir build will fail to, and its going to be a very surprising situation as its look like their change has somehow caused a problem with the authentication system, and theyll spend time debugging it

NOTES:

The browser size can vary a bit, the idea is that it is always centered andruns off the bottom edge

Use Chrome browser

1 tab open, unless tabs help illustrate

Browser extensions & bookmarks bar is hidden

Is the branch green?

the little green build indicator makes it hard to miss, eliminating this problem. another good reason to create branches on the server.

Git Hooks

NOTES:


So now lets talk about how git can magically improve the quality of your code.

.git/hooks

You can think of hooks as gits plugin system. They let you hook into certain git operations and customize the behavior of your repository. If you look in the .git directory of any git repository youll see a directory named hooks which contains a set of example hook scripts.

Build status post-checkout hook

http://bit.do/git-ci

NOTES:


but there is a problemimagine another developer comes in to fix a bug in the data access layer, and does the right thing and creates a branchtheir build will fail to, and its going to be a very surprising situation as its look like their change has somehow caused a problem with the authentication system, and theyll spend time debugging it

pre-*post-*server-sideclient-side

Notify chat room

Run lint / checkstyle

Is it safe to branch?Protect master

There are two broad classes of hooks, client-side and server-side. Client-side hooks run on your developers machines and server-side hooks run on your git server.

You can also categorize hooks as pre- or post- hooks. Pre-hooks are invoked before certain git operations, and have the option to cancel an operation if needed. Post-hooks on the other hand run after an operation has completed, and therefore dont have the option to cancel it.

For example, I have a post-checkout hook installed on my development machine that runs every time I checkout a branch. It calls out to my Bamboo server and checks to see whether the tip of the branch has a passing build or not. If it doesnt, it warns me that it is not safe to create a new branch from that point, as my new branch will presumably have the same test failures.

Another popular hook is the post-receive hook. Post-receive hooks are called when branches are updated on your git server. One popular use case for this kind of hook is notifications. Some teams at Atlassian use post-receive hooks to send notifications to their teams HipChat rooms when new branches are pushed to the server.

Pre-hooks are a very powerful type of hook, as they allow you to prevent certain operations from proceeding. The pre-commit hook is a hook that lets you intercept (and optionally prevent) a commit operation before it happens. One common use of the pre-commit hook is to check that your code passes automated style or lint rules before you create a commit. Since this type of automated check typically runs very quickly, its convenient to run it locally before you commit your changes. This prevents you from pushing a commit that will break the checkstyle or lint build.

Some operations are too expensive to run locally though. This is where the powerful server-side pre-receive hook comes in. Pre-receive hooks can be used to prevent developers from pushing code to your server, unless the code meets certain conditions. You can think of these hooks as elite ninja guardians, protecting the master branch from bad code.

Slide Title

build a fortress for master

There are many different techniques you can use with pre-receive hooks to protect your master.

One popular technique is to block merges unless the tip of the branch being merged in has a green build. By only allowing branches with green builds to be merged into master, we vastly improve our chances of keeping master green and stable too. When a developer attempts to push the merge commit to the git server, the pre-receive hook is executed and calls out to your CI server. If the CI server reports that the tip of the merged branch is broken, the push is rejected and the developer is notified that they will have to fix the build before merging.

A similar technique can be used for checking code coverage or check style violations. If your CI server generates coverage metrics as part of the build, you can use a pre-receive hook to check whether a particular commit increases or decreases your code coverage. If code coverage decreases, the update is rejected and the developer has to improve their test code and try again.

http://bit.do/git-ci

If youre interested in playing around with some of these hooks, checkout this link: bit.do/git-ci. Itll take you to a Bitbucket repository with some ruby hooks for enforcing check style, code coverage and green builds on your master branch.

Now Ill hand you back over to Sarah to wrap up.

Collaborate Photo: Photographer's Mate 3rd Class Eric S. Garstbetter

NOTES:


Working with contractors?

NOTES:


Circle of TrustPhoto: Aljaz Zajc

NOTES:


Strangers on the internetContractors

InternsOther product teamsSupport

Core dev teamCircle of Trust

NOTES:


Collaborating with SVN

Core dev teamEveryone else

emailing patchesrepository tarballshell-ish conflicts

NOTES:


Collaborating with forks

Everyone elseCore dev team

Changes automatically synchronizedownstream

.. but must be reviewed before moving upstream

NOTES:


feature/*Mentoring with branches

SeniordevelopersJuniordevelopers

master

NOTES:


Strangers on the internet

InternsOther product teamsSupport

Core dev team

Contractors

NOTES:


allows core development team control over what ships to your customersallows junior developers to work on the main repository while having their code reviewed by senior developersallows contractors to work on up to date forks of the repository using fork synchonization, which means no ugly conflicts for your development team to solve

Why?

NOTES:


version control sensation thats sweeping the nationDevelopers love:* speed* offline* created by Linus Torvalds, the dude who wrote LinuxTeams love it: * collaboration among distributed teams really easy * flexible branching model to get rid of code freezes and make releasing easy * light weight pull requests that ensures high quality code and smarter developers

Why?

NOTES:


Lets quickly talk about why you might want to use Stash to host your Git repositories.

CommitLog

But I do have some git credentials. If you look at the commit log for Atlassian Stash, you can see my name on the very first commit. Back in late 2011 myself and another developer built the very first spike of Stash during Atlassians quarterly ShipIt competition in the Sydney Atlassian office. I then spent a bit of time as a Stash team lead before relocating to San Francisco to join our developer relations team.

Why ? BEST enterprise Git workflow Integrations & extensibility Scalability

NOTES:


Three reasons why Im really proud of what weve built with the Stash project.

Git workflows for teamsExtensions& Integrations

Scalability

Why ?

NOTES:


Three reasons why Im really proud of what weve built with the Stash project.

Git workflow for teams

feature/STASH-123

master

ForkingBranchingvs

NOTES:


Forking: Each developer creates a copy of the main repository, pushes changes to it, and then creates a pull request between the two repositories.Branching: Each developer creates branches in the same repository and then creates pull requests between branches.

We prefer branching: simpler - developers dont have to configure multiple remotes, and you dont have to set up your continuous integration servers to watch multiple repositories. Also you have better visibility into what your team is doing from one place.

feature/STASH-123

masterGit workflow for teams

X reviewers approved? Y builds passed? All tasks complete?

NOTES:


Bitbucket and GitHub have good pull request implementationsOther products allow you to discuss changes that have been madeStash ALSO enforces that certain conditions are met.

feature/STASH-123

master

Git workflow for teamsPull request merge checksRepository hooksBranch permissions

NOTES:


Pull request merge checks allow you to enforce certain pre-conditions before a merge is allowed, including requiring green builds and a certain number of reviewers.

Repository hooks allow you to intercept code changes even earlier - when a developer pushes changes to the server! e.g. hip chat and CI server notifications, or preventing people from doing force pushes or pushing files of a certain type or size.

Branch permissions allow you to limit who can push to a particular branch. Great for contractors and interns!

feature/STASH-123

master

Git workflow for teamsPull request merge checksRepository hooksBranch permissionsFlexible &Extensible

NOTES:


Branch permissions can be configured by branch name or an ant glob pattern, allowing you to do funky things like enforcing naming conventions for your branches.Both merge checks and hooks are pluggable, so you can customize them to suit your workflow exactly!

Powerful integrations

NOTES:


Another reason to use Stash is its tight integration with the rest of the Atlassian stack. Weve shown you how you can view your Stash repo data in JIRA, and vice versa, and transition your issues based on your code. Weve also shown you how Stash can notify Bamboo and HipChat when developers push changes or work with Pull Requests.

Powerful integrations

NOTES:


But Stash also integrates with other tools that you may already by using!There are freely available community maintained plugins for Jenkins, TeamCity and plenty of other CI servers. Plus there are SVN mirroring plugins and migration tools if youre looking for a nice way to migrate smoothly.

Stash Platform

Branch Permissions

REST APIs

JIRA Integration

Plugin APIs

NOTES:


Full Java APIRepository HooksMerge ChecksUser InterfaceREST end-pointsFiletype renderersSSH commands

Stash Platform

Branch Permissions

REST APIs

JIRA Integration

Source?You betcha!Plugin APIs

NOTES:


The reason these plugins have evolved is because Stash has a comprehensive and open API!Full Java API - with full backwards compatibility and proper deprecation proceduresRepository Hooks & Merge Checks - as we discussed earlierPluggable User Interface - allowing you to inject your own HTML, CSS and Javascript into the Stash UIBuild your own REST end-points and SSH commands - to provide custom functionality & expose your data in interesting waysRich plugin points like Filetype renderers, that let you define customer source and diff views for the file types that you use, e.g. 3d models or proprietary formats

And what makes Stash really special is that weve built it as a platform first.

Many of the features that weve shown you today are actually built as plugins! This means that were coding against exactly the same API as external developers use, meaning its rock solid and battle-hardened when you come to do your own customization.

Plus, if you have a commercial license - even a $10 starter license - you get the source for free. So while were not exactly open source, you can audit what were doing if you want - and use it as inspiration for your own plugins.

Plugin APIsSource?You betcha!

Repository Hooks

Java API

Merge Checks

Web Fragments

REST Resources

Git Command Builders

Filetype Renderers

Custom SSH Commands

Stash Platform

Branch Permissions

REST APIs

JIRA Integration

NOTES:


(use previous slide instead?)

insert /rest/api/latestRESTful APIs

NOTES:


When we first started the Stash project, we had two teams. One was mainly front-end developers, and the other was mainly back-end. The contract between the two teams was the REST API. This means that Stash has a very strong mapping between its REST and Web UI. Almost all the functionality available in the UI is available via REST. In fact - all you need to do is insert /rest/api/latest at the front of a particular resource and bingo!

RESTful APIs

insert /rest/api/latest

NOTES:


.. you get the REST variant of that resource.

Scalability

Request throttling

NOTES:


The third reason Im proud of what weve done with Stash, is what weve done to improve its performance and scalability.

To ensure uptime, weve implemented a throttling system that limits the number of concurrent git commands that are invoked at any one time. There are separate limits for hosting operations - like clones, pushes and pulls - and operations that are used to populate the user interface.

This means that your developers will still be able to do pull requests while your CI servers are hammering the hosting APIs, and vice-versa.

The limits themselves are configurable - just like everything else in Stash. There are very few hardcoded constants - almost everything is configurable by your system administrator.

Request queuing

Scalability

NOTES:


Speaking of CI servers one thing we implemented fairly early on was a repository hook to notify CI servers when a branch was updated - this is much more efficient than having your CI servers poll the repository for changes. It did, however, mean that youd have a large number of incoming requests coming from CI servers whenever a change was pushed - sometimes pushing Stash over the throttling limit. This would occasionally result in rejected requests, which would cause the CI server to fail the build. So we implemented request queuing, which holds the request open for a short period of time, waiting to be allowed to proceed. This time is also configurable.

Response CachingScalability

NOTES:


Then we got even smarter about it. Because these CI servers are all typically requesting the same data - that is the same set of ref updates - we realized it was a pretty good candidate for caching. So now, when the first request comes in from a CI server, Stash spools the response out to disk whilst queuing up any other concurrent requests for the same objects. Then, subsequent requests are served off the cached file - which is much more efficient, and much less load on the server, meaning we can serve more requests!

Clustering

Scalability

NOTES:


But we still werent 100% happy, because even though it was much more efficient - there was still an upper bound to how many concurrent requests that a single Stash server could handle. So we decided to implement clustering. Stash is the only clusterable Git solution out there, and effectively means you can scale up your instance to support as many developers, CI servers and other clients as you like!

Git workflows for teamsExtensions& Integrations

Scalability

Why ?

NOTES:


So these are the three reasons we are super proud of what weve achieved with Stash. Quick recap on workflows; APIs, extensions & integrations; and scalability.

BIG thanks toyour local experts in Korea!

NOTES:


But we still werent 100% happy, because even though it was much more efficient - there was still an upper bound to how many concurrent requests that a single Stash server could handle. So we decided to implement clustering. Stash is the only clusterable Git solution out there, and effectively means you can scale up your instance to support as many developers, CI servers and other clients as you like!

All sorts of teams are on&

NOTES:


These features are why there are all sorts of teams using Git and Stash.

in the EnterpriseGit & Stash

These are not small companies - one of the common misconceptions about git is that it is only used by startups and open source projects. Not true! Huge enterprises are using Git.

These are not small companies - one of the common misconceptions about git is that it is only used by startups and open source projects. Not true! Huge enterprises are using Git.

Q & A

$10 for up to 10 devsFree for 5 usersTotally free

The ultimate workflow

NOTES:


If you want to try out any of the products weve shown off tonight, we have a free 30 day trial of Stash, bitbucket is free for five users and SourceTree is 100% free. We also have $10 starter licenses for all of our products that are fully featured for up to 10 users.

Bring up Jesse Miller from ServiceRocket, our sponsors for this evening to help answer any questions.

Before we head into Q & A Id like to pull the organizer Atlassian User Group up on stage to tell you a bit about it, Paul.

Thanks Paul! Now well take a bit of time for questions.

Thank you!


ultimate git workflow - seoul 2015

Technology