DIY Debian Wheezy Local Git Server With Git Lite Workflow

[40hz]

Recently posted on the HowtoForge website - a step-by-step how-to to take you through the setup of your very own Debian-based small team GIT VCS server. Thought it might be of interest to some of the coding types here.

Link to full article here.

Debian Wheezy Local Git Server With Git Lite Workflow

Introduction

This howto describes a shared local git [1] server setup for a small team. This is a repository layout that is familiar to anyone used to working with a traditional version control system.

One of the tutorial objectives is to show detailed steps to prepare the server (here called the depot because of its authoritative role) and publish the code on a public service like Github, Gitorius [2,3] et. al.

A second objective is to introduce the Git Lite Workflow in team development. This serves as an introduction to gits powerful branch and merge features. Your personal favorite workflow may be different compared to this model. For a feature rich workflow albeit more complex, see nvie [4].

[kyrathaba]

Thanks, 40.

I stowed the full article via Readability's "Read Later" bookmarklet. Recently downloaded and installed VS 2012 Express, which comes with its own Team Foundation Server (surprisingly), even though it limits you to five on a team.

I'll have to compare that to the small-team GIT VCS.

[f0dder]

VS 2012 has Git support now, btw, official from MS - it works with normal repositories as well as the new TFS Git support.

Unless I'm missing something, the support is extremely basic, though.

[kyrathaba]

^ Yeah, fodder, I think you're right about the support in VS for Git being bare-bones basic.

I liked the following from the HgInit site:

In Mercurial, you think about changesets. A changeset is a concise list of the changes between one revision and the next revision.

Six of one, half dozen of the other: what’s the difference?

Here’s the difference. Imagine that you and I are working on some code, and we branch that code, and we each go off into our separate workspaces and make lots and lots of changes to that code separately, so they have diverged quite a bit.

When we have to merge, Subversion tries to look at both revisions—my modified code, and your modified code—and it tries to guess how to smash them together in one big unholy mess. It usually fails, producing pages and pages of “merge conflicts” that aren’t really conflicts, simply places where Subversion failed to figure out what we did.

By contrast, while we were working separately in Mercurial, Mercurial was busy keeping a series of changesets. And so, when we want to merge our code together, Mercurial actually has a whole lot more information: it knows what each of us changed and can reapply those changes, rather than just looking at the final product and trying to guess how to put it together.