Git Makes Me Angry Inside

Git Makes Me Angry Inside

Emma Jane WestbyEducation Development CoordinatorDrupalize.Me

@emmajanehwhttp://drupalize.me

Slides at: http://tinyurl.com/dcto13-git

Saturday, 13 July, 13

Problem: Developers face a steep learning curve when they choose to adopt version control.Solution: There is a version control strategy to suit your workflow, even if you've always thought it was too hard to bother.Is your project folder filled with files like this: page.old.2.bak.php? Does Git make you angry inside? Do you resent that everyone except you regularly visits the magical place referred to as "The Command Line"? Are you afraid of the vagrant who stole your puppet? In this session you will get a gentle introduction to working efficiently as a developer in small teams, or as a solo developer. We'll focus on real world examples you can actually use to make your work faster and more efficient.Yes, this is an introductory session. This is for people who feel shame that they don't know how to "just cd into yer root durrr" and get mad when people say "just diff me a patch" as if it's something as easy as making a mai thai even though you have no rum. No, you don't have to have git installed to attend. You don't even need to know where the command line is on your computer.

http://drupalize.me

http://drupalize.me

http://www.slideshare.net/emmajane/work-flow-for-small-teams-and-solo-devs

http://www.slideshare.net/emmajane/work-flow-for-small-teams-and-solo-devs

Why Stick Around

• Learn how Git thinks, without being exposed to the command line.

• Learn how to structure your work flow to take advantage of Git.

• Learn how basic commands are applied to common work flow scenarios.

• Q&A / therapy session


What’s your role?


You need to start with the people....

What are your tasks?

download work

create snapshot

share work


What are the tasks that your team work on?For example: download work, make changes, upload work to a shared space.

What’s your workflow?


There are a lot of valid workflows.

What’s your branch management strategy?


As your people are working together, they need to have private, and shared spaces to do their work. This is where a branch management strategy gets layered in.

How do we make Git do that?

Git Shell, cross-platform


We’re not going to talk about the specifics of how to run commands today. But these are a few examples of the GUIs that are available for different platforms. (You don’t *have to be* stuck on the command line if you don’t want to be.)

Before we get started: let’s take a second to find out who you are. Why are you here, and how are you currently struggling with version control?

Git is 90% process and 10% technology.

• Git was written by kernel developers, for kernel developers. Chances are high you’re not a kernel developer. Stop blaming yourself, and start blaming Git for your struggles.

• Not all is lost! If you can diagram the problem you are trying to solve; you will be able to find the right Git commands.

• Before we start drawing pictures, let’s take a look at some of the concepts version control helps us with.


Out of the box, Git does basically nothing for you. It’s your processes that will allow you to apply the tools you need to make version control work for you.

Then go through each of the points listed.

Transition: let’s take a look at some of the terms you’ll run into when working with Git to give us a shared language.

Version control (sort of) makes automation easier

• Backup and restore

• Synchronize across multiple platforms

• Short-term “undo” to test implications of changes

• Long-term “undo” to reverse bugs or regressions

• Track changes to see why/how software evolved

• Track ownership to give “credit” to change makers

• Sandbox code to test changes without affecting other people and systems


There are a lot of valid reasons to use version control. The biggest gain bigger teams will see is in automation of process. But you don’t need to automate things to take advantage of version control.

Read through the list of things version control helps with.

Terminology: locations

• remote repository

• trunk or main

• head or tip

• local repository

• client

• working copy


There are a lot of terms in version control. Creating a map of where things live can make the documentation a lot easier to deal with.

Repo: database of changes to your files.Server: computer storing the repoClient: computer connecting to the repoWorking copy: local copy where changes are madeTrunk/main: The current, primary source for unchanged codeHead: the latest revision in a repository (tip: latest in a branch...HEAD moves, tip doesn’t).

Terminology: actions and tasks


With our locations mapped out, let’s take a look at the common tasks or “actions” you can take.

