Git Setup Best practices

Question

I was tasked with setting up Git for my office. We have several sites. I just set up a network drive for us to push our changes to. My question is: Where do I init the Git repos

Answer 1

The structure of repos is not a matter if sites (whatever you want to tell with that) but a matter of projects.

As a rule of thumb:

• use ONE (bare, blessed) repo for each independent project
• if common modules are shared, realize with submodules

Within each repo, structure the work with branches, and do not confuse branches with means of organizing different software stacks: branches are used to organize the work in one repo (i.e. different development strings of ONE software). One branching model (that seems to be quite popular here at SO) is this one:

Confused? Curious? Read the explanation...

Answer 2

You probably want to have a centralized server which you push changes to and clone from. This server may have one repository or many. I recommend reading http://sethrobertson.github.com/GitBestPractices/ which has several sections of direct interest. Specifically picking a local workflow, a distributed workflow, and how to divide your work up into repositories.

Answer 3

I would recommend gitolite if you host the repo internally. You add a central repo by simply changing the confusion file.

Unless you are doing cross-platform development, set auto crlf to false.

Manage your branches this way:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Answer 4

It's a matter of preference if you'd rather have all code bases in one git repo, or each in their own. That said, my preference would be one git repo per code base/site. That way you can work on a single site without having to check out the others, and you won't have to worry about changes to the other sites getting in the way of any commits you might push to any given site.

Answer 5

Basic Setup

I would suggest you create a directory devoted to git on a server.

I used the directory name /git on a server run by my company for work related things, and for personal use I also created a directory called /git on a private web server.

Inside your /git directory you can then create bare repositories for your projects

ssh git@myserver
cd /git
mkdir Project7sName.git
cd Project7sName.git
git init --bare
echo "Take over the world project" > description

Add a viewer

Then you can install something like GitList on the server to allow software changes to be nicely view-able, e.g. deletions in red and insertions in green.

Distributed Version Control?

Git is a distributed version control system. So you might want to do this at several sites. The advantages are then that if at any time you lose your connection to other sites, you can continue to work uninterrupted. Also, if you have hard drive failures or any sort of similar problems, you have multiple copies of the data.

You can nominate a site as being the main site if you like that people should always push to, or your working practices could be that people push to all your server sites.

Make use of commands like

git remote add siteA ssh://git@siteA/git/repositoryX.git

so you can then do things like

git push siteA master
git push siteB master

I have a backup script which runs daily, pulling from github, from our own gitserver, a NAS drive, a USB drive, and pushing to each of them too.

Doing that, there are two methods of ensuring there are multiple copies of a software change.

1. By the user (pushing to multiple sites) and
2. By administration (copying changes between sites).

Start by setting up Git on a server and adding something like GitList to view changes nicely.

Once you properly understand the steps involved, you can repeat them at another site if you like, as and when you choose.

Import old projects?

As system administrator, you may want to import old projects into Git.

You can do this by committing an empty repository.

git touch .gitignore
git add .gitignore
git commit -m Empty

And then repeatedly unzipping your archived versions of a project into a project directory (emptied apart from the git files) and committing the archived state.

rm *
unzip ...
git add *
git commit -m "Archived state 2013 week 18"
git tag ArchivedState2013week18

If you commit the archived states in chronological order then your viewing software (GitList or whatever) is then likely to start showing you the software changes for historical fixes, albeit mixed together at times and incomplete at others.

Also, you will be able to use git blame to have an idea when some lines of code were introduced.