Git Branches

Branching is definitely one of the powerhouse aspects of Git. This will be a brief post on how to create, checkout and commit to a new branch. And then merge the changes back into your master branch.... Should you need to.

Example. Spiking a potential technical solution to a future, unimplemented feature. (indicated by 'feature_x' below)

Visualizing branching (image from gitguru.com)

$ git checkout -b feature_x
Switched to a new branch "feature_x"

What's happened here is you've told Git to create a new representation of your project off the main development or working branch. Everyone else can continue to work on that branch, commit things to it, push those commits, etc... You can also keep working on that main branch and pulling down updates on it as well.

View all your branches (The star indicates the branch you're currently on):

$ git branch -a
* feature_x
  master

If you're main development branch is called 'master' this is how you move back and forth between branches your two branches.

$ git checkout master 
Switched to branch 'master'

$ git checkout feature_x
Switched to branch 'feature_x'

Now, at the moment your branch is stored only locally on your machine. If you want someone else to be able to view it or commit to it, you need to push it to your remote repository or 'origin'.

$ git push origin feature_x

Ok, let's talk about how you work on this new branch and move things between it and master.

First, check the new branch back out

$ git checkout feature_x

Switched to branch 'feature_x'

Now, write some code.... la la la... write some more code.....

You can see what you've done so far with

$ git status

# On branch feature_x
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# new_file.rb


Now, add the files to the staging area and commit the code into the git directory for this branch.

$ git add .
$ git commit -m"JY - my code changes"
[feature_x 2c4674c] JY - my code changes
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 new_file.rb

In my earlier post, I talked about how the git DB keeps track of your git directory. When you have multiple branches you can imagine that that DB is tracking each different branch as a different git directory. One way of viewing these directories is using 'git log'.

$ git log

commit 2c4674cf17fd0b7a950076023c810e9796400e0a

Author: John Doe <john.doe@gmail.com>

Date:   Fri Sep 28 12:14:57 2011 -0400

    JY - my code changes

.

.

.

You can checkout master again and run the same command there to confirm that it is, in fact, only on your feature_x branch. But one thing to notice when looking at these commits listed under the git log is that each one has unique identifier associated with it. I'll wrap this post up by showing how you can pull commits from one branch to another by using the cherry-pick command. 

$ git checkout master

Switched to branch 'feature_x'

$ git cherry-pick 2c4674cf17fd0b7a950076023c810e9796400e0a

[master efc5626] JY - my code changes

 0 files changed, 0 insertions(+), 0 deletions(-)

 create mode 100644 new_file.rb 

You can see that that commit has been added to master by doing another 'git log'. Notice that the commit has a different unique identifier. So, it's unique to it's branch within the git directory/db.

$ git log

commit efc562669b7dd993c0a4088144d6f008fde66c0e

Author: Julie Yaunches <julie.yaunches@thoughtworks.com>

Date:   Fri Sep 28 12:14:57 2012 -0400

    JY - my code changes

.

.

.

Git Foundations

I've been using git for the last few years... but I've noticed recently that I've gotten markedly better at it. I think that's because I had to. Anyway, I find the clarity and possibilities opened up by understanding it more deeply very cool. So, in furthering this understanding... I will attempt to explain what I see as the core components and differences between it and other version-control systems.

VCS Rethought - Snapshots not file-system changes

Git sort of rethought version-control instead of just using the same technique as it's predecessors. 

Other version-control systems worked based off of file-system changes.... and tracking these changes over time. Git works based on snapshots. Every time you commit, Git takes a picture of what all your files look like at that moment and stores a reference to that snapshot. It only does this for files that have changed, for unchanged files, it just stores a link to the previous identical file it has already stored. I think in understanding this, it's best to visualize Git as a mini filesystem. 

Local Storage - Intelligent, compressed database

Git does almost everything locally. You can diff a file against the same version of it 2 weeks back without a network connection. The reason for this is that it stores everything, all it's snapshots etc... in it's own intelligent, compressed database. You may say... wow, how big does that get? It actually scales  much better in terms of disk space use than other VCSs. The larger/longer the project the bigger the difference. For the Mozilla project, Git is 30x smaller than SVN.

Three Directories, Three File States

Important: Git has 3 main states that your file changes can be in at any time: Committed, Modified, Staged. And, at any given moment 1 file may exist in all three of these states for you to access and adjust. How does it do this? By basically tracking these changes using 3 different directories: the working directory, the staging area, and the git directory

(Borrowed from Pro Git by Scott Chacon)

The git directory - This is essentially the git database that stores all the info and snapshots of your project. This is what you copied onto your local filesystem when you first cloned the remote repository (from Github or wherever) for your project.

The working directory - This is one version of the project that's been checked out from the git directory for you to work on. This is where your initial file changes, additions go. 

The staging area - When you're happy with some work, but not quite ready to commit it, you can stage it. You do this by adding it to Git. [> git add /dir/filename.rb] or [> git add .]

First Post

Going to be my new techie blog. Expect Android, Ruby, and general enthusiast topics.