Git

The Git system (http://git-scm.com/) was originally developed by Linus Torvalds as a distributed version control system to replace BitKeeper for the Linux Kernel project

The bottom line is this: modern software development may take many "forms", but it usually boils down to this. Git enables such a branched workflow. That is why distributed version control in general, and git in particular, is the most widely adopted version control system for software development

See Git/hacks for example commands

Intro to Git

Greg Rundlett setup git repository hosting services at the IIC (http://svn.iic.harvard.edu/gitweb/)

Why do we have git? Because Git is better than X Now that we have the "My DVCS is better than your DVCS" argument out of the way, you can actually get some valuable insights from that website if you are interested in comparing Git with Mercurial, Bazaar, Subversion or Perforce. If I had to single out one primary advantage of Git, it would be that it actually features branching and merging.

Repo visibility is completely customizable, as are individual permissions to write to repos. I've installed a system called gitosis to handle the privileges through a special git repository. It uses Public Key cryptography rather than granting SSH accounts to everyone. This makes it really easy to do your work securely without even needing a password. For the curious, the actual mechanics of gitosis are detailed at scie.nti.st

You can actually host your own private repository on any server that you have access to. To collaborate with your peers, export a bare repo and use SSH keys. more

To host a public repo, go to http://github.com

You might want to read about how we migrate from Subversion to Git or how others have done it

Tools

• http://git-scm.com/tools
• http://github.com/guides/using-the-egit-eclipse-plugin-with-github

Reporting

How many lines have I contributed since last year?

git log --stat --author $(git config --get user.email) --since="last year" --until="last month" | awk -F',' '/files? changed/ {
    files += $1
    insertions += $2
    deletions += $3
    print
}
END {
    print "Files Changed: " files
    print "Insertions: " insertions
    print "Deletions: " deletions
    print "Lines changed: " insertions + deletions

}'

Visualizing

There are a lot of ways to use the git log command to visualize your history. Everything from git log --pretty=oneline or git log --graph --oneline to git log --graph --full-history --all --color --date=short --pretty=format:"%x1b[31m%h%x09%x1b[32m%d%x1b[0m%x20%ad %s" which you probably want to put into your ~/.gitconfig as some alias because who the heck is going to remember that one? Of course there are also many GUI clients.

Documentation

• http://wildlyinaccurate.com/a-hackers-guide-to-git Helpful intro because it doesn't pretend that Git is just like Subversion
• http://www.gitcasts.com GitCasts
• http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday Git in 20 commands
• http://git-scm.com/course/svn.html Git crash course for SVN users
• http://utsl.gen.nz/talks/git-svn/intro.html This intro for git-svn (a combination of git + svn) actually provides a lot of information and especially gives perspective if you've tried to use svk.
• http://git.or.cz/course/svn.html
• http://software.complete.org/software/wiki/site/GitGuide Git Guide (short) at Software Complete.org
• http://git-scm.com/book/en/v2
• http://git-scm.com/documentation
• http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
• http://www.kernel.org/pub/software/scm/git/docs/git-config.html
• http://github.com/guides/providing-your-ssh-key

Git and Subversion

• http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion
• http://viget.com/extend/effectively-using-git-with-subversion
• http://trac.parrot.org/parrot/wiki/git-svn-tutorial
• http://flavio.castelli.name/2007/09/04/howto_use_git_with_svn/

Git Repo Hosting

It seems everyone uses GitHub these days (~8 million users, 20 million projects). It's not a bad solution, but there are some drawbacks, and whether you're just looking to host your own project or setup enterprise-wide git hosting, there are other ways to host your projects in Git. Let's take a look at some options.

1. GitHub can make it a bit easier for developers who are used to working with svn because they have 'built-in' svn client support. GitHub Enterprise can be installed on your own servers. GitHub costs money for private repos.
2. GitLab is the "popular" alternative to GitHub that comes in "Community", "Enterprise" and "Cloud" versions. They say it's "better than GitHub" One nice thing that I note is that they've integrated git-annex for large binary support. This is a nice plus. (I've personally used git-annex as a file backup system -- like DropBox. In my case, it was to make backups of UbuntuOne when that service was discontinued.) You can install GitLab in minutes on your own server. It's costs if you want the Enterprise version.
3. GitBlit is "a pure Java git server that just works". It's a "true" open source project run by James Moger and scores of other contributors. GitBlit is self-hosted, so you can get a feel for it quickly by looking at the projects own source code. It does have some nice features. The current Wikimedia Ops team is using Gitblit to drive https://git.wikimedia.org/ Gitblit is an open-source, pure Java stack for managing, viewing, and serving Git repositories. It's designed primarily as a tool for small workgroups who want to host centralized repositories. It comes in two options: GO is an integrated single stack solution so you can really get up and running in no time flat; and there is a WAR version (assumes you already have a servlet container like Jetty or Tomcat.) Gitblit requires a Java 7 Runtime Environment (JRE) Gitblit comes with a lot of features
4. gitolite is similar to the now defunct gitosis.

Background

I got into Git to make managing Drupal projects possible. Now that we have a distributed VCS, we can actually collaborate in multiple ways (more than just a centralized model), and we can work offline . We can easily branch and merge. We can pull in updates from the Drupal core maintainers. We can pull in updates from the Drupal community (module maintainers). We can track our own custom modules - especially if they are developed by more than one person. We can branch, tag and deploy these combined sources to multiple instances (dev, staging, production) across multiple instances of Drupal (e.g. client projects that should share the exact same codebase) and have complete clarity on where each project stands regarding patches and security fixes or updates. There have been several attempts in the Drupal community (credit to Moshe, Ben, Dries, et al.) to get this all working over the past year or so and I think we're finally seeing the tide turn in our favor. Drupal may actually start to be "easy" to maintain and deploy. Actually, the whole point is to BE up-to-date on all our projects. This only happens when it is feasible. Git makes it feasible.

• http://versioncontrolblog.com/2007/08/02/upgrading-drupal-52-with-git/
• http://www.aidanf.net/node/133
• http://github.com/mikl/drupal/tree/master

I pulled down the whole clone (which is only 26MB in size) of mikl's public history of Drupal in a few minutes.

With Git, it is even possible to manage projects which are composites of multiple sources (Ever tried that with Subversion's 'externals'? -- Don't bother to try it with Subversion because it just doesn't work! Not only are externals feature poor, you'll still end up wanting to merge even more than before. And as we know, merging is not a feature in Subversion.)

Comparisons of Branches, sources etc.

When comparing large trees of files, you need a good set of tools to be able to filter out noise. Normally KDiff3 is very good at this. However, KDiff3 is not available yet as a package for Ubuntu. If you compile it from source, I still found that the most important feature -- the preprocessor -- would not work if more than one command were piped together.

Specifically, I couldn't use this preprocessor setting which worked great for me in the past: sed "s/\$\(Id\|Revision\|Author\|Log\|Header\|Date\).*\$/\$\1\$/" | sed "s#/\* vim: set.*#/* vim: set ... */#" | sed "s/^.*opyright.*$/Copyright Greg Rundlett :-)/"

Without the benefit of a good preprocessor, KDiff would falsely tell me that there were 1,523 files which differed between DRUPAL-6-9 and DRUPAL-6-10

Kompare seemed hard to configure, and Meld didn't apply the pre-processor to directory compares. So, I used the command-line version of diff:
greg@greg-linux:~/work/git/drupal$ diff -r --exclude=.git --exclude=.svn --brief --ignore-matching-lines="$Id" . /var/www/drupal/

Only in /var/www/drupal/: favicon.ico
Only in /var/www/drupal/sites/all: modules
Only in /var/www/drupal/sites/all: themes
Only in /var/www/drupal/sites: dev.example.org
Only in /var/www/drupal/sites: example.org
Only in /var/www/drupal/sites: localhost
Only in /var/www/drupal/sites: prod.example.org
Only in /var/www/drupal/sites: www.example.org

Building a Git server

(This recipe was from 2008. It may still work, but ymmv)

Generally following the series of instructions at http://vafer.org/blog/20080115011413 I installed Git-core, gitweb and gitosis on the host

# install git, the git-svn tool and the viewvc equivalent
apt-get install git-core git-svn gitweb

# run the git-daemon - a really simple server for git repositories
sudo -u git git-daemon --reuseaddr --verbose --base-path=/home/git/repositories/ --detach

# create a service that starts when the machine starts
cat > /etc/init.d/git-daemon << EOF
#!/bin/sh

test -f /usr/bin/git-daemon || exit 0

. /lib/lsb/init-functions

GITDAEMON_OPTIONS="--reuseaddr --verbose --base-path=/home/git/repositories/ --detach"

case "$1" in
start)  log_daemon_msg "Starting git-daemon"

start-stop-daemon --start -c git:git --quiet --background \
--exec /usr/bin/git-daemon -- ${GITDAEMON_OPTIONS}

log_end_msg $?
;;
stop)   log_daemon_msg "Stopping git-daemon"

