Version Control Systems

A version control system solves the problem of how many people can work on the same code base at the same time.
It also serves as a proof of work which can be used in legal cases -- the history of versions proving the code did not materialize out of nowhere.
One of the oldest version control system is the Source Code Control System developed at Bell Labs in 1972.
It was subsequently supplanted in popularity by RCS (Revision Control System) which in turn was supplanted by CVS (Concurrent Version System).
Nowadays, there are many different version control systems on the market.
There are traditional central repository systems: CVS, Subversion (open source); BitKeeper, Perforce, ClearCase ( proprietary)
There are also distributed version control systems: Bazaar, git, Mercurial.
Here is a round-up of the different features of these systems https://en.wikipedia.org/wiki/Comparison_of_revision_control_software
Today, we are going to look at the git version control system as one means to manage our own projects. So we are going to be looking at a distributed VCS.
We will then talk about GitHub which is a web-site for hosting git repository. This central web-site and its features will give us a little bit of the flavor of how centralized repos work.
From Wikipedia, we can see GitHub is the most popular such hosting platform (65 million users versus 30 million users for Gitlab and 5 million users for BitBucket).

Git

Git has been around since 2005, and was originally developed by Linus Torvalds, the creator of Linux.
Git has a nice website for publicly hosting git repositories known as GitHub. Repositories on this site get their own issue tracker (with rss feed) and wiki.
To begin to set up a git repository move to where you would like to have your repository and type:
```
git init name_of_git_repository.
```
If you cd into this directory and do an ls -a to see hidden files, you will see a .git folder.
The .git folder keeps a complete copy of all prior commits down for this repository.
If you want to let someone to get a copy of your repository, you copy the repository folder on to a usb key (a key without Stuxnet please), give it to the person you want to have the repository.

The person that wants to get your repository, might have an existing repository that they want to get your stuff into or might be starting from scratch. They issue a commands like:

git clone path_to_clone_from to_folder #from scratch case
git pull path_to_from_repos branch_name_you_want_to_pull_into #existing case
git checkout branch #makes branch the current branch in the repository you are working on

Notice sharing can be done locally without the need for a central repository, you can zip your git folders and e-mail, git even has its own e-mail commands.
To see information about git commands, you can type 'git help', or 'git help command'

Example Creating a Repository

Here is a short example of creating a repository on a *nix system in the directory /Users/cpollett

mkdir myrepos
cd myrepos
git init
git add .
echo "hi there" > test.txt
git add test.txt
git commit -a -m "Initial commit"
cd ..
git clone file:///Users/cpollett/myrepos myrepos2
cd myrepos2 # now start editing myrepos2
echo "test2" > test2.txt
git add test2.txt
git commit -a -m "Made some changes"
cd ../myrepos #now want to get changes back in myrepos
git pull file:///Users/cpollett/myrepos2 master

