Subversion uses the traditional, "central repository" scheme to version control. If you are working in a team, one person will need to be designated to host the "official" repository in his/her home directory. Members of the group will then check-out a working copy from the HEAD of the central repository and commit changes back to that location. This is slightly different from distributed version control which will follow (in the Git/Mercurial sections below).
Creating an empty Subversion repository
Setting up the Repo to Serve via HTTP
Basic SVN Commands
Git is a distributed version control system designed to allow each developer his/her own 'repository' (e.g. the developer can easily branch on his own working copy without affecting the "official" source tree). In this scheme, no one necessarily needs to commit to an official central repository (although pulling changes to one particular working set is beneficial in order to turn in assignments). Git can also act as a pseudo central-repository from your public_html directory in order to allow project members to clone copies of the working source.
Creating a serviceable Git repository
This initial Git repository will serve as a starting point for team members to clone a working copy, and to begin adding their files to the project. When it is time to merge code segments from each member, the person who owns the public_html folder will act as the repo administrator and pull the necessary changes from each of the other team members.
Assuming there are existing source files (or in this case the project assignment) in the directory where you would like to work
$ pwd /home/ugrads/wwildcat/myproj $ ls #there are existing files that I want to myProjAssignment1.txt $ git init #initialize an empty repository Initialized empty Git repository in /home/ugrads/wwildcat/myproj/.git $ git add . #add all the files and directories in `pwd` to the repo $ git commit #this commits the changes (i.e. the adds you made) and opens an editor to allow #you to make any comments describing the commit
Now we will clone the repository into our public_html directory so that we can checkout our repository over HTTP
# a bare git repository is one without a working copy (i.e. it is only the versioned objects and their relations) $ git clone --bare ~/myproj ~/public_html/repos/myproj.git #tell your remote git repo that you want to serve it out $ cd ~/public_html/repos/myproj.git #change into the project's html directory $ touch git-daemon-export-ok #this tells git that it is ok to export this repository $ git update-server-info #this puts in the necessary information to tell where it came from $ mv hooks/post-update.sample hooks/post-update && chmod +x hooks/post-update #this script runs update-server-info every time there is an update on the repo
Now you can checkout a working copy anywhere!
my_machine_at_home$ git clone http://people.cis.ksu.edu/~wwildcat/myproj.git . #checks out a working copy into the current directory ...Hack on some stuff... my_machine_at_home$ git commit -a -m "In this commit I hacked some stuff" #commits all changes to the local repo (-m lets you specify a message inline #rather than opening $EDITOR)
After making changes, you can push your changes to the "official" repo hosted in your webspace over ssh. Note the leading slash before the tilde, this is different from scp syntax
my_machine_at_home$ git push ssh://firstname.lastname@example.org/~/public_html/myproj.git
Helpful Git Commands
$ git checkout -b testingNewFeature #this command makes a branch (copy of the code) in your local repository. You can make any changes to the code #and it does not affect the MASTER copy. If your changes go well, you can merge them into master, if they don't #you can either keep the branch for future reference, or delete it without affecting your production code
$ git checkout master #switch back to the master repository after working on a branch $ git merge testingNewFeature #merge all changes made in testingNewFeature in the master (mainline) copy of the repo
$ git pull #this will automagically pull changes into your working copy from the remote repository that you cloned from
$ git log #shows a log of all the commits to this repo, it also lists the date/author of the patch
$ git status #shows which branch you are working on in the working copy