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

Identify yourself
=================

The first thing you want to do right off the bat is to identify yourself: add your name and e-mail address to your Git configurations. This is done with two simple commands:

     git config --global user.name 'YOUR NAME'
     git config --global user.email 'YOUR_EMAIL_ADDRESS'

It is possible to sign your work with GPG. If you are planning on doing this, and doing this with another GPG key then your default key, you can configure Git to using another key by default:

     git configre --global user.signingkey YOUR_GPG_KEY_ID

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 want 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 created your .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 or accidental removal.

You can ushe such repository for allowing collaboration with a common repository that all collaborators can 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 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 users, 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.

Generate your key
=================

Many Git servers authenticate using public SSH keys. If you do not already have SSH installed, install it, it is probably named openssh in your GNU/Linux distributions' package repository.

Before create an SSH key, check if you already have one. You are looking for a pair of id_rsa.pub and id_rsa, in ~/.ssh. id_rsa is your private key and should not be shared or made public. id_rsa.pub is you public key and is the file you want to upload you your Git hosting server.

If you do not already have a key, you can create it with:

     ssh-keygen -t rsa -C 'YOUR_EMAIL_ADDRESS'

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

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

Git is a version control system known for its lightning speed (Especially under POSIX compatible systems.) 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.

Online documentation
====================

As with most software packages, Git includes online documentation, accessible in several ways. The simplest way, this will working on all systems is by add --help to the command git or git VERB.

Git is a project started by Linus Torvalds, the creator of the Linux kernel, so naturally it has manpages, but not any official info manual. Since info supports manpage you can use info in place of man.

Git includes several manpages, one manpage for every Git command: man git VERB or alternatively man git-VERB, and manpages on special topic:

  * man git

  * man gitattributes

  * man gitcli

  * man gitcore-tutorial

  * man gitcredentials

  * man gitdiffcore

  * man gitglossary

  * man githooks

  * man gitignore

  * man gitmodules

  * man gitnamespaces

  * man gitrepository-layout

  * man gittutorial

  * man gittutorial-2

  * man gitworkflows

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

Workflow
========

Git encourage you to create multiple local branches of your 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 works 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 prepend 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 information.

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

Version control
***************

Tagging versions
================

General, programs have different release version. When you release a new version, you tag the last commit makes it into that version. To do this, create an annotated tag object and push it to your origin:

     git tag -a 'RELEASE_VERSION'
     git push origin 'RELEASE_VERSION'

The created tag can be refered to as any commit or branch.

If you want to remove a tag, you just tell Git to delete it and push the deletion of its reference to your origin:

     git tag -d 'RELEASE_VERSION'
     git push origin :refs/tags/'RELEASE_VERSION'

refs/tags/RELEASE_VERSION is a file in the .git directory. Using a : tells Git that you want to push the local file before the : to the remote file after the :. If the local file is not specified, in order words, the argument begins with :, you are telling Git to remove the remote file. This only work with referense, that is, files inside .git/refs.

Cherry picking
==============

Cherry picking is the action of applying changes made in another commit. It is a create tool both for apply changes made to another branch or to backport features.

Cherry picking works just merging branches, except, instead of choosing a branch to pull and apply all it changes you choose individual commits, and commits ranges:

     git cherry-pick COMMIT_ID

Examine the log
===============

So how are you going to cherry-pick commits if you do not know their commit ID:s? Simple, you use Git's log tool to find their ID:s.

The log will only show earlier commits in the branch then the currently checked out commit. Typing git log will show you the commit's ID, author, date, and commit message. You can limit the commits to a commits where specify files has been changed by appending those files to the command.

Interface
*********

First things first
==================

Many Git commands take both revisions and paths as their arguments. First come the revisions, then the files. If you have files that can be misunderstood for a revision, place a -- between the revisions and the files, anything after a -- is interpreted as a file. It is a good practice to do this in scripts that takes random user-input.

Wildcards
=========

Many Git commands allow wildcards in paths. These commands will expand wildcards in the arguments just a the shell. To avoid problems, never use characters in paths that are used in the shell for wildcards and expansions… yeah, I know, it is annoying.

Features
********

Git and permissions
===================

File systems lets you set permissions for users on files. Permissions, such as whether the owner, a specific user group, or others, can read, write or execute the file as well as whether the permissions of the owner if the file is granted the execute instance of the program for further permissions that are mission critical.