start-stop-daemon --stop --quiet --name git-daemon

log_end_msg $?
;;
*)      log_action_msg "Usage: /etc/init.d/git-daemon {start|stop}"
exit 2
;;
esac
exit 0
EOF

# and add it to the various run-levels
update-rc.d git-daemon defaults

# setup the configuration of the gitweb repository browser
vi /etc/gitweb.conf

# Add cgi capabilities to our "Version Control" host
vi /etc/apache2/sites-available/git

# check the syntax of our apache configuration
apache2ctl configtest

# oops, the mod_rewrite isn't enabled
a2enmod rewrite

# check syntax and errors again
apache2ctl configtest

# restart apache
/etc/init.d/apache2 restart

# see what may have been added to the web docroot
ls /var/www/

# check to see that gitweb is installed
# and see what files it installs since they aren't in /var/www
dpkg --status gitweb
dpkg --listfiles gitweb

# create a symbolic link between the gitweb software and the repository root where we'll be viewing it.
ln -s /usr/share/gitweb /home/git/

# see what we have so far
ls /home/git/

# setup our gitweb configuration
vi /etc/gitweb.conf

# check if gitosis is packaged for ubuntu
apt-cache search gitosis
# and install it
apt-get install gitosis

Rant

quote 

After replacing the 1.0 code with 1.1 code, svn status will show files with local modifications as well as, perhaps, some unversioned files. If we did what we were supposed to do, the unversioned files are only those new files introduced in the 1.1 release of libcomplex--we run svn add on those to get them under version control. If the 1.1 code no longer has certain files that were in the 1.0 tree, it may be hard to notice them; you'd have to compare the two trees with some external tool and then svn delete any files present in 1.0 but not in 1.1. (Although it might also be just fine to let these same files live on in unused obscurity!) Finally, once our current working copy contains only the libcomplex 1.1 code, we commit the changes we made to get it looking that way.

