Month: November 2012

Git for Beginners – A Sample Workflow

So here is my *very* happy path sample workflow, using local branches, with explanations for first time users of Git. See here for a worksheet with useful git commands and their uses and a sample workflow. This covers only what this post covers.

You will aslo see references here to “git tf”. This is not an alias but a cross-platform, command line tools that facilitate sharing of changes between TFS and Git. The commands are the same as the regular Git ones. But slightly different for pushing and pulling. See here for more information.

A familiar workflow:

  • Get the latest code
  • Create somewhere to put the changes you are about to make
  • Make changes
  • Make sure you are happy with them and want to integrate them back into the main repo.
  • Check for any more updates
  • Push your code into the remote repo

Now broken down into the Git steps to achieve the above.

1. Get the latest code

Make sure you are on master. Use git status to check.

Pull down the latest changes onto master git pull

2. Create a new branch for your story work.
Name it after your story so you can remember it later. git checkout -b [branchname]

If you do a git status now you will see you are on your new branch.

3. This is where you code as normal, running your tests etc.

4.Commit your changes to your branch.
When you are a point where you are happy with your changes and you want to pull in everyone else’s changes… You can commit as many times as you like to one branch but try to keep them small and in a working state.

A git status will show you your changes.

You will see the files that git is tracking and has staged and those that it has not. git add . Or git add -A will add any untracked files.

Next commit your files to your branch. git commit -am "[message]"

When you do a git status now, you should see no changes.

If you do a git log you will see that your commit is now part of the branches history.

5. Get latest code on master

Move back onto your master branch git checkout master

If you do a git log at this point, you will notice that your commit is not yet on master, and the latest commit will be from when you last pulled.

git pull will bring down any more changes.

6. Update your branch with lastet code

Move back to your story branch git checkout storyname

Next you are going to rebase your branch. When you originally created your branch it was based on point in time x, since there have been additional changes (time y), you want to tell your branch that you actually want it to be based from time y and you want your changes on top of that. So now git rebase master will update your branch with all the changes that are now in your master branch. As you watch the output you will see that git pulls out your change, fast forwards to time y and then replays your change on the top. Now you may have conflicts at this point if two people have changed the same thing but will assume things are all good.

Now run your tests and make sure everything is good.

7. Get your changes back into the main repo.

Move back to your master branch git checkout master

Merge your branch back into master with git merge storybranch

git push will then send up changes to the remote repository.

Next time… Merge conflicts…..

Git for Beginners – Team Lunch and Learn

Our team has just embarked on “Lunch and Learn”s. (A time for the team to get together over lunch and learn about something new). For the first one, my colleague Tom and I volunteered to teach the team to use Git…

Our development team was previously all located in the UK, but we are about to go distributed with teams in both India and the UK.

We are working on a .Net stack so of course, (shudder) we are using TFS. Due to the team changing to be distributed we are having to look at more distributed friendly source control systems, and thankfully Git is on the table.

Now I am definitely still a relatively Git noob. I was introduced to it on my last project, and we used it pretty extensively for a year. Now, I hate working without it. I think it’s changed the way that I work, so it’s hard to go back to the TFS dictated way of working.

We are planning on doing two sessions. This first one being just on the very very basics for someone who has never used Git or another distributed Source Control System. Literally, this is how you get stuff out, change stuff, and get it back in. Hoping nothing goes wrong.

Anyway, we bought pizza for everyone, to keep them happy, and quiet.

The first part of the session we did in a meeting room with whiteboards. Tom talked about some of the high level concepts of distributed source control systems. Along with a brief description of how it differs from TFS ***. Tom also talked through some of the key terminology that people would need to get used to. i.e. working trees, remote repository, the index/staging etc.

My job was guiding the team through the workflow that we’ll be encouraging. I chose to first explain the workflow we would be using, away from the computers using pictures, to ensure that everyone listened and understand why they were doing each command. I was worried that everyone would be distracted and race ahead without considering what they were doing with a shiny new toy in front of them.

Now I know that there are two different schools of thought out there. Local branches or committing on master. I was taught to use Git using local branches so that’s what I’m more comfortable teaching. Plus it means that your master branch is always clean, gives you a bit more of a safety net, but also it forces you to change the way that you are working, not just doing the same workflow you did in TFS or SVN. It forces you to start getting used to the concepts that really make Git powerful.

It went surprisingly well. I was expecting a lot of fear and resistance, but actually it create a great new energy around the team. Everyone rushed back to the computers to try out what we had been showing them, and it started a lot of good discussions.

See the following post for my detailed description and walkthrough of a sample workflow with Git.

*** to keep the “but in TFS…..” To a minimum, I asked everyone to keep an open mind and if anyone who wasn’t presenting brought up TFS they’d have to do star jumps in the corner.