Tracking permissions in version control system makes no senses since source code should always be readable and writable by the owner and it is local configuration whether you want to extend those permissions to other users on your computer.

However there are source code that is executable, scripts, such as Bash, Perl and Python. This is may Git does however track the execution bits. The set-user-ID bit and the set-group-ID bit is however not tracked, nor should they, those should only be set when the program is being installed.

Git does not track directories, so permissions no directories are also ignored.

Be aware that some systems sets the execution bit willy-nilly when a file is created.

This is a shortcoming of Git, but only in comparision to darcs. Since files are only executable if they are compiled or have a shebang, it would make more since so set it on and only on the files with a shebang or otherwise tagged to how a specific permission.

Additionally Git does not track file ownership --- that would not only be stupid, that would be outright dumb, even moronic ---, access control lists, extended attributes nor forks.

Git and timestamps
==================

One of Git's features is that it does not have the feature (Yes, that it does not have it. Do not be confused, not have features are often grater features.) of perserving timestamps.

Perserving modification time on files is considered harmful. Consider if Git were to perserve the modification time. If you have compiled the program, and then checkout en earlier commit, perhaps another branch, and you build it again, now your compiled files from the other branch has a newer time stamp then the source in the current branch and the files will not build unless you force them to build, which you more than likely will forget. So you may observe a behaviour of your program that is not defined by the checkout source code.

This is way Git sets the timestamp to the current time on every file it modifies, but only those. Files that have not changes will not change timestamp so the build system will not rebuild them unless there is some other reason it needs to.

Git and custom merge tools
==========================

Git lets you use custom automatic merge tools. This can be used, for example, to merge binary file formats. It is possible to use a merge tool to required human interaction, however, this is discouraged because than the commit history will have no indication that there was a merge conflict. You can use a merge tool that tries to merge and marks all conflicts, and then manually use a tool the lets you see the conflicts and resolve.

Git and shared build caches
===========================

A few set source controls systems have shared build cache of derived objects. Git does not. Build cache, private or public, is none of source control systems' concern and should be handled with tools made specifically for just that.

Git and keyword expansion
=========================

About half of all source control systems supports keyword expansion. As a feature, Git does not. Keyword expansion causes strange problems and is not really useful. Nor it is a true task for source control systems to implement, If can as successfully be implemented with external tools, where it belongs.

Git and links
=============

A Git repository will not grow larger if you hard link a huge file over and over again, not that you would ever want to… However Git does not actually track hard links.

Git supports symbolic links, and stores the exact reference stored in the symlink, it is not resolved or otherwise rewritten, so make short you use relative references in your symlinks.

Git and filenames
=================

Git treats filenames as byte sequences, meaning that if it supports all characters supported by your file system, including one developers operativing systems uses UTF-8 and the other's uses UTF-16, or only ASCII, there will be problems. Will it is true that systems really should use UTF-8, be case sensitive and support the entire Unicode, even characters that are not yet defined with use of all 31 bits (Yes Unicode supports only up to 31 bits, so negative ordinals can be considered process private use.) except the NUL control character, you may consider just using lower case ASCII and be friendly to other systems on use a very restricted set of punctuation and no control characters.

Git and merge tracking
======================

Git takes history seriously, therefore when a merge is made, even if it can be automatically fully merged, a commit it created. This is very useful is keep track of changes and identifing and resolving evil merges. If you are inclined to shoot your self in the foot you can always rebase your repository so that merges are not created.

Git and empty directories
=========================

Git does not track empty directories, it even removes them for you when it remove all files in a directory. Basically there is not reason to track directories, ever, but if you are so inclined you can add a .gitignore file inside it.

Git and encoding convertions
============================

Git can keep track of encoding for commit metadata. Git does however not convert file content, if your are indeed inclined to want to shoot yourself in the foot a filtering mechanism can be used.

Git and atomic commits
======================

This might seem obvious, but CVS, ClearCase and Visual SourceSafe does not implement this; atomic commits. Atomic commits refers to a guarantee att an action cannot be interrupted and leave in a partially complete state but be marked at complete, either all changes are made or none at all.

Basically this means that first you backup the reference to the current commit, mark a file as a commit is being saved, store the new commit, update the reference to the current commit to point at the new commit and then mark that no commit is being saved. If the mark is then detected to say that not commit is being save but instead absolutely anything else, restore the state in the same manner.

Beyond Git
**********

Additional tools
================