So, according to the official Subversion manual, the right way to track source code that you build on, you should

1. download an export (they don't even consider that your vendor should be and IS using a VCS)
2. add stuff that they added
3. launch external tools to find out if there were deletions
4. or just ignore deletions (tell me why we're using source code managment tools?)
5. commit those changes

They admit that this is not exactly what you would like: "...things can quickly degrade into a situation where we have to manually re-create our customizations in the new version."

The official manual continues: "Vendor drops that contain more than a few deletes, additions, and moves complicate the process of upgrading to each successive version of the third-party data. So Subversion supplies the svn_load_dirs.pl script to assist with this process."

Except that svn_load_dirs.pl does not come with Subversion , and even if it did, it has limited or zero capabilities to handle and TRACK the status, history, and provenance of your source code. In any situation where a conflict arises, svn_load_dirs.pl will ask YOU to figure it out -- without any supporting details. Despite what the quote from the manual implies, the actual README with svn_load_dirs.pl says that it should NOT be used with sources that come from another VCS... those imports should be scripted ala cvs2svn etc.

I don't recommend looking at these, you'll just learn how NOT to do things. But here are examples of others who have needlessly fought with Subversion to manage their Drupal sites and source code

• http://minimalmedia.com/en/blog/dave/upgrading-drupal-core-with-vendor-branches-and-svnloaddirs-almost-perfect
• http://www.transmachina.com/en/drupal-subversion-repository
• http://www.davidgrant.ca/maintaining_vendor_sources_with_subversion
• http://www.burtonini.com/blog/computers/svn-vendor-2005-05-04-13-55

Version Control System