eddorre

Found 4 posts tagged with 'git'

The Git Parabale - My Take

Sunday May 31, 2009 11:30 | comment icon 2 Comments

Tom Preston-Werner, one of the founders of GitHub, recently posted an article titled The Git Parable.

His assertion is that most people teach the functions of Git incorrectly, or in his words, Most people try to teach Git by demonstrating a few dozen commands and then yelling “tadaaaaa.” I believe this method is flawed. Such a treatment may leave you with the ability to use Git to perform simple tasks, but the Git commands will still feel like magical incantations.

He offers an alternative solution, which happens to be the rest of his article — all 4,126 words of it. There is nothing wrong with his article, but using it to teach Git? No way. If anything, it should be the 4th step in teaching Git; definitely not the first.

There seems to be a fundamental misunderstanding about how information is consumed and retained (retained being the most important piece) by people. Let me explain.

Let’s say that you’re being taught how to do something. For the sake of the argument, you’ll want to choose something that’s out of your comfort zone. So if you’re a programmer that doesn’t know anything about knitting, you’d choose that. If you’re a chef that doesn’t know anything about programming, you’d choose that, etc.

Rank the following in how you like to learn about this new skill.

  • I want to read about it
  • I want to talk to someone about it
  • I want to see someone do it
  • I want to be hands on and do it

How did you do?

Most people retain information using the following method:

  • I want to see someone do it
  • I want to be hands on and do it
  • I want to talk to someone about it
  • I want to read about it

Notice where reading is. Notice where seeing is. This is one of the reasons that screencasts, cooking TV shows, and pair programming are so popular amongst neophytes. See and then do. Reading is usually reserved for reference; “I know how to do the basics of this skill, but I want to expand upon it.”

Of course, this is predicated on the person’s learning style. If you chose “reading first” and then “doing” then Tom’s article, The Git Parable, would be right up your alley but it’s been my experience that most people simply do not learn in this fashion. In a very non-scientific and informal poll of people in the audience at Todd Hudson’s talk on Design for Effective Knowledge Transfer at WebVisions people overwhelmingly chose “seeing”, “doing”, “talking” and finally “reading”.

Interestingly enough, people also like the ability to be able to “switch” into the different learning modes as quickly as possible. Anything that prevents that this “learning switching” is going to detract from the end goal of information retention and knowledge transfer. An example of this? Let’s say that I’m watching a 20 minute screencast on how to get started with jQuery. I may watch the first 5 minutes of it, then immediately switch to trying to do it and then when I get stuck, I might want to go back to watching the rest of the screencast or I might try asking a co-worker or a friend. This is where most online learning goes wrong. It doesn’t allow the user to experience knowledge transfer in the way that they need to. Therefore retention of information goes down.

Based off of this information, the way to teach Git is not by reading a 4000 page article first. In fact, you’re most likely going to lose people and discourage them from learning the material in the first place.

Everyday Git from Refresh Portland

Sunday January 25, 2009 21:40 | comment icon 2 Comments

Refresh Portland LogoIn late December (2008) I floated an idea to the other Refresh Portland founders about doing a presentation on Git. As a newcomer and a recent convert to Git, I wanted to share my enthusiasm and learned knowledge with other people that might want to get the basics under their belt.

This past Thursday was the kick off for the Refresh Portland ’09 season and I gave my presentation, Everyday Git, to approximately 25-30 people with 16 viewing online.

If you missed it you can review the slides online or watch the entire presentation on UStream.

Thanks again to everyone that came out.

Displaying Git Branch Name with Bash at Command Line

Sunday December 21, 2008 02:11 | comment icon 1 Comment

When you’re first introduced to Git, you’ll probably just be working in your master branch, but eventually you’ll want to test some experimental feature in your code base without disturbing the master branch. Git makes this a snap to do with the command “git checkout -b branchname”.

If you’re working on a few experimental features at a time, each with their own branch name, it gets a little confusing as to which branch you’re currently working in. Of course, you could just type in the commands “git branch” or “git status” but there is an easier way to keep track of what branch you’re actively working in.

Robby posted an excellent article titled Lighthouse tickets and Git branching that helps him and others at Planet Argon with their workflow during the day. By appending the Git branch name to the end of the command line prompt, he’s able to instantly recognize which branch he’s currently working in.

