Using Git
*********

Copyright © 2013 Mattias Andrée

     Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''.

Getting started
***************

Create a repository
===================

A repository is a directory under source control, normally your project you are working on.

Create an empty directory and cd into it:

     mkdir MY_PROJECT
     cd MY_PROJECT

When you are inside the directory for the repository issus the git command to initialise the repository:

     git init

This command creates a directory namend .git inside the directory with all data git requires to operate on the repository.

The next thing you want to do is to create a .gitignore file, it is used to keep track of with files that should be be included in the repository, unless overruled with a forced staging.

A good base .gitignore content you probably always want to use is:

     _/
     # It is a good idea to allow the directory _ to
     # contain temporary file you do not whant to stage.

     .*
     # Generally you probably do not want to include
     # hidden files.

     !.git*
     # But you do generally want to include files
     starting with .git, such as .gitignore.

     \#*\#
     *~
     *.bak
     # And you do not want to include backup files.

Git parses .gitignore with wildcards, # for comments and ! for inclusion rather than exclusion, latter entires override earlier entries.

When you have create you .gitignore you are ready to stage it and make your first commit:

     git add .gitignore
     git commit -m 'first commit'

Create an origin
================

It is a good idea to create a backup repostory, so you do not lose your work on a disc failure, filesystem corruption accidental removal.

You can such repostory for allowing collaboration with a command repository that the collaborators can all submit and fetch commits from.

This repository is customarly called `origin'. And it is a bare repository, meaning that it only hold the data in the .git directory and cannot be used as the working directory.

     mkcd -p /srv/git/MY_REPOSITORY.git
     cd /srv/git/MY_REPOSITORY.git
     git init --bare

     cd -  # Go back to your project respository
     git remote add origin file:///srv/git/MY_REPOSITORY.git
     git push -u orgin master  # master is the bransh you are working in

It is standard to append .git to the end of the repository name when it is bare.

To submit your changes to origin you can now use the command git push. To fetch updates others have made, use the command git pull.

Gratis hosting
==============

As seen you do not need host, but it is a grate way for making your projects available to the world.

Here is a lost of gratis git hosting services that hosts Free Software.

* Savannah (https://savannah.nongnu.org/)
     Hosts Free Software only, and projects are audited for licensing issues upon registration. So it can take a short time before it is accepted, but you your project will not use non-Free Software and no license information will be missing. Savannah runs on only Free Software.

* Gna! (https://gna.org)
     For Free Software projects only. Gna! runs on only Free Software.

* BitBucket (https://bitbucket.org)
     Gratis for 5 uses, with unlimied number of private repositories for 5 collaborators.

* GitHub (https://github.com/)
     5 private repositories for students, for two yours and reactivatable when expired. Teachers and student organisations can get private repositories, as many as required, for an organisation.

* Assembla (https://www.assembla.com/catalog/51-free-private-git-repository-package?type=private&ad=git-wiki)
     Hosting limited to 2 GB with one free private repository for three users.

* CloudForge (https://www.cloudforge.com/pricing)
     Hosting limited to 2 GB.

You should note that there are, other, git hosting services that does not allow Free Software. Some of them will allow Open Source, some will allow Free Software, but not gratis.

Introduction
************

What is Git?
============

Git is a version control system know for its lightning speed and being distributed. A version control system is a system for storing changes in a history tree and allow for multiple people to work on the same project without the risk of the code being too new to accept a submitted patch.

When you are working it is important to keep track of changes so that you can find when edit step broke the system. But version control also lets you create branches, these are different versions of the same project being developed concurrently which lets your team implement features in parallel and merge them in into the mainline when stable.

And other important feature of version control that can be used to tag releases of the code. If you have release a program and is sent a bug report you may want to test it one both the current version and the version the user used.

It is distributed
=================

Traditionally, version control systems were centralised. Every project has one repository all contributers pushed and pulled from. Git is distributed, this means that contributers clone the respositor and words on that clone instead of ``checking out'' the current tip of the source code. This actually means that there are multiple backups of the respository is recovering a crash or corruption will be a breeze.

It is a popular misconception that distributed systems are not suited for projects that requires an official central repository. This is far from true; projects have a central blessed repository, possibly with mirrors.

A blessed repository, refered to as the upstream, is the projects official respository. Its maintained by a select few with input from submitted updates. But the upstream can also be a shared repository, this is the classical Subversion-style workflow, where everyone pulls from and pushes to. Git does not allow you to push before you have pulled to latest commit so this workflow works fine.

Small projects will usally have one maintainer and contributors clones her blessed repository and sends submissons to her. Larger projects may have multiple maintainers that helps with excepting submissons. A common model like this, that you often se on GitHub, is the integeration manager workflow, where the maintainer is an integeration manager than excepts pull requests from developers that have public repositores, often called forks (which should not be confused with a project fork where the forker is taked the project in another direction is does not requests pulls.)

Even larger project will usablly work with a dictator and lieutenants workflow where developers clones the blessed repository and submits patches to the lieutenants who in turn submits the the dictator that finally pushes the changes to the blessed repository.

Integrity
=========

Git cryptographically hashes all data associated with a commit, including the prior commit. This makes it unfeasible to modify a commit without changing the commit ID; change the commit ID brakes the commit history and would therefore get noticed as the develops cannot work against a broken commit history.

Additionally commits can be signed with GPG, so you can be sure that the commit is how is says he is.

Branching out
*************

Workflow
========

Git encourage you to create multiple local branches of you repository. A branch is a fork of your commit history, it allows you to implement features in parallel. The most important part with this is that you can fix bugs meanwhile you are working one big new features.

You main branch is by default called `master', from it, it is recommended to have a branch called `develop'. The develop branch is the branch you work on, and when it is stable, you merge it with the master branch.

