<spanclass="tomenu"><ahref="#navigation">↓ Menu ↓</a></span>
<spanclass="flush"></span>
</div>
</div>
<divid="titre">
<h1>Git for n00b</h1>
<h2>introduction</h2>
</div>
<divclass="flush"></div>
<divid="afterheader"class="article">
<divclass="corps">
<divclass="intro">
<p>A detailed tutorial of <ahref="http://git-scm.org">Git</a> for people knowing very few about versions systems. You’ll understand utility of such program and how we use modern version control system. I try to stay as pragmatic as possible.</p>
</div>
<hr/>
<h1id="begin-with-conclusion">Begin with conclusion</h1>
<p>Here is the list of sufficient and necessary command to use <ahref="http://git-scm.org"title="Git">Git</a>. There is very few. It is normal not to understand immediately but it is to gives you an idea. Even if this article is long, 95% of <ahref="http://git-scm.org"title="Git">Git</a> usage is in these 7 commands:</p>
<divclass="sourceCode"id="cb2"><preclass="sourceCode zsh"><codeclass="sourceCode zsh"><aclass="sourceLine"id="cb2-1"title="1"><spanclass="co"># get modifications from other</span></a>
<p>This article is written for people knowing very few about versionning systems. It is also written for those who had didn’t followed progress since CVS or subversion (SVN). This is why, in a first time I’ll explain quickly which are the goal of such systems. Secondly, I’ll explain how to install and configure <ahref="http://git-scm.org"title="Git">Git</a>. Then, I give the command for each feature a <abbrtitle="Decentralized Concurent Versions System">DCVS</abbr> must have.</p>
<h1id="gitgit-for-what"><ahref="http://git-scm.org"title="Git">Git</a> for what?</h1>
<divclass="intro">
<p>If you just want to use <ahref="http://git-scm.org"title="Git">Git</a><strong>immediately</strong>, just read dark part. You read this part later to understand correctly foundations of version systems and not doing strange things.</p>
</div>
<p><ahref="http://git-scm.org"title="Git">Git</a> is a <abbrtitle="Decentralized Concurent Versions System">DCVS</abbr>, which means a Decentralized Concurrent Versions System. Let’s analyze each part of this long term:</p>
<h3id="versions-system">Versions System</h3>
<p>Firstly, versions system manage files. When somebody work with files without a versions system, the following happens frequently:</p>
<p>When you modify a somehow critical file you don’t want to loose. You copy naturally this file with another name. For example:</p>
<p>In consequence of what, the new file, play the role of <em>backup</em>. If you break everything, you can always return in the last state by overwriting your modifications. Of course, this method is not very professional and is a bit limited. If you make many modifications, you’ll end with many files with strange names like:</p>
<p>If you want to make it works correctly, you’ll have to use naming convention. Files take many place even if you modify most of time only some lines.</p>
<p><em>Fortunately, versions system are here to help.</em></p>
<p>You only have to signal you want a new version of a file and the versions system will do the job for you. It will record the backup where it could be easily recovered. Generally, systems version do it better than you, making the backup only of the modified lines and not the total file.</p>
<p>Once upon a time versions were managed for each file separately. I think about CVS. Then it naturally appears projects are a coherent set of files. Recover each file separately was a tedious work. This is why versions number passed from files to the entire project.</p>
<p>It is therefore possible to say, “I want to get back three days earlier”.</p>
<divclass="black">
<p><em>What gives versions system?</em> (I didn’t mention everything at all)</p>
<ul>
<li>automatic backups: <em>back in time</em>,</li>
<li>gives the ability to see differences between each version,</li>
<li>put a <em>tag</em> on some version to be able to refer to them easily,</li>
<li>gives the ability to see an historic of all modifications. Generally the user must add a comment for each new version.</li>
</ul>
</div>
<h3id="concurrent">concurrent:</h3>
<p>Version Systems are already useful to manage its own projects. They help to organize and resolve partially backup problems. I say partially because you have to backup your repository on a decent file system. But versions system are really interesting is on projects done by many people.</p>
<p>Let’s begin by an example, a two person project ; Alex and Beatrice. On a file containing a <em>Lovecraft</em>’s gods list:</p>
<p>Alex modification is <em>lost</em>. One more time, versions system are here to help.</p>
<p>A version system would had <em>merge</em> the two files at the time Beatrice send the file on the server. And like by magic, on the server the file would be:</p>
<p>In real life, at the moment Beatrice want to send her modifications, the versions system alert her a modification had occurred on the server. Then she uses a command which pull the modification from the server to her local computer. And this command update her file. After that, Beatrice send again the new file on the server.</p>
<divclass="black">
<p><strong>In what Concurrent Versions System help?</strong></p>
<ul>
<li>get without any problem others modifications,</li>
<li>send without any problem its own modifications to others,</li>
<li>manage conflicts. I didn’t speak about it, but sometimes a conflict can occur (when two different people modify the same line on a file for example). SVC help to resolve such problem. More on that later,</li>
<li>help to know who done what and when.</li>
</ul>
</div>
<h3id="decentralized">decentralized</h3>
<p>This word became popular only recently about CVS. And it mainly means two things:</p>
<p>First, until really recently (SVN), you’ll have to be connected to the distant server to get informations about a project. Like get the history. New decentralized systems work with a local <em>REPOSITORY</em> (directory containing backups and many informations linked to the versions system functionalities). Hence, one can view the history of a project without the need of being connected.</p>
<p>All instances of a project can live <em>independently</em>.</p>
<p>To be more precise, DCVS are base on the <em>branch</em> notion.</p>
<p>Practically, it has great importance. It means, everybody work separately, and the system help to glue all their work.</p>
<p>It is even more than just that. It help to code independently each feature and bug fixes. Under other system it was far more difficult.</p>
<p>Typical example:</p>
<blockquote>
<p>I develop my project. I’m ameliorating something. An urgent bug is reported.</p>
<p>With a DCVS I can easily, get back to the version with the bug. Fix it. Send the fix. Get back to my feature work. And even, use the fix for the new version with my new feature.</p>
<p>In a not decentralized version system, doing such a thing is possible but not natural. Decentralization means it become natural to use a branch for each separable work.</p>
</blockquote>
<divclass="black">
<p><strong>Advantages given by DCVS:</strong></p>
<ul>
<li>Ability to work offline,</li>
<li>Ability to create many <em>atomic</em> patches,</li>
<li>Help the maintenance of many different versions of the same application.</li>
</ul>
</div>
<h2id="to-resume">To resume</h2>
<p>Let’s resume what we can easily do with DCVS:</p>
<p><strong>Versions Systems</strong></p>
<ul>
<li>back in time,</li>
<li>list differences between versions,</li>
<li>name some versions to refer to them easily</li>
<li>show history of modifications</li>
</ul>
<p><strong>Concurrent</strong></p>
<ul>
<li>get others modifications,</li>
<li>send its modifications to others,</li>
<li>know who done what and when,</li>
<li>conflicts management.</li>
</ul>
<p><strong>Decentralized</strong></p>
<ul>
<li>Easily manipulate branches</li>
</ul>
<p>Now let’s see how to obtain all these things easily with <ahref="http://git-scm.org"title="Git">Git</a>.</p>
<p>Save the following file as your <code>~/.gitconfig</code>.</p>
<pre><code>[color]
branch = auto
diff = auto
status = auto
[alias]
st = status
co = checkout
br = branch
lg = log --pretty=oneline --graph
logfull = log --pretty=fuller --graph --stat -p
unstage = reset HEAD
# there should be an article on what this command do
uncommit = !zsh -c '"if (($0)); then nb=$(( $0 - 1 )); else nb=0; fi; i=0; while ((i<=nb)); do git revert -n --no-edit HEAD~$i; ((i++)); done; git commit -m \"revert to $0 version(s) back\""'
undomerge = reset --hard ORIG_HEAD
conflict = !gitk --left-right HEAD...MERGE_HEAD
# under Mac OS X, you should use gitx instead
# conflict = !gitx --left-right HEAD...MERGE_HEAD
[branch]
autosetupmerge = true</code></pre>
<p>You can achieve the same result using for each entry the command: <code>git config --global</code>. Next, configure your name and your email. For example, if your name is John Doe and your email is <code>john.doe@email.com</code>. Launch the following commands:</p>
<divclass="sourceCode"id="cb9"><preclass="sourceCode zsh"><codeclass="sourceCode zsh"><aclass="sourceLine"id="cb9-1"title="1">$ git config --global user.name John Doe</a>
<p>Here it is. Base configuration is over. The file containing alias will help to type shorter commands.</p>
<h2id="get-a-project">Get a project</h2>
<p>If a project is already versionned with <ahref="http://git-scm.org"title="Git">Git</a> you should have an <code>URL</code> of the sources. Then use the following command:</p>
<p>If there is no git server but you’ve got an <code>ssh</code> access. Just replace the <code>git://host</code> by <code>ssh://user@host</code>. In order not to type your password each time, use:</p>
<p>Reply to question and <strong>do not enter</strong> a password. Then copy your keys to the distant server. This is not the safest way to do this. The safest being, using <code>ssh-agent</code>.</p>
<p>The easiest way if you have <code>ssh-copy-id</code>:</p>
<p>Let do a small remark. If you don’t want to <em>version</em> every file. Typically intermediate compilation file, swap files… Then you need to exclude them. Just before launching the <code>git add .</code> command. You need to create a <code>.gitignore</code> file in the root directory of your project. This file will contain all exclude <em>pattern</em>. For example:</p>
<p>Now, if you want to create a repository on a distant server, it <em>must</em> not be in <code>bare</code> mode. The repository will contain only versionning informations, but not the files of the project. To achieve that:</p>
<h2id="abstract-of-the-second-step">Abstract of the second step</h2>
<p>You now have a local directory on your computer. It is versionned and you can say it is, because there is a <code>.git</code> directory at the root (and the root only) of your project. This directory contain all necessary informations for <ahref="http://git-scm.org"title="Git">Git</a> to version your project.</p>
<p>Now you only need to know how to use it.</p>
<h1id="here-we-go">Here we go!</h1>
<p>Here is one from many way to use <ahref="http://git-scm.org"title="Git">Git</a>. This method is sufficient to work on a project. Not there is many other <em>workflows</em>.</p>
<h2id="basic-usage">Basic usage</h2>
<p>Work with <ahref="http://git-scm.org"title="Git">Git</a> immediately:</p>
<ul>
<li>Get modification done by others <code>git pull</code>,</li>
<li>See details of these modifications <code>git log</code>,</li>
<li>Many times:
<ul>
<li><em>Make an atomic modification</em></li>
<li>Verify details of this modification: <code>git status</code> and <code>git diff</code>,</li>
<li>Add some file to be versionned if necessary:<br/><code>git add [file]</code>,</li>
<li>Save you modifications <br/><code>git commit -a -m "message"</code>,</li>
<li>Send your modifications to others: <code>git push</code> (redo a <code>git pull</code> if push return an error).</li>
</ul></li>
</ul>
<p>With these few commands you can use <ahref="http://git-scm.org"title="Git">Git</a>. Even if it is sufficient, you need to know one more thing before really begin ; How to manage <em>conflicts</em>.</p>
<p>Conflicts can arise when you change the same line of code on the same file from another branch you’re merging. It can seems a bit intimidating, but with <ahref="http://git-scm.org"title="Git">Git</a> this kind of thing is really simple to handle.</p>
<aclass="sourceLine"id="cb19-9"title="9">Automatic merge failed; fix conflicts and <spanclass="kw">then</span> commit the result.</a></code></pre></div>
Zoot <spanclass="Constant"><strong>the not so pure</strong></span>
</pre>
</div>
<p>and to commit</p>
<div>
<divclass="sourceCode"id="cb20"><preclass="sourceCode zsh"><codeclass="sourceCode zsh"><aclass="sourceLine"id="cb20-1"title="1">git commit -a -m <spanclass="st">"conflict resolved"</span></a></code></pre></div>
</div>
<p>Now you’re ready to use <ahref="http://git-scm.org"title="Git">Git</a>. <ahref="http://git-scm.org"title="Git">Git</a> provide many other functionnalities. Now we’ll see some <ahref="http://git-scm.org"title="Git">Git</a> usages older CVS couldn’t handle.</p>
<h1id="why-git-is-cool">Why Git is cool?</h1>
<p>Because with <ahref="http://git-scm.org"title="Git">Git</a> you can work on many part of some project totally independently. This is the true efficiency of decentralisation.</p>
<p>Each branch use the same directory. Then you can easily change your branch. You can also change branch when some files are modified. You can then dispatch your work on many different branches and merge them on one master branch at will.</p>
<p>Using the <code>git rebase</code> you can decide which modifications should be forget or merged into only one modification.</p>
<p>What does it mean for real usage? You can focus on coding. For example, you can code, a fix for bug b01 and for bug b02 and code a feature f03. Once finished you can create a branch by bug and by feature. And finally you can merge these modifications on a main branch.</p>
<p>All was done to code and decide how to organize your versions after. In other VCS it is not as natural as in <ahref="http://git-scm.org"title="Git">Git</a>.</p>
<p>With <ahref="http://git-scm.org"title="Git">Git</a> you can depend of many different sources. Then, there is not necessarily a ‘master’ repository where everybody puts its modifications.</p>
<p>What changes the most with <ahref="http://git-scm.org"title="Git">Git</a> when you come from SVN, it’s the idea of a centralized project on one server. With <ahref="http://git-scm.org"title="Git">Git</a> many people could work on the same project but not necessarily on the same <em>repository</em> as main reference. One can easily fix a bug and send a patch to many different versions of a project.</p>
<h1id="command-list">Command List</h1>
<h2id="command-for-each-functionality">Command for each functionality</h2>
<p>In the first part, we saw the list of resolved problem by <ahref="http://git-scm.org"title="Git">Git</a>. To resume <ahref="http://git-scm.org"title="Git">Git</a> should do:</p>
<ul>
<li>get others modifications,</li>
<li>send modifications to others,</li>
<li>get back in time,</li>
<li>list differences between each version,</li>
<li>name some versions in order to refer easily to them,</li>
