Ultimate Git Workflow - Seoul 2015
-
Upload
atlassian- -
Category
Technology
-
view
1.164 -
download
0
Transcript of 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:
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.
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:
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.
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?
Tim Pettersen Developer Provocateur Atlassian @kannonboy
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
Im a developer provocateur from Atlassian.
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
Who here has heard of Atlassian?
Facts
800+ Developers
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
Source: Atlassian Git Survey 2013release speed: git vs centralized
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
Photos that fill up the entire screen have a great visual impact.
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:
Photos that fill up the entire screen have a great visual impact.
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:
Photos that fill up the entire screen have a great visual impact.
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
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
hotfix/JIRA-32-wtf-ie8-srsly 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
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
?
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
Atlassian BitbucketWorkflowSaaS Workflow
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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
Multiple Product Versions
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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
Multiple Product Versions
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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
Multiple Product Versions
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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
Multiple Product Versions
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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
Multiple Product Versions
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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
Multiple Product Versions
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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
Multiple Product Versions
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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
boring work
Multiple Product Versions
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
Photos that fill up the entire screen have a great visual impact.
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
TeamOwnership
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
Code review
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
Pull requests
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
Pull requests
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
Pull requests
review before merging
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
Pull requests
human judgement needed?
what-evs
bad API decision
O(n!) algorithm
technical debt
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
Client-side hooks Server-side hooksContinuous IntegrationCode Reviewkola ta
So weve discussed many different aspects of software
AWARENESS
LEADSPROSPECTSSALES
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
AWARENESS
LEADSPROSPECTSSALES
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
Photo: Steffen Heinz
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
http://commons.wikimedia.org/wiki/File:Bon_toutou.png
Continuous Integration
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
So now lets talk about how git can magically improve the quality of your code.
Building master & develop
develop
master
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
Weve talked about building master and develop
Comic: Randall Munroe http://xkcd.com/303/
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
Working with contractors?
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
Circle of TrustPhoto: Aljaz Zajc
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
Strangers on the internetContractors
InternsOther product teamsSupport
Core dev teamCircle of Trust
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
Collaborating with SVN
Core dev teamEveryone else
emailing patchesrepository tarballshell-ish conflicts
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
Collaborating with forks
Everyone elseCore dev team
Changes automatically synchronizedownstream
.. but must be reviewed before moving upstream
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
feature/*Mentoring with branches
SeniordevelopersJuniordevelopers
master
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
Strangers on the internet
InternsOther product teamsSupport
Core dev team
Contractors
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
Three reasons why Im really proud of what weve built with the Stash project.
Git workflows for teamsExtensions& Integrations
Scalability
Why ?
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
Three reasons why Im really proud of what weve built with the Stash project.
Git workflow for teams
feature/STASH-123
master
ForkingBranchingvs
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
Full Java APIRepository HooksMerge ChecksUser InterfaceREST end-pointsFiletype renderersSSH commands
Stash Platform
Branch Permissions
REST APIs
JIRA Integration
Source?You betcha!Plugin APIs
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
(use previous slide instead?)
insert /rest/api/latestRESTful APIs
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
.. you get the REST variant of that resource.
Scalability
Request throttling
NOTES:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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:
If you want to divide your talk into chapters, use this slide for Chapter titles
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 divide your talk into chapters, use this slide for Chapter titles
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!
Tim Pettersen Developer Provocateur Atlassian @kannonboy