From the develop branch you can branch out an create topic branches, an disposable experiments.

Creating branches
=================

The quickest way to create a new branch and start working on it is to issue a checkout command that create a new branch:

     git checkout -b BRANCH_NAME

After issuing this command you are located in a new branch. The create it in the origin, make a push:

     git push -u origin BRANCH_NAME

From this point on you can push without parameters:

     git push

The -u origin BRANCH_NAME is just to initially tell which remote repository a pushes should go to.

To switch branch use the checkout command:

     git checkout BRANCH_NAME

Merging branches
================

The merge a branch into another, switch to one of them and pull the other:

     git checkout MERGER
     git pull . MERGEE

In the default mode, git pull . MERGEE is a short and fore a fetch and merge:

     git fetch MERGEE &&
     git merge MERGEE

If you two cannot be automatically merged, you will you get a merge conflict. A case where you will get merge conflicts is when one of the branches as made a modification where the other has change the indention, so keep to a coding style from the start; or both has edited the same lines.

If you get a merge conflict, git will tell you so, in which files there are conflicts, and exit with the return code 1 to indicated that the merge was not successful and human intervention is required. If the merger branch as a file with the line Hello world and the mergee branch as the line hello world!, the file will contain:

     <<<<<<< HEAD
     Hello world
     =======
     hello world!
     >>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Where xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx is the lower case hexadecimnal represention of the commit ID at the tip of the mergee branch, which is a SHA-1 hash sum of the commit.

After a merge conflict you will need to stage the files and make a new commit.

Collaborating
*************

Cloning a repository
====================

The first thing you need to do in order to begin collaboration is the clone the repository:

     git clone REPOSITORY -o upstream

By including -o upstream, git sets up the cloned repository as a remote repository named `upstream'.

If you want to access a branch in the upstream repository, use upstream/BRANCH as the branch name.

Submitting patches
==================

The best way to create a patch is with Git's format-patch command. Assuming you began from upstream/master:

     git format-patch upstream/master

This command with create a patch whose name will be printed by git format-patch.

Creating a patch this way will keep track of the commit messages, and the individual commits. Another advantage with it is that it can easily be submitted to a mailing list, which the common way for large projects for accepting patches.

The created patch file is formated as an e-mail, with `[PATCH]' in the beginning of the subject line. If you update the patch it is customary to use `[PATCH v2]' instread and `[PATCH v3]' on the second update. If the patch, however it not readly for being included, but is rather for discussion, use `PATCH/RFC' (RFC is an abbreviation for `Request for comments') instead of `PATCH'.

To send the patch, use git send-email:

     git send-email --to=EMAIL_ADDRESS_TO_SEND_TO PATCH_FILE

If you have registered to the mailing list, or for some other reason, want to send under a different e-mail address then you made the commits with, you need to specify an envelop send, by adding an option:

     --envelope-sender=SENDER_EMAIL_ADDRESS

You will also need the specify which SMTP server to use, authorisation and configurations:

     --smtp-server=DOMAIN    # it usally is prefixed with smtp.
     --smtp-server-port=PORT
     --smtp-encryption=ssl   # or tls
     --smtp-user=ACCOUNT     # usally just the username without domain
     --smtp-pass=PASSPHRASE

If you are using a forwarding e-mail, such as @member.fsf.org, you send from using your normal e-mail, but use the forwarding e-mail address as the envelop-sender, most e-mail server should accept this.

If you are replying to a message in the mailing list, perhaps with an updated patch, you should specify the message ID of the message to replay to. This done my adding the option:

     --in-reply-to=MESSAGE_ID

To get the message ID, open the message in your e-mail client and choose to see all headers --- if not possible: download the it as an mbox file and open it in an text editor --- a look for:

     Message-ID: <MESSAGE_ID>

As indicated here, it is surrended by less than and grater than-signs. You should, if you have subscribed to the mailing list, have gotten it send to your e-mail. If you do not have it, go the the mailing lit and click that you want to reply, it will open your e-mail client in compose mode and the in-reply-to address will have been set to the proper message ID.

Accepting patches
=================

To apply a patch, use the git am (`am' stands for `apply mailbox', but it words on regular patch files) command:

     git am PATCH_FILE

