all repos — h3rald @ 06775a396e6380dacf6d2eab2a563621d7df218e

The sources of https://h3rald.com

content/articles/git-for-the-locals.textile

 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
----- 
permalink: git-for-the-locals
title: Git for the Locals
tags: 
- programming
type: article
filter_pre: textile
-----
_"This is a *local* shop for *local* people, we want no trouble here!"_

— Edward, "The League of Gentlemen":http://en.wikipedia.org/wiki/League_of_gentlemen

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(TM) without spending some time looking into it. And especially nowadays, finding the time to look into something new can be a real challange.

I deliberately didn't look into Git properly since it went "mainstream" (maybe I shouldn't use this word), but when "this tutorial":http://www.spheredev.org/wiki/Git_for_the_lazy came out I couldn't resist. Sure, I knew Git was an amazingly fast distributed version control system, that "GitHub":http://github.com/ offered free accounts, that all the cool guys were slowly starting to use it in place of Subversion, etc. etc.

What I didn't realize though, that the most obvious advantage of this DVCS was the fact that it was *distributed*, i.e., it _didn't need_ a centralized server. 

Let me repeat this: *Git _doesn't need_ a centralized server.*

Really.h3. ...But it's not user-friendly! 

If you're a Windows user and you used Subversion before, chances are that you got accustomed to "TortoiseSVN":http://tortoisesvn.tigris.org/, too. TortoiseSVN is — in a way — a nice graphical fron-end to SVN which provides seamless Windows Explorer integration. 
Git doesn't have anything like that yet. There's something in the works, sure, but nothing really comparable to TortoiseSVN. Therefore, you are _kindly suggested_ to get on and use the command line for all your git stuff.

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 DOS prompt is no way near to bash & Co.

For the -lazy gits- Windows users, "MSysGit":http://code.google.com/p/msysgit/ is the answer to all your problems. _Officially_ 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.

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.
In a few click, you'll be able to use Git (and Bash!) right away: no tricks, no hassle, no kidding.

And stop moaning about the command line not being user friendly. You want a new repository _anywhere_? Just type in the following:

<typo:code>
git init
git add .
git commit
</typo:code>

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 SVN, for sure.

h3. Are you local?

"Being local" 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% _local_ repository.

The three Git commands I mentioned earlier can be used to create a repository _there_, exactly where you are: not on a server far, far away.
Let's see what this means:

# You don't need an Internet connection anymore to use a VCS
# You don't get a .svn folder in _every_ damn directory of your project, with a load of crappy files in it.
# You get only a .git folder _at top level_, 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
# You can physically copy your repository anywhere and still use it
# You don't need to signup to GitHub for an account, if you only want your own VCS

OK, this is an extreme scenario, but sometimes you may want your _own_ 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.
With Git, you can get all the advantages of a VCS (and an _incredibly fast_ VCS) without having to setup any server infrastructure: just install Git on your machine, and you're done. No server processes, no hassle.


h3. Don't connect, synchronize

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 VCS, event.

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 SSH at work, so I wouldn't be able to push my commits back to a central repository online like GitHub.

So here's what I did:

# I setup a local repository for my project on a local folder at work.
# I started working on my project, did a few commits.
# After performing the last commit for the day (you are encouraged to commit often by Git, really), I synchronized that folder with my USB key, via SyncToy.
# Back at home, I used SyncToy again to synchronize my files (including the repository) between the USB key and my home computer.
# Performing a @git status@ 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.
# All I did was a @git reset --hard@ to get _exactly_ the same files I committed at work, with absolutely no information loss.

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.

h3. Conclusion

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 _anyone_, as a fast, simple and very effective private _local_ repository. In case you need one, that is (if you are really _local_).