Unfortunately, he doesn’t tell you how he achieved that feat. After Googling for a bit, I came up with a solution that worked for me. NOTE: Robby is using the z shell (zsh) and I’m using the built in shell with OS X; bash. My solution works with bash and not zsh.

First, I created a .bash_profile file by running the following command from my home directory: “touch .bash_profile”.

Then I modified the contents of the file to include the following:


function parse_git_branch() {
git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}
PS1="\h:\w \u\$(parse_git_branch)$ "

When I’m in a directory that isn’t source controlled via Git, the command line will appear normal:

skyrocket:~ carlos$

Otherwise, it will display the following:

skyrocket:~/work/eddorreblog carlos(master)$

Although I’m using the notation “hostname:working_directory username” you can modify it to your liking using the Bash Prompt HOWTO.

Moving from Subversion to Git & GitHub

Monday December 08, 2008 00:26 | comment icon 0 Comments

Although Git has been making the rounds in social media for a while, it really caught my attention this year at RailsConf with Scott Chacon’s presentation; Getting Git.

After RailsConf and throughout the summer, I was determined to learn more about the fledgling revision control system but something always came up to squash that effort.

Luckily, Planet Argon uses Git exclusively for their version control system and it’s allowed me to learn some of the basics via my favorite learning technique; trial by fire.

In the few weeks that I have been working with Git I’ve been very impressed with how easy it is to get up and running. I’ve been so impressed that I decided to migrate away from Subversion and move to using Git and GitHub for all of my big projects (including this blogging engine).

WARNING: By following these instructions you are taking responsibility for what happens on your system. As with anything, your mileage may vary and I suggest you do a complete backup of your client machine and server machines.

First this is first; install Git. If you’re on a Debian Linux based machine you can install the Git package by running the following commands:

sudo aptitude install git-core git-svn

If you’re on a Mac, I suggest using MacPorts to install the software by running the following commands (after MacPorts has been installed)

sudo port install git-core git-svn

If you’re using a different OS, consult the Git install documentation.

Before I continue further, it’s important to understand my goal. I want to migrate everything from Subversion to Git and then dump Subversion. I do not want to keep Subversion at the end of this process. There are ways to bridge Git to Subversion just in case you can’t completely remove Subversion from your infrastructure but that’s not my intent.

With that in mind, if you have any uncommitted files from your Subversion repository, I suggest finishing up your work and getting all files committed before proceeding otherwise they won’t be available for Git.

First thing you’ll want to do is to identify yourself to Git so that when you make commits, it’ll know who you are. This is done by the following command (this can also be done on a per project basis but I’m doing it globally):

git config --global user.email your_email_here.com

Once that is finished, we’ll use git-svn to “clone” our Subversion repository. Basically, this checks out your entire project into a branch titled git-svn and then creates a new branch called master. Finally it merges git-svn to your master branch.

The command to run this “cloning” process is:

git svn clone path_to_your_subversion_respository_here

You may need to include “/trunk” to the end of your Subversion repository. Also, depending on the size of your project, the cloning process could take a while.

I’m paranoid, so I like to confirm that both the git-svn and the master branches are merged together at the end of the “cloning” process. First, make sure that you are in the master branch by running the following command:

git checkout master

Then merge git-svn into it by running:

git merge git-svn

You should be greeted with a message that reads “Already up to date.” Everything should now be in Git and you could theoretically be able to dump Subversion now. Obviously, a pragmatic approach would be to archive your Subversion repository on a backup device just in case anything bad happens.

I should note that Git is now running on your local machine and you can make commits to your local repository. This is obviously different from the Subversion client-server model and if this makes you uncomfortable you can certainly setup an origin server to push and pull content from. I chose GitHub primarily because it’s easy to use and setup. Once you are signed up with GitHub, create a repository and run the following commands:

cd existing_git_repository
git remote add origin github_repository_address
git push origin master

I should make a footnote here. Since my Subversion repository isn’t available on the Internet, I wasn’t able to use GitHub’s Subversion import feature. Feel free to use that feature if your Subversion repository is available on the Internet. That way you can skip the whole git-svn thing.

At this point, feel free to delete the git-svn branch as it won’t be needed anymore. You can do this by running the following command:

git branch -d branch_name

Now that you have installed Git, what now?

I would suggest reading the article Git for Designers

More resources:

GitCasts
git-scm.com

end kanji