Is good practice to sign off commits to help establish a chain to trace submissions, and some projects will require it. To sign off with git am, just add --signoff.

Making pull requests
====================

A less feature rich alternative than patches are pull request, but they are easier to just because you do know need to know anything to make a pull request and to accept them you just need to know how to pull from other repositories.

Git does however provide a command the produces a clean standard message than can be posted on a mailing list. To do this just type:

     git request pull FORKING_POINT_COMMIT YOUR_URL

Additionally you can add a commit that the pull requests stops at, if you have another commit than HEAD --- the current commit you are working at --- in mind. You can also add -p if you want to see the changes.

Basic commands
**************

The trees of Git
================

Git has four trees should know about to better understand how Git works.

The first tree you encounter is the working directory. The tree begins in the parent so called git directory; the directory you executed git init in, and contains the directory .git.

When you are using git add to stage files you encounter the next tree. This tree is called the index, and is separate from the working directory, when you stage a file, you stage an edit, if you edit the file further those changes does not make it into the index until you restage the file.

When you have done some work --- just a small logical step is recommended --- and want to save your changes you commit then with git commit. This is when you encounter the third tree, the HEAD. HEAD is the file tree of the last commit, and it is updated when make a commit.

The fourth tree is not a file tree, it is the commit tree. The important thing with Git is that this tree is not linear, it is a directed acyclic graph, so it is not really a tree, but you can think of it as one because you are normally only interested in the leaves, your branches.

File operations
===============

Their are four basic options you can do on files: add, update, remove and rename, adding and update is done with the same command:

     git add FILE

To remove a file or rename a file, just do as you normally would without git, but prepand git:

     git rm FILE           # Remove FILE
     git mv FILE NEW_NAME  # Rename FILE to NEW_NAME

If an directory in becomes empty in the working directory it is automatically removed from working directory. And directories are never tracked by Git, so you cannot have an empty directory in a commit.

You can also use git add -u (-u is the short option for --update.) to stage an edit in an already tracked file or stage the removal of it if it as been removed from the working directory.

A caveat with git mv is that is that is that same thing as typing:

     cp FILE NEW_NAME
     git rm FILE
     git add NEW_NAME

In other words, the history for the file is reset and if you do this at the same time someone edits the file you will get a merge conflict.

This is not a problem with GNU Arch because it keeps track of which file is which by giving it an unique identifier, and you may think that would have been a good think. But if the content of the file depends on the file's name, or the other way around, and a line with such dependency is added, the file's content would become bad. Well it is debatable since the case could be that another file depends on the renamed files name, and someone could make a change in that file. But fixing a merge conflict when you have only renamed the file is not too hard and it eliminates a potatial maintenance miss.

If you want do know the file staging difference between the index and working directory type git status.

Go back in time
===============

Because git keeps track of what has changed it has a log you access, which has commit messages, so you know when something has happend or what has happen lately. To read the log type:

     git log

If you want to know which files have changes, you can use git whatchanged instead.