Git is used for source control, for a complete, possibily collaborative, development environment you need additional tools.

Everything Git can do, you can do in the command line, but some repetitive gets cumbersome in the command line because you will need to run the same command in unpredictable variations. For this the package and command tig may be just want you need if you live in the terminal.

bugseverywhere is a grate tool for keeping track of issues in Git repositories. Issues are commited to the current branch you are working on, meaning that you can have separate issues in separate branches. So if you have separate branches for separate features that are being implemented you can create separate issues inside those branches. And when a branch get merged with your develop branch the unresolved issues is merged into the develop branch.

If you are working on a large project with multiple collaborator and contributors, and you have dedicated hosting serve, you can install Internet services that can assist collaboration and especially contributors.

  * Flyspray is a web-based project management and issue tracking system used by many projects

  * GNU Mailman is a projcet for managing electronic mailing lists which can be very useful for accepting patches.

  * newsd is standalone NNTP server for centralised newsgroup forum serving on a single server, which can be very discussions.

All of these programs, as well as Git, are released under the GNU General Public License, except Flyspray which is released under the GNU Lesser General Public License.

The binary problem
==================

Source control does not work well with binary files. Consider that two persons are edition the same file which cannot be interpreted by a human using a text editor. If there is a conflict, Git may not realise it depending on the binary format, or may not be able to merge the changes. If Git cannot merge the and you cannot open it in a text editor, you will not a file you can open and se the conflicts in so you must open both's versions and manual inspect and merge them.

Perhaps you plan to work alone and never ever get another developer on your project and are not convinced that merge conflicts reason enough to work text based formats. Than consider that you need to know the exact changes of commits; the Git log will not be able to help you if you are using binary formats.

Luckily most type of files formats have an text based alternative.

Raster images
     Portable pixmap (.ppm, .pgm, .pbm, .pnm) is a text based (Optionally partially binary.) image format that is supported by The GNU Image Manipulation Program (GIMP).

Vector images
     Scalable Vector (Yes it is redudant, but that is really what it is called.) Graphics (SVG) is the most popular vector image format, and in fact it is text based, more precisely it is XML based. Will you may not be able to view an SVG file with merge conflicts, you are still able to open it in an text editor and fix the conficts. However it may not be the simplest thing to resolve in a text editor it helps you to identify where the conflicts are located in the graphics.

Documentation
     Texinfo and TeX are two very popular alternatives to word editors such as Libre Office.

     Texinfo is designed for manuals and books, and can be compiled to virtually any publish format, including info manuals, Hypertext Markup Language, Portable Document Format and PostScript.

     TeX is more general purpose (Texinfo is actually a macro set for TeX.) has extensible and redefinable syntax and is written to guarantee that one source will always and everywhere produce the exact same binaries, in terms of hows that look when viewed. Its macro set LaTeX is the prefered office system in academia.

Writing commit messages
=======================

Commits are accompanied by messages. This both helps yourself and other developers to identify a specific commit of interest, as well as giving information about what is happening in the development process, so every developer can keep up to speed.

Commit messages can also be used to create changelogs, where you create a change log from the commit history and filter out unimportant changes.

Change logs and commit massages are generally written on the same style. A short message written in imperfect, optionally with additional larges paragraphs that goes more in depth.

Even if your project is not in English it is preferable to keep your commit message as well as much as possible of your project (that is not visible to the user) in English. Assume your project is in Swedish, everyone that understands Swedish will be able to translate it to any other language. So far it would be okay to write anything in Swedish, but once it has been translate, for example to English, additional translators that do not understand Swedish can contribute with additional translators. Now it is perferable with English, while the translators can understand everything that are should translate they do not understand anything else. When translating a program it useful to be able to understand what the program does and not just want it prints so you can do more accurate translations, and sometimes just one translation is not enough to have en unambiguous understanding.

It is preferable to commit as often as possible, however this interrupts your mind flow, so committing should take as short time as possible (Git is very friendly in this respect as create a commit is lightning fast, and photon fast in comparsing to other old school source control systems.). Because of this you may need to compromise your messages, one thing you can do is to not describe a fix bug if it should be obvious for the changeset (Can only be obvious from small changes.), after all if you do not understand a change you can always ask someone. Another thing you can do is to use some standard shorthands.

m
     Minor change.

doc
     Add or change documentation.

typo
     Fix a typo.

spello
     Fix a spello.

grammaro
     Fix a grammaro.

