Git best practices @Atlassian

This morning was the first day at [Silicon Valley Codecamp](http =//www.siliconvalley-codecamp.com/) and I have to say I did not expect such a huge effort and well organized event.

Bear in mind this event was based on donations, despite of this, they provided coffee, lunch and very nice stands with different companies such as JetBrains, IBM or Pivotal.

I thought that SaaS Workflows & Git Best Practices by Tim Pettersen and Erik van Zijst could be a good talk, although I’not a sofware engineer I do keep my personal projects under Git, and I wanted to learn more about it.

The speakers made the talk very easy to follow, here are some of the ideas I found quite useful.

Branching

In Git branching is very cheap, the message was clear:

Branch all the things!!

People not familiar to work with Git, use a more tradicional workflow, Linear workflow

If somebody push something that breaks, all the team is affected. On the other hand, you may use the Merge workflow, it looks like something like this

The idea is pretty simple, and very useful if you have a CI intrastructure. Below are the main branches in the repository.

Master Branch

All the code that is already in production.

Developemnet Branch

All the code that is in staging. It branches off from Master and it merges back to Development.

Feature Branch

It branches off from Development.

The name of the branches is a convention :

feature/JIRA-<ID_JIRA><-DESCRIPTION>

Hotfix/Bugfix

How hotfixes work is a bit different,

  • Branch off from Master to a new branch with naming hotfix/JIRA-<ID_JIRA>.
  • Merge the previous hotfix into Development.
  • If the previous worked, merge hotfix into Master

Although Rebase is a very neat worklow, is also dangerous and pretty easy to mess your repository up, the most important thing to remember, do not rebase public branches, because rebase rewrites your history, this means it changes the SHA-1 of your commits.

Merge commit

  • uggly
  • full traceability
  • hard to screw up

Rebase (fast forward)

  • no merge commits

Rebase (squash)

  • easy to read
  • more difficult to trace changes

And this is pretty much it, at the end of the talk there was a Git Quiz very funny. Thanks to the organization for this event.