If you want to take a closer look a commit an see the state of the project at the commit type:

     git stash               # Only if you have uncommited changes, this
                             # saves you changes outside the tree in a stack.
     git checkout COMMIT_ID  # Take a look around!
     git checkout -          # Checking out - means that you checkout the
                             # commit you were on before the last checkout.
                             # Kind of like `cd -'.
     git stash pop           # Only if you have uncommited changes, this
                             # reapplies the changes you saved with `git stash'
                             # and removes it from that stack.

If you instead what to see all changes from that point of time type:

     git diff COMMIT_ID

Or for a specific file:

     git diff COMMIT_ID FILE

If you decide that you want to go back permanently to this state you type:

     git revert THE_COMMIT_ID_OF_THE_COMMIT_AFTER_THAT_COMMIT..HEAD

If you have not push the commits you want to revert you can do a reset instead, thay way the are irreverable removed instead of a new commit being made:

     git reset --hard COMMIT_ID

But you should think of that as running as root:

Chris: root is the number zero user, it is main user in your system, it can do everything, it can literally delete the filesystem while your operating system is running.

Bryan: Yeah, it is a grate user in that regard.

Chris: Yeah. Yeah.

Bryan: Here is the thing, so people always say `do not run as root.' I always run as root.

Chris: Do you really always run as root?

Bryan: Hell yes. Do you know why I always run as root?

Chris: Why?

Bryan: Awesome.

Chris: Here, I... <interrupted>

Bryan: I live on the edge. I'm like Mad Max. <Saying something but Chris is louder.>

Chris: Do you really always run as root for real?

Bryan: No, I do not run as root. Are you kidding me, that is asinine! I would love to think that I am so hardcore that I just always ran as root. I just, caution to the wind, screw it, lets just thunderdome this bitch and... you know, see what happens. But no, never run as root, never ever do that. The only time you run as root is when you run as root temporarly, you sudo.

Chris: You need to do something.

Only use reset if you are absolutely sure and know exactly what you are doing.

I just don't know what went wrong
*********************************

Naïve reset
===========

If something went horribly, horribly, horribly, horribly wrong and you do not know how to get back to a clean state, you can always doing this naïvely by clone the repository:

     git clone REPOSITORY REPOSITORY.new
     cp REPOSITORY/.git/config REPOSITORY.new/.git/config
     yes | rm -r REPOSITORY
     mv REPOSITORY.new REPOSITORY

Using the stash
===============

The stash is a grate utility for storing changes. If you have made changes in the working directory or the index, you can store them in the stash and both the working directory and the index will be restored to the HEAD. Keep in mind the the naïve reset will discard the stash because the stash is local. Changes stored to the stash can be applied to any branch and any later state of the HEAD, that is what the stash is made for.

The basic stash operations include:

git stash
     Store the changes made to the index and working directory.

git stash drop
     Discard the object at the top of the stash stack.

git stash apply
     Apply changes stored as the object at the top of the stash stack.

git stash pop
     Synonym for git stash apply && git stash drop.

git stash clear
     Discard all stored stash objects.

Commit amendment
================

If you have not yet pushed your latest commit you can amend it. If you have pushed it, you cannot amend it cause the commit ID changes because it is SHA-1 hashsum of all imformation.

To amend your commit run git commit --amend. It will launch your text editor so you can edit the commit message, additionally all staged changes are included in the amendment.

Bisection
=========

Bisection is the process of identifying when a bug was introduced.

To start a bisection you first need to tell git to start bisection and specify the commit range. If the current commit is bad you type:

     git bisect start
     git bisect bad
     git bisect good LAST_KNOWN_GOOD_COMMIT

After this you either of, depending if the commit Git checks out is good or bad:

     git bisect good
     git bisect bad

Git will tell you when it has found the the first bad or possible first bad commit. To then checkout the commit that was checked out before the bisection started type:

     git bisect reset

If you in the process of the bisection landed on a commit you need to skip because it has some other problem, you can use

     git reset --hard HEAD~N

Where N is the number of revisions before the checked out, you want to jump to. You can also use git bisect skip to Git which revision that cannot be tested so they are excluded from the bisection process.

Instead of manually telling Git if a commit is good or bad, you can use:

     git bisect TEST_SCRIPT [ARGUMENTS...]

The test script should exit with 0, if and only if the commit is good, 125 to skip the commit, and anything else between 1 and 127, inclusively, if the commmit is bad. Other values (128–255) will abort the bisection.

GNU Free Documentation License
******************************

     [file fdl.texinfo not included]