Basic actions:adopt / download: clone, merge, fetch, checkout, pull/rebasereview: log, statuscompare: diff HEAD, diff, diff --cachedreset: checkout, checkout HEAD, reset --hard (throw away in-between commits), revert (save in-between commits)save: add -u, commit, commit -adistribute: push

Set the stage!

Before we can set our workflow we need to know who we’re dealing with and what they’re supposed to be doing.


People first. In this next section, we’ll start with the folks on your team (not the software).

Who’s on your code team?

Write down a list of all of the people on your code team. This list may include:

• developers

• designers

• project managers

• clients


Who are the folks on your team? Designer? Developer? Site builder?

Where do you fit in?

Maybe you do everything. Maybe you only do some things. Write a list of all the tasks you are actually responsible for. This might include:

• Writing code.

• Reviewing code.

• Pushing tested code to the server.

• Fixing broken code.


Slide is “as advertised”.

What are your tools and restraints?

Often there are other things we need to fit into our workflow. Create a third list of any tools and restraints you are aware of. This list might include:

• Version control software (we’ll always assume Git)

• Code hosting system (Bitbucket, GitHub, self-hosted)

• Server ecosystem (dev / staging / live)

• Code editors & integrated developer environments (vim, Dreamweaver, Sublime, PHPstorm)

• Automated testing systems or review “gates”



What’s your workflow?

With the team members identified, it’s time to sketch out how these people (ideally) work together.


Now that we know the people, let’s talk about how they work together. There are lots of valid ways of working together, let’s take a look at a few of them.

Solo developer workflow


Solo dev workflow: create project, add files, do work, upload files

Partner workflow with no central server


James starts a grocery list; Emma already had a grocery list started so she asks to see James’s list. She adds her items to James’s list and hands it back.

Centralized workflow with no local commits


the “old” style of version control has a single place where all work is checked into. Every time work is saved, it’s uploaded to the shared space. You can implement this workflow with distributed version control too, but you wouldn’t want to.

Decentralized with human gatekeeper


This is pretty typical: it’s a decentralized workflow. The developers pull/clone. Do their work locally and then ask their “gatekeeper” to check their work and merge it into the central repo. Once the central repo has the changes, the devs grab a fresh copy and continue their work.

Decentralized with automated gatekeeper


The decentralized with automated gatekeeper is almost the same, except it’s a computer making the decision on whether or not code should be accepted. This is fine for quantitative reviews, but shouldn’t be used for qualitative reviews...unless there are pre-merge peer reviews also happening.

Sketch out your workflow

• Identify the roles on your team.

• Identify the relationships between the team members.

• Draw arrows to show how code flows between team members.



How will you manage your branches?

With the workflow described, it’s time to look at how the code will be segregated into different branches.


This is where the fun starts! Managing branches in a distributed workflow.

Popular strategies

• http://nvie.com/posts/a-successful-git-branching-model

• http://scottchacon.com/2011/08/31/github-flow.html


Work flow and branch management





peer review



peer review

public / live server



peer review




peer review


dev / testing server



peer review



master

master

master



peer review



master

master

master

dev

dev

dev



feature feature

hotfix feature

peer review



master

master

master

dev

dev

dev



feature feature

hotfix feature

peer review



master

master

master

dev

dev

dev


Sketch out your branch management strategy

• Identify the roles on your team.

• Identify the relationships between the team members.

• Draw arrows to show how code flows between team members.

• Time: 10 minutes


Q&A + Git Therapy Session


You can make Git do what you want...now that you know what you want.

@emmajanehwhttp://drupalize.me

Slides: http://lb.com/dcto13-gitHow to git: http://lb.cm/howto-git-videos


http://drupalize.me

http://drupalize.me

http://lb.com/dcto13-git

http://lb.com/dcto13-git

http://lb.cm/howto-git-videos

http://lb.cm/howto-git-videos

Technology

Git Makes Me Angry Inside