This produces a copy of the repository in a separate folder. We then edit the copy, and pull the changes back (the changes were in the clone's master branch) into the original repository. We will describe git add and git commit in a moment.

If in myrepos2 we want to get changes from myrepos, we could simply have done:
```
git pull
```
as git will default to pulling where it was cloned from.

Creating a WebDav repository

If you want to have a workflow more like svn with a central repository you can configure a WebDAV directory in Apache on a server for git:

<Location /git/myrepos.git>
DAV on
AuthType Basic
AuthName "My site"
AuthUserFile /etc/apache2/myrepos.passwd
<LimitExcept GET HEAD PROPFIND OPTIONS REPORT >
Require valid-user
</LimitExcept>
</Location>

When you initialize your repository, you do the following commands:

mkdir myrepos.git
cd myrepos.git
git init --bare
git update-server-info

You need to change the permissions and ownerships so the web server can access this folder, if _www was the user and group of the webserver then we could do:
```
sudo chown -R _www .
sudo chgrp -R _www .
```
Finally, you would need to restart the webserver:
```
sudo httpd -k stop
sudo httpd -k start
```

Configuring your Repository

To find out how our repository is set-up without trying to understand the contents of our .git folder, we can use the git config command:
```
git config -l #lists current config settings.
git config setting_name new_value #changes a setting
```
Git will take a stab at figuring out who you are, but you will probably want to adjust the settings user.name and user.email to properly identify yourself when you commit changes:
```
git config --global user.name "Your Name Comes Here"
git config --global user.email you@yourdomain.example.com
```
You might also want to use git config to configure an upload url:
```
git config remote.upload.url http://myserver/git/myrepos.git
```
Continuing the example of the last slide, we could populate the blank server's repository with stuff we make via:
```
cd myrepos
git init
git add .
git commit -m "setting up initial repository"
git push upload master
```
This might ask for password info. If you like you can configure a ~/.netrc file to save this info. This is a file on *nix systems with the following lines:
```
machine [servername]
login [username]
password [password]
```
where you replace what's in brackets with the relevant info.

Adding, Moving Files

git doesn't manage files unless you tell git about them:

git add file_or_folder 
#folders added recursively, 
#.gitignore can be used to list files you don't want added or managed.
git clean #gets rid of files git doesn't know about
git rm file  #removes the file from the repository, with -f deletes from filesystem
git mv loc1 loc2 #moves file from loc1 to loc2
git checkout [rev] file #gets the [rev] version of the file into the current branch
#-f overwrites uncommitted changes.
# Checkout master to go back to the most recent revision

Git revision numbers are super-unmeaningful 20 byte SHA-1 hashes. Fortunately, you only need to use prefixes of a given hash number which are enough to uniquely identify a given branch.

Committing changes

We continue to look at how to manage versions of a project in git.

Adding files, removing files, modifying files, each make changes to your copy of the repository after the last revision.
This revision is called HEAD in addition to its SHA-1 name.

To make a new revision of a given branch, you use the git commit command:

git commit -m "Commit message" 
git commit -a -m "Commit message" #the -a adds any unmanaged files to the repository

The new revision will incorporate all the changes you made since the previous revision.
If you want to undo any changes you have made since the last commit, you can use the command:
```
git reset --hard HEAD
```
Commits happen locally only on your machine.
To find out information about commits you can use the "git log" command.
To find out what has changed since the last commit you can use "git status"
To see the changes between two revisions, you can use "git diff rev1 rev2"
To see who has been modifying a file, you can use "git blame file".

Branches, Merging Branches

You can find out what branches exist in your repository by typing the command:
```
git branch
```
To make a new branch you can use the command: git branch my_new_branch_name
As we said before, you use "git checkout branchname" to switch between branches.
By default, if your repository has anything in it, it will have a master branch.
To merge branch branchname with the currently checked-out branch, you can type "git merge branchname"
git will tell you if there are conflicts. "git diff" will tell you which files were messed up by the merge.
After fixing the files, to resolve the conflicts type "git commit -a".

Example resolving conflicts

Conflicts might arise on a git merge, but also might arise on a git pull. As an example, consider:

%git pull
Auto-merging tmp.php
CONFLICT (add/add): Merge conflict in tmp.php
Automatic merge failed; fix conflicts and then commit the result.
%cat tmp.php
cat tmp.php
<?php
<<<<<<< HEAD
 echo "hello";
 echo "good bye";
=======
>>>>>>> a9a8ed990108598d06334e29c0eb37d98f0845aa
?>

Here % is the command prompt.

We could edit tmp.php and fix the conflict. Then to say there were no conflicts we do:
```
git add tmp.php
git commit -m "conflicts fixed and here is a message saying how"
```

Making patches

To make a patch with git you use the command:
```
git format-patch rev1 rev2
```
By default you will get a separate patch file for each commit between the two revisions. As an example of creating a single file patch via concatenation, we could do instead:
```
git format-patch e3e4f2067 --stdout > my.patch
```
Here no rev2 is given so it will be assumed to be HEAD.

To see the effects of a patch on current branch before applying it, you can do things like:

% git apply --stat my.patch
 test1.php |    2 ++
 test2.php |    2 ++
 test1.php |    1 +
 test2.php |    2 --
 4 files changed, 5 insertions(+), 2 deletions(-)

To see if the patch will cause any problem if applied, one can type:
```
git apply --check my.patch
```
Finally, to apply a patch to the current branch, you use
```
git am --signoff <  my.patch
```
git repositories can be put on a server and made accessible remotely. This is what (Github does).
This is either done using git daemon, or using WebDAV extension to http. In either case, you can do your "git clone" with a url rather than a filesystem path.
If you've cloned such a repository, and made and commited modifications, and now want to send them back to the remote repository, you use the command "git push" or "git push remote_branch_name local_branch_name".

Git Tags

With git we often directly make tagged revision of the master branch.
The production server than does a git checkout of that tag.
To create such a tag you might do,
```
git tag -a tag_name revision -m "message about creating tag"
```
For example, in our myrepos example, we might make some changes and commit and the commit has version number. We could make a v1 tag as follows:
```
git tag -a v1 c3ac05c -m "Made Version 1"
```
"git tag -l" lists what tags one has.
By default, when you do a git push, tags are not sent. To send them, use "git push --tags"
To get remote tags into your local git instance you can do:
```
git fetch --tags
```
In our case, we could cd into myrepos2 and then type this line.
```
cd ../myrepos2
git pull
git fetch --tags
```
To checkout a tag one can do:
```
git checkout tags/[tag_name]
```
In our example, in myrepos2, we could type:
```
git checkout tags/v1
```

In-Class Exercise

Let's experiment with git.
If you don't have git installed, install it.
In a shell, make a new repository.
In this repository, add a file "hello_world.txt". Take the sentence "Hello world! Best, (your name here)." After typing each word one-by-one into your editor, make a commit (i.e., Hello [commit] World! [commit] ...).
Create a single file patch with all the changes after your second commit.
Create a version tag after the third commit.
Upload your patch and screenshot of your session to the Oct 26 In-Class Exercise Thread.

Version Control, Git

Outline