ref
     Abbreviation for reference.

conf
     Abbreviation for configuration.

misc
     Abbreviation for miscellaneous.

+
     As well as, another logical change in the same commit.

If you want shorten the time it takes to create a commit, I personally recommend to have a short shell function for opening your text editor and stage the openned files when the editor exits. And create a shell function the runs git commit -m "$*".

Standard files
==============

All projects should have a set of files:

README (optional)
     You should have a readme file at the root of your project. It should describe the project and how the program is used.

DEPENDENCIES (optional)
     If your program has other dependencies than a compiler, linker, interpreter, libc, coreutils and similar standard packages, and make tools such as make and automake. You should have a file that list all dependency: runtime dependencies, optional runtime dependencies, build dependencies, opt-out build dependencies, opt-in build dependencies. Try to specify version range and what the package is used for, especially for optional dependecies.

INSTALLING (optional)
     For more advanced build systems you should have a file that specified how to configure the building process.

CONTRIBUTING (optional)
     If your have rules on how to submit patches, code style guildlines, or other information for contributors, you should have files with all such information in the top of your repository.

HACKING (optional)
     For complex project you can have a file named HACKING with information about how to modify the code.

COPYING
     When you make your project available it is not longer private software and you need to give it a license compatible with its dependencies. If you do not have a license it defaults to being proprietary. The copying file includes the license summary or the complete license text if it is short, and at the top, the project name, short description, years of active development, and copyright holder name and e-mail address. It is the same text as the copyright information you put at the top of source code files.

LICENSE
     If the projects license is large, you put the fill license plain text in the file named LICENSE in the top if your repository.

Keeping the repository clean
============================

Keeping repositories clean is instrumental in making it easy to maintains and simple for new contributors to get started. Do not commit binaries to repository, it should only contain source files, this means that you do not commit the program precompiled, libraries the project is using and integrated development environment (IDE) files. You can however make exceptions for precompiled not-programs that are compiled by your build system if you think it is useful enough for users to be available precompiled. For example you can have a manual precompiled.

Your project can include directories such as:

bin
     This directory should not be committed, rather it should be ignored and be created when compiling the program, it should include linked files such as commands, .so-files and .jar-file.

obj
     This directory should not be committed, rather it should be ignored and be created when compiling the program, it should include compiled but not linked files such as .o-files and .class-file.

src
     Put your source code it this directory.

dev
     Auxiliary files and scripts used by developers, such as code self tests, bisection commands, and resource file inspection scripts.

contrib
     Personally, I do not like this, but you can use it for additional source that is not required for the core of the package.

dist
     If you are maintain package distribution if your package of an operativing system distribution, you can have directories named dist/DISTRIBUTION for each distribition. You may want to do this this way because than other users can look at it and start maintaining package distribution of your package of the operativing system distribution they are using.

share
     If you have of the following directories, you can put all of them this directories instead of in the root.

completion
     All commands such have shell tab-completion, if you are writing them individually for each shell you can place them in this directory.

manuals
     If you write manuals in multiple formats you can place them in this directory.

info
     Every project should be well documented, if you are this with texinfo, you can put you texinfo files in this directory.

man
     If your project have manpages, you can place them in this directory.

po
     Programs that used gettext for translations can place the translations in this directory.

*
     Resource files can be places in a directory named after their category.

A friendly build system
=======================

`So I should not include project metafiles use by my integrated development environment?' No when you are doing that you are binding everyone to your environment and you do not provide everyone with a way to build your package. Every package should be buildable with a small set of commands that do not require human interaction beyond type them in a simple predictable manner in the command line, ther is very important for package distribution. To make possible for everyone to build your program you can use GNU Autotools or just a simple handwritten make file.

Additionally such a build system lets you provide means to configure and customise the build process as well as installing and uninstalling (without using package management) the program. Further, it allows you to compile individual files and clean the directory from all compiled files.

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

     [file fdl.texinfo not included]

Glossary
********

alternate object database
     A repository can inherit part of its object database from another object database, which is called ``alternate''.

bare repositry
     A bare repository is a repository without an index tree or working tree. It just contains the commits. Because it just contains the commits it does not have a .git directory, but instread directly contains the content you would find in a .git directory. If is normally named with .git is a suffix.

blob object
     Untyped object, for example, the contents of a file.

branch
     Alternative parallel development line, normally indended the be merged with the branch it forked out of.

cache
     Obsolete, replaced by ‘index’.

chain
     List of objects where each object has a reference to the next object, its successor.

checkout
     The action of changing branch.

cherry-picking
     Creating a new commit from a subset of commits.

clean
     A working tree is clean if has no changes relative to the current HEAD

commit (noun)
     A single point in the development history stored in Git. The entire history of a project is represented as a set of interrelated commits.

     Alternatives to Git may use the terms `revision' or `version' instead of `commit'. `Commit' is also used as a short and for `commit object'.

