\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:: * 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 some a few hours before it is accepted. Savannah runs on only free software. @item @bullet{} @url{https://gna.org, Gna!} For Free Software projects only. @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:: @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 GNU Free Documentation License @appendix GNU Free Documentation License @include fdl.texinfo @bye