Committing changes

On Monday, we introduced Git as a version control system for our projects. Today, 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".

Let's Experiment

If you don't already have Git, you can download it from https://git-scm.com/.
For this let's experiment, create a fresh git repository in a folder my_fresh_repo. Make a file test.txt with the letter a in it.
Add this file to your repository and make an initial commit.
Do the following three times: Reopen the file add to the end of it, the letter a. Commit this change.
Make a patch from your second commit to HEAD, and post it as your solution to the Oct 26 Let's Experiment Therad.

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
```

Issue Tracking

Typically, you would post patches you make to some kind of bug/issue tracking tool for review before they are checked-in.
Some popular Bug/Issue tracking tools are: JIRA , Bugzilla , Trac, MantisBT .
Here is a list of other tracker that exist: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
GitHub comes with its own lightweight issue tracker for each project and has its own wiki. If you spot a bug or see an issue you would like to solve you just click on the issue link and write up a description of it. People can follow up on your description and if it is eventually solved then close the issue.
For each project GitHub also has a Wiki which can be used to describe things like how to compile the project etc.

GitHub

GitHub is a web-based hosting service for git repositories.
It was launched in 2008 and according to Wikipedia has around 14 million users and as of today hosts more than 35 million repositories.
It was originally written in Ruby (using Ruby on Rails) and Erlang. Information about its infrastructure can be gleaned by following the Github Blog Engineering Category.
GitHub hosts two kinds of repositories public and private. Here is a link to Details on GitHub plans.
GitHub recommends repositories be less than 1GB and not have many files bigger than 100MB.
Public repositories are free and are viewable by anyone.
Private repositories can be limited in who sees it but cost money.
The Cinequest project is hosted on various public repositories -- one for iPhone, one for Android.
Cloud services like GitHub can be cool -- just be sure to always keep your own copy of the data.

Getting started with GitHub

To use github you should at a minimum configure in git your username and email:

git config --global user.name "YOUR NAME"
git config --global user.email "YOUR EMAIL ADDRESS"

Here is what an example git repository might looked like:
Notice there is the HTTPS and url. This can be use to git clone this repository.
If you want to start your own repository, when you log in to GitHub on your profile page, you'll see at the top a bar like:
You can select the plus icon, click create new repository, and follow the directions.

GitHub Work Flows

GitHub itself has pretty good tutorials on how to Create a GitHub Repository and Fork a GitHub Repository.
The basic workflow for working with an existing git repository on GitHub is to go to that repositories page, and
- Click the Fork link.
- Get a local copy of the fork, work on it, either within GitHub's online editors or on your local machine, commit changes. If not already, get those changes push'd back to your local copy.
- Initiate a pull request back to the original repository.
- The owner of the original repository then decides if they want to accept or not the pull request.

GitHub Work Details -- Getting a copy

In details what happening, is clicking fork gives you a copy in your user account space of that repository. For example, the original repository might have been:

https://github.com/ORIGINAL_USERNAME/PROJECT.git

your fork wil be

https://github.com/YOUR_USERNAME/PROJECT.git

To get a copy on your laptop of your fork, you just clone that address:

git clone https://github.com/YOUR_USERNAME/PROJECT.git

To make sure you can stay in sync with the original repository we need to add an upstream source for our clone:

git remote add upstream https://github.com/ORIGINAL_USERNAME/PROJECT.git

GitHub Work Details -- Working locally, Synchronization, Pull Requests

After making a local clone we can make changes, commit them, and use
```
git push origin master
```
to send them back to GitHub in our workspace on GitHub.
Periodically, we should synchronize with the upstream source:
```
git fetch upstream
```
then check out our local branch
```
git checkout master
```
and finally merge changes (we might need to resolve conflicts like described earlier)
```
git merge upstream/master
```
To make a request of the original project to get your code incorporated in it involves make a pull request. This is pretty straightforward and can be done in a GUI. Here are GitHub's Pull Request Instructions
Similarly, for the project maintainer to merge in a pull request can also be done via GUI. Here are GitHub's Merge a Pull Request Instructions.

Finish Git, Github

Outline