\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename using-git.info
@settitle using git
@afourpaper
@documentencoding UTF-8
@documentlanguage en
@finalout
@c %**end of header
@dircategory Version Control
@direntry
* using git: (using git). Using the Git source control management
@end direntry
@copying
Copyright @copyright{} 2013 Mattias Andrée
@quotation
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''.
@end quotation
@end copying
@ifnottex
@node Top
@top Using Git
@insertcopying
@end ifnottex
@titlepage
@title Using Git
@author by Mattias Andrée (maandree)
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage
@contents
@menu
* Getting started::
* Introduction::
* Branching out::
* Collaborating::
* GNU Free Documentation License::
@end menu
@node Getting started
@chapter Getting started
@menu
* Create a repository::
* Create an origin::
* Gratis hosting::
@end menu
@node Create a repository
@section Create a repository
A repository is a directory under source control,
normally your project you are working on.
Create an empty directory and @command{cd} into it:
@example
mkdir MY_PROJECT
cd MY_PROJECT
@end example
When you are inside the directory for the repository
issus the git command to initialise the repository:
@example
git init
@end example
This command creates a directory namend @file{.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
@file{.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 @file{.gitignore} content you probably
always want to use is:
@example
_/
# 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.
@end example
Git parses @file{.gitignore} with wildcards,
@code{#} for comments and @code{!} for inclusion
rather than exclusion, latter entires override
earlier entries.
When you have create you @file{.gitignore} you
are ready to stage it and make your first commit:
@example
git add .gitignore
git commit -n 'first commit'
@end example
@node Create an origin
@section 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 @file{.git} directory
and cannot be used as the working directory.
@example
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
@end example
It is standard to append @file{.git} to the
end of the repository name when it is bare.
To submit your changes to origin you can now
use the command @command{git push}. To fetch
updates others have made, use the command
@command{git pull}.
@node Gratis hosting
@section 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.
@table @asis
@item @bullet{} @url{https://savannah.nongnu.org/, Savannah}
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.
@item @bullet{} @url{https://gna.org, Gna!}
For Free Software projects only. Gna! runs on only
Free Software. Gna! runs on only
Free Software.
@item @bullet{} @url{https://bitbucket.org, BitBucket}
Gratis for 5 uses, with unlimied number of private
repositories for 5 collaborators.
@item @bullet{} @url{https://github.com/, GitHub}
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.
@item @bullet{} @url{https://www.assembla.com/catalog/51-free-private-git-repository-package?type=private&ad=git-wiki, Assembla}
Hosting limited to 2 GB with one free private
repository for three users.
@item @bullet{} @url{https://www.cloudforge.com/pricing, CloudForge}
Hosting limited to 2 GB.
@end table
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.
@node Introduction
@chapter Introduction
@menu
* What is Git?::
* It is distributed::
* Integrity::
@end menu
@node What is Git?
@section 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.
@node It is distributed
@section 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.
@node Integrity
@section 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.
@node Branching out
@chapter Branching out
@menu
* Workflow::
* Creating branches::
* Merging branches::
@end menu
@node Workflow
@section 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.
@node Creating branches
@section 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:
@example
git checkout -b BRANCH_NAME
@end example
After issuing this command you are located
in a new branch. The create it in the origin,
make a push:
@example
git push -u origin BRANCH_NAME
@end example
From this point on you can push without
parameters:
@example
git push
@end example
The @command{-u origin BRANCH_NAME} is just
to initially tell which remote repository
a pushes should go to.
To switch branch use the checkout command:
@example
git checkout BRANCH_NAME
@end example
@node Merging branches
@section Merging branches
The merge a branch into another, switch
to one of them and pull the other:
@example
git checkout MERGER
git pull . MERGEE
@end example
In the default mode, @command{git pull . MERGEE}
is a short and fore a fetch and merge:
@example
git fetch MERGEE &&
git merge MERGEE
@end example
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
@code{Hello world} and the mergee branch
as the line @code{hello world!}, the
file will contain:
@example
<<<<<<< HEAD
Hello world
=======
hello world!
>>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
@end example
Where
@code{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.
@node Collaborating
@chapter Collaborating
@menu
* Cloning a repository::
* Submitting patches::
@end menu
@node Cloning a repository
@section Cloning a repository
The first thing you need to do in order
to begin collaboration is the clone the
repository:
@example
git clone REPOSITORY -o upstream
@end example
By including @command{-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
@code{upstream/BRANCH} as the branch name.
@node Submitting patches
@section Submitting patches
The best way to create a patch is with Git's
@command{format-patch} command. Assuming
you began from @code{upstream/master}:
@example
git format-patch upstream/master
@end example
This command with create a patch whose name
will be printed by @command{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'@footnote{RFC is an abbreviation
for `Request for comments'} instead of `PATCH'.
To send the patch, use @command{git send-email}:
@example
git send-email --to=EMAIL_ADDRESS_TO_SEND_TO PATCH_FILE
@end example
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:
@example
--envelope-sender=SENDER_EMAIL_ADDRESS
@end example
You will also need the specify which SMTP
server to use, authorisation and configurations:
@example
--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
@end example
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.
@node GNU Free Documentation License
@appendix GNU Free Documentation License
@include fdl.texinfo
@bye
