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

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

Let's Experiment

Create a git repository containing your HW2 code.
Make a clone of this repository.
Change the title of the analytics/index.php file in the cloned repository.
Commit this change.
Make a patch of the difference between this change and the original repository.
Apply the patch of this change back to the original repository
Post the patch you made and a transcript of the applying it to the March 16 Thread.

GitHub

GitHub is a web-based hosting service for git repositories.
It was launched in 2008 and currently has between 3-4 million users and as of today hosts more than 15.6 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.

Our Website Design Paradigm So Far...

Our basic set-up for website interaction so far is:
1. User comes to initial page of web-site.
2. Default web page (the landing page) for the site is served, either using a static HTML page or a with minimal PHP intervention.
3. The user clicks links or enters form data to navigate around the site.
4. No dynamic processing happens on the client.
5. On the server, a controller processes the link or form data, uses session information, gets/sets database information using models, and chooses a new view to display.
In choosing for a form whether it should use method GET or POST, ask whether the result of processing the form data should be a bookmarkable location?
If it can be, use GET; otherwise, POST.
For forms that do things that we don't want to be repeatable with the same information, like purchasing items, posting comments or blog entries, etc., we should use POST.

POST REDIRECT GET

When you click the reload on a page that is the result of a POST'd form, or use the back to cycle through pages where forms were POST'd, your browser will typically ask if you want to resubmit the form data.
Not only is the back button, somewhat broken by this, people have a nasty habit of clicking okay on any dialog box that pops up, which can result in a re-purchase, re-blog post, etc.
To solve this problem, we use a web design pattern known as POST-REDIRECT-GET.
The idea is when POST is used for the form:
```
<form method="post">

<input type="submit" name='submit button' value='submit' />
</form>
```
we process the data in the receiving controller. Rather than choose a view and display it, we instead, output a 301 redirect, location header to some safe page. In PHP, we could do this with a line like:
```
<?php
header("Location:http://somewhere.safe.com/");
```
When the browser, goes to http://somewhere.safe.com/, it will use GET to request the page.
Because the POST'd form data resulted in a redirect, the get location only is stored in the browser history. So now going back through the history using the back button will go through this same page and before this the page where the form was initially blank.

Finish Git, GitHub, PRG, Javascript

Outline