commit (verb)
     The action of storing a new snapshot of the project's state. The state of the index is stored and HEAD is advanced to the new commit.

commit object
     A Git internal object which contains the information about a particalur revision. It contains informations such as author, commiter, date, files and parents.

core Git
     The fundamental tools of source code management.

dangling object
     An object that is not reachable, even from other unreachable objects; there are not references to it.

detached HEAD
     HEAD that does not store the name of a branch. Git allows you to checkout arbitrary commmits, when you checkout a commit that is not the tip of any branch, the HEAD is ``detached''.

     To store changes make in a detached HEAD you must first create a new branch from it.

directory
     You may also know it as `catalogue' or even `folder'. It can contain files and other directories, which you can list with the command ls and you can change directory with the command cd.

dirty
     The working tree is dirty if it contains uncommited modifications.

evil merge
     A merge that introduces changes that do not appear in any parent. Variable name conflicts can be a cause of evil merges. This is why you do not rebase your commits.

fast forward
     The action of doing a fast-forward merge, a pull for updates when Git branch is just behind, not diverged.

fast-forward
     A special type of merge that will often be the case when you pull updates from a remote repository. A fast-forward merge is a merge where you have made no changes but there are changes on the remote-tracking branch that can be pulled without any merge logic.

fetch
     When you fetch a branch's head ref from a remote repository, you download, to a local database, objects that have not yet been downloaded.

gitfile
     A plain file named .git located in the root fo the working tree, that points the to real repository. The is a create idea to use this if you do not want a backup repostory as it prevents you from accidentally remove anything but the working tree.

grafts
     Two different development lines can be join together by recoding facke ancestry information. This is configured via the .git/info/grafts file.

hash
     Especially if cryptographic, almost unique, indefeasibly reverable, fixed size, scrambling of content. In Git's context, synonym for object name.

head
     A named reference to the commit at the tip if a branch.

HEAD
     The head of the currently checked out branch, or the currently checkout commit in which case the HEAD is ``detached''.

head ref
     Synonym for `head'.

hook
     Several Git commands make callouts to user definable scripts. This allows developers to add functionally or checkout, and commands can be verified and aborted.

     .git/hooks are filled with sample scripts that can be enabled by removing their .sample suffix.

index
     Snapshot of the working tree intended to be promoted to a commit.

index entry
     The information regarding a particular file that is stored in the index

master
     Unless set otherwise, the default branch in a repository. It is created with the first commit in the project.

merge (verb)
     The action of integrating the commits for another development branch.

merge (noun)
     A commit the is created when merging a branch into another.

object
     The unit of storage in Git. It is identified by the SHA-1 hash of its content.

object database
     Stores a set of Git objects.

object identifier
     Unique 40 character hexadecimal identifer of an object, derived from the objects content, by hashing with SHA-1.

object name
     Synonym for object identifier.

object type
     `Commit', `tree', `tag' or `blob'.

octopus
     The action of mergin more than two branches.

origin
     The default repository to push to, the one you cloned.

pack
     A set of objects that have been compressed.

pack index
     A list of metadata for objects in a pack, to speed up access time of individual objects.

plumbing
     The fundamental tools of source code management. Low-level commands.

porcelain
     High-level commands.

pull
     The action of integrate new commits from another branch, often a remote-tracking branch.

push
     The adcttion of sending updates to a remote repository.

rebase
     The action of rewriting history by pretending that you pulled updates before committing.

ref
     SHA-1 hash or name of a particular object.

refspec
     Description of the mapping between ref and local ref. Used by fetch and push.

resolve
     The action of manually merging the parts the tool could not automatically merge.

revision
     A commit.

rewind
     The action of throwing away part of the development.

SHA-1
     Secure Hash Algorithm 1, a cryptographic hash function used by Git for object names. It is the fastest secure hash algorithm around, bit is is also quite old.

shallow repository
     A repository with an incomplete commit history.