===== Introduction =====

git is a [[http://en.wikipedia.org/wiki/Revision_control|source control management]] tool similiar to CVS or SVN. This tutorial will give enough information to:

  * create a central git repository on your MetaARPA account
  * clone that git repository to your off-site computer
  * sync your changes with your repository copy on sdf

Unfortunately in its current form it will not cover multiple users using the same git repo. \\  The best reason why a person would use git instead of cvs or svn is that git does not require a central server. For example, let's say you were taking out a CVS repository to your laptop and would not be able to connect to the server for a month. When you get back, that entire months worth of work is seen as a single diff. Which you would have to merge by hand to the other changes, but also you couldn't differentiate between reasons you changed files. For example, let's say you fixed a bug and added a new feature. Which filechanges were for the new feature? Which for the bugfix? CVS has no clue. Enter git. You can locally "commit" changes without talking to the server, so you could have done a commit after the new feature and a commit after the bug fix and to the repository they are two unique changes.

===== Configuring your account to use git on sdf =====

First, you must be MetaARPA to use git.  
Second, the git pkg installs most binaries you need in /usr/pkg/libexec/git-core. This needs to be in your PATH. The easiest solution is to edit ~/.bash_profile and ~/.bashrc to read:

  export PATH=/usr/pkg/libexec/git-core/:${PATH}

Now any SSH session will have the necessary git binaries in the PATH.

===== Creating a central git repository on SDF =====

I suggest creating a subdirectory that will hold nothing but your git repositories.. let's say it's ~/git. The server copy of the git repository need not be a useable repository (IE, the files under revision control do not need to exist.. we just need the git database to exist so we can clone from it). Under git this is called a "bare" repository.

==== Create the server repository ====

  cd ~
  mkdir git
  mkdir myproject
  git --bare init
  
And that's it! on the server side. This remains empty until you first "push" your project to the server.

===== Creating your local git repository. =====

Let's assume you already have a project you want to start watching under git, with the files     
  ~/proj/
  ~/proj/include
  ~/proj/test.c
  ~/proj/include/test.h

First, initialize the git project:

  cd ~/proj
  git init

Now your repository is initialized! Time to check in your current project. First we add the files to the repository. I like to manually add each file instead of doing a "commit all" because "commit all" tends to collect files you never wanted to add to source control (object files, temp editing files, etc).

  git add test.c include/test.h  
  git commit
  
If the commit failed, follow the directions onscreen to configure your username and email so git can track you as a user in the repository.
Now time to connect your local copy to the repository on sdf.
  
  git remote add origin user@sdf.lonestar.org:git/proj  
  git push origin master
  
Git should ask for your password, and then tell you it uploaded the objects and that everything succeeded.
If not, ask on the sdf forum for advise.

===== Copying your central repository to a client machine =====

Last thing: Now that you have a central copy, how do you check it out? use "git clone":
  git clone ssh://user@sdf.lonestar.org:~/git/proj

===== Backing up all your existing git repos to a remote server =====

sdf doesn't backup your git repository.. while any cloned git tree is basically a backup it'd be nice to have an "official" backup to go along with your now "official" git server on sdf. Here is a script that will, in sequence:

  * check your git repo for any changes
  * if changes exist, tar up all your git repo
  * ftp it to another host

The script is expecting you to have a directory called ~/git, and under that directory have your git projects named as ~/git/proj1.git, ~/git/proj2.git, etc. Otherwise modify it as you see fit.

==== The script, git-backup.sh ====

<code bash>
  #!/usr/pkg/bin/bash

  cd ~/git
  mv git-summary git-summary-old
  for i in *.git; do
    cd $i
    git log --pretty=oneline &gt;&gt; ../git-summary
    cd ..
  done

  diff git-summary git-summary-old
  if [ "$?" != "0" ]; then
     #tgz up the whole git directory with today's date
     cd ..
     rm git-latest.tgz
     tar -cvzf git-latest.tgz git
     ftp ftp.your-host.com &lt;&lt;WOOPWOOPWOOP
     cd git-backup
     rename git-latest.tgz git-backup.tgz
     put git-latest.tgz
     quit
  WOOPWOOPWOOP
  fi
</code>

Note: For the FTP to work, edit your ~/.netrc file so that ftp.your-host.com has an entry that looks like:\\

<code>
  machine ftp.your-host.com
      login your-user-name
      password your-password
      bin
</code>

Also ensure to run "chmod 600 ~/.netrc" to hide your credentials to the rest of the world :). Now add this to your (daily or less) cron tasks with mkcron (MetaARPA only, just like git ;) and enjoy your timely backups!

===== Updating your local copy with changes made to the repo =====

First, let's note that for git, each repository is equal. This is unlike older VCS like CVS or Subversion. Now, if you have not cloned from your SDF repo, do

  git remote add origin user@sdf.lonestar.org:git/project

where "origin" is the nickname for the repository on "sdf.lonestar.org". 
Then, you do

  git fetch

followed by

  git merge 

Git also provides the command "git pull" to do a fetch followed by a merge. This is unlike CVS and Subversion, where "update" works like "pull". The two commands are provided because your local repo is not meant to be a copy of the remote, so you need to be able to fetch the remote without merging it into your local repository.


===== Creating a public access, read only repo =====
Once you have your repo setup for you to do your work in, you may have a need to make your work public. Making it public allows for other users to pull specific version of your project without having to have development rights. A slight modification to your repo is needed and some webspace to host it.

=== Setup some webspace ===
To host a readonly public access version of your repo you will need to setup some space in your html directory. For our example our public repo will be accessable at http://user.sdf.org/devel/proj.git

  mkdir ~/html/devel
  hooks/post-update

In your repo directory for the project there is a directory that contains a set of scripts which are called at different times during your interaction with git. For more information about the "hooks" directory check out githook.

The script we will need to modify is post-update. This script is called after an update has occured on the server side of your repo. 

<code bash>
#!/bin/sh
#
# File: ~/git/proj.git/hooks/post-update
#
# Description: Called when an update is pushed to the server
#

# Location of your repo on the server
GIT_DIR=/arpa/tz/u/user/git/proj.git

# Location of your public version of the repo
HTTP_DIR=/arpa/tz/u/user/html/devel/proj.git

# Update local repo info
git update-server-info

# Make sure a clean copy is moved
rm -rf $HTTP_DIR
cp -rf $GIT_DIR $HTTP_DIR
chgrp -R nobody $HTTP_DIR

# Directories must have Read and Execute Permissions
# for apache to be able to navigate them.
for d in `find $HTTP_DIR -type d`; do
  chmod a+rx $d
done

# Files must have Read Permissions for apache
# to be able to read them.
for f in `find $HTTP_DIR -type f`; do
  chmod a+r $f
done

# Display a message on the client side to show 
# the action has been performed.
echo "Updated Public Access"
</code>

Now that you have setup this script make sure its executable.
  
  chmod a+x ~/git/proj.git/hooks/post-update

You can now run the script directly or wait until you have committed and pushed an update to your server.

=== Verifying script is run. ===

When you push an update to your private development repo, a new output has been added by our script.

  $ git push
  Counting objects: 5, done.
  Compressing objects: 100% (2/2), done.
  Writing objects: 100% (3/3), 256 bytes, done.
  Total 3 (delta 1), reused 0 (delta 0)
  remote: Updated Public Access
  To user@sdf.org:git/proj.git
     e60a9de..1f8a43f  master -> master
  $

In the above example there is a new line labled "remote" which means that during the push, the server produced output. The line matches the last line in our post-update script. Now you have two methods of access.

**Private Access**: git clone user@sdf.org:~/git/proj.git \\
**Public Readonly Access**: git clone http://user.sdf.org/devel/proj.git

===== Further Reading =====

There are quite a few good tutorials freely available on the net. Check out: 
  * [[http://www.webdesignerdepot.com/2009/03/intro-to-git-for-web-designers/|Intro to Git for Webdesigners]]
  * [[http://gitimmersion.com/|Git Immersion: Tour through the fundamentals]]
  * [[http://progit.org/book/|Pro Git]]
  * [[http://book.git-scm.com/|The Git Community Book]]

===== TODO =====

  * merging/branching

Best look online for more in-depth tutorials.. 
I haven't needed these features yet as my projects are all just me, so I don't know how to do it!

$Id: scmgit-intro.html,v 1.6 2011/06/24 16:08:10 jecxjo Exp $