all repos — h3rald @ 6b243ded05a7593922d198634c681075de1c12e2

The sources of https://h3rald.com

contents/articles/git-for-the-locals.html

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
-----
title: "Git for the Locals"
content-type: article
timestamp: 1216095480
tags: "programming"
-----
<p><em>&#8220;This is a <strong>local</strong> shop for <strong>local</strong> people, we want no trouble
		here!&#8221;</em></p>
<p>&mdash; Edward, <a href="http://en.wikipedia.org/wiki/League_of_gentlemen">The League of Gentlemen</a></p>
<p>I'm normally quite cautious when it comes to IT novelties like new frameworks, new methodologies and similar,
	especially when it feels like they're over-hyped. Especially nowadays, it is sometimes very hard to tell whether
	something new is over-hyped or really a Good Thing&#8482; without spending some time looking into it. And especially
	nowadays, finding the time to look into something new can be a real challange.</p>
<p>I deliberately didn't look into Git properly since it went &#8220;mainstream&#8221; (maybe I shouldn't use this
	word), but when <a href="http://www.spheredev.org/wiki/Git_for_the_lazy">this tutorial</a> came out I couldn't
	resist. Sure, I knew Git was an amazingly fast distributed version control system, that <a
		href="http://github.com/">GitHub</a> offered free accounts, that all the cool guys were slowly starting to use
	it in place of Subversion, etc. etc.</p>
<p>What I didn't realize though, that the most obvious advantage of this <span class="caps">DVCS</span> was the fact
	that it was <strong>distributed</strong>, i.e., it <em>didn't need</em> a centralized server.</p>
<p>Let me repeat this: <strong>Git <em>doesn't need</em> a centralized server.</strong></p>
<p>Really.h3. &#8230;But it's not user-friendly!</p>
<p>If you're a Windows user and you used Subversion before, chances are that you got accustomed to <a
		href="http://tortoisesvn.tigris.org/">TortoiseSVN</a>, too. TortoiseSVN is &mdash; in a way &mdash; a nice
	graphical fron-end to <span class="caps">SVN</span> which provides seamless Windows Explorer integration. <br />
	Git doesn't have anything like that yet. There's something in the works, sure, but nothing really comparable to
	TortoiseSVN. Therefore, you are <em>kindly suggested</em> to get on and use the command line for all your git stuff.
</p>
<p>Oh well, I personally love using command line interfaces for certain tasks, event if I spend more time on Windows
	than on any other OS and well, the <span class="caps">DOS</span> prompt is no way near to bash &amp; Co.</p>
<p>For the <del>lazy gits</del> Windows users, <a href="http://code.google.com/p/msysgit/">MSysGit</a> is the answer to
	all your problems. <em>Officially</em> you have to install Cygwin and all its crap to be able to use Git on Windows.
	Not that Cygwin is bad, but I personally don't like the extra layer it creates between you and an OS symulation
	which is not really what's on your machine.It would be great if you could get all the Bash goodies natively, without
	the hassle.</p>
<p>that's basically what you get for free when you install MSysGit: the best (to date) version of Bash you could
	possibly dream of for Windows, along with a few handy Gnu tools and of course all git commands.<br />
	In a few click, you'll be able to use Git (and Bash!) right away: no tricks, no hassle, no kidding.</p>
<p>And stop moaning about the command line not being user friendly. You want a new repository <em>anywhere</em>? Just
	type in the following:</p>
<div class='text'>
	<pre><code>git init
git add .
git commit</code></pre>
</div>
<p>This will create your new repository in the current directory, add all your files and filders recursively, and
	perform the initial commit. What's so hard in this? Nothing. And it's faster than <span class="caps">SVN</span>, for
	sure.</p>
<h3>Are you local?</h3>
<p>&#8220;Being local&#8221; has its own advantages: you know where you stand, you know what to expect, you don't depend
	on other people. What I didn't fully realize about Git is that it can be a 100% <em>local</em> repository.</p>
<p>The three Git commands I mentioned earlier can be used to create a repository <em>there</em>, exactly where you are:
	not on a server far, far away.<br />
	Let's see what this means:</p>
<ol>
	<li>You don't need an Internet connection anymore to use a <span class="caps">VCS</span></li>
	<li>You don't get a .svn folder in <em>every</em> damn directory of your project, with a load of crappy files in it.
	</li>
	<li>You get only a .git folder <em>at top level</em>, and that's where your repository actually is. Granted, there
		are going to be quite a few files in there, but they're not going to be scattered all over the place</li>
	<li>You can physically copy your repository anywhere and still use it</li>
	<li>You don't need to signup to GitHub for an account, if you only want your own <span class="caps">VCS</span></li>
</ol>
<p>OK, this is an extreme scenario, but sometimes you may want your <em>own</em> local repository for your stuff. You
	may want a place to version your documents, or a place to version your own little pet programming project nobody
	knows about.<br />
	With Git, you can get all the advantages of a <span class="caps">VCS</span> (and an <em>incredibly fast</em> <span
		class="caps">VCS</span>) without having to setup any server infrastructure: just install Git on your machine,
	and you're done. No server processes, no hassle.</p>
<h3>Don't connect, synchronize</h3>
<p>All the information your repository needs is stored in that little .git folder, nowhere else. You can copy your files
	and that folder, and you'll still get your repository back wherever you are. Maybe you can zip it before copying it,
	and then unzip it where you need a <span class="caps">VCS</span>, event.</p>
<p>I tried using some synchronization utilities like SyncToy or RoboCopy on Windows to keep my files synchronized on
	multiple computers: it all started off from the fact that I can't use <span class="caps">SSH</span> at work, so I
	wouldn't be able to push my commits back to a central repository online like GitHub.</p>
<p>So here's what I did:</p>
<ol>
	<li>I setup a local repository for my project on a local folder at work.</li>
	<li>I started working on my project, did a few commits.</li>
	<li>After performing the last commit for the day (you are encouraged to commit often by Git, really), I synchronized
		that folder with my <span class="caps">USB</span> key, via SyncToy.</li>
	<li>Back at home, I used SyncToy again to synchronize my files (including the repository) between the <span
			class="caps">USB</span> key and my home computer.</li>
	<li>Performing a <code>git status</code> showed that some files have been modified (all of them, actually): that's
		because Git detected that they weren't the same files which were committed, presumably because of different
		timestamps etc.</li>
	<li>All I did was a <code>git reset --hard</code> to get <em>exactly</em> the same files I committed at work, with
		absolutely no information loss.</li>
</ol>
<p>Isn't it a bad thing to move your git folder back and forth and let another program to synchronize files within it?
	Maybe, but it seems to work so far. A safer option, in this case, may be zipping the folder before synchronizing it,
	just to be sure.</p>
<h3>Conclusion</h3>
<p>Git can do much more than this. Git offers some really interesting branching features, for example, which I didn't
	mention in this article, of course, like several dozens of other commands. What I tried to point out was that Git
	can be used by <em>anyone</em>, as a fast, simple and very effective private <em>local</em> repository. In case you
	need one, that is (if you are really <em>local</em>).</p>