ollowing on from last weeks post about Simple Two Factor SSH Authentication this post shows you how to use the same SSH trick to create a multi-user private git server. I believe the principles here can also be applied to mercurial or subversion.

I was recently working on a client project that we converted to git, we hired an agency to work on the front-end for the project and they had four users that needed access. I didn't really want to create them individual accounts on the server so I started thinking how I could securely manage multiple-user access to a git repository running under a single git user without giving them shell access.

After a bit of research I identified two possible candidates gitosis and gitolite but they seemed overkill for what I was trying to achieve.

It was about one year ago that we switched to Git. Previously, we used Subversion, through the Mac app Versions, which (rightly) holds an Apple Design Award.

This post is based on a talk I gave at the 18th Cocoaheads Meetup Vienna (CHW018) on Feb 17th, 2011. It is an annotated tour of my Git config, Git related scripts and commands, and various other tips and tricks I picked up over the years. You can find most of these things in my dotfiles repo, as well with a lot of other stuff, like parts of my Zsh config. Patches welcome.

If you have started to feel comfortable using git and have begun to acknowledge its power, but you feel like you're missing out on some of the importance of the advanced features, this post is for you. Before I jump into the use cases and commands, I'd like to explain a little motivation.

As you should know if you've read enough about git, one of the many interesting things about the design is that a commit in git is just a snapshot of the current repository. Yes, the entire repository! Of course, due to algorithmic awesome-tude, this is compressed against time, so it's not horribly inefficient to do. 

If you want to read more about the internals (which I highly reccommend), check out Git from the Bottom Up. 

I think that fact of git's design is interesting in and of itself, but most especially because it reveals intent. Git's awesome flexibility and power are useful because they allow you to manipulate your changes into logical steps that you can present to your team. It's no surprise that this is one of git's strengths, considering it was developed to do version control on the Linux kernel. Without a system that allows such manipulation, Linus would be impossibly swamped with work trying to extract meaning from hundreds of commits coming from all across the world. While most of us are lucky enough to not have such a large team, the same practices that make their development efficient can be applied to yours. 

Git is a wonderful version control system, but it does have a bit of a learning curve. The learning curve is made worse because git is so much more powerful than Subversion (for example). When you first try to learn git, it's confusing to sift through all of the powerful features people excitedly write about, just so you can find out how to do the simplest SVN use case. Annoying.

I want to write a post on those advanced features, but when I reflected back on my learning process, I realized that it wouldn't be fair to make the situation worse. With that in mind, here's my simplified guide to git- nothing but the absolute basics. It's not even git 101, it's git 001. If you don't need git 001, skip to git 102. There is no git 101- that's covered all too well online.

[Assumption: you have git set up for development on your team's repository. If you don't, there are a million tutorials online, but I'd honestly recommend just asking someone to do it for you. If my motivation lasts beyond Git 102, I'll add another post about setting up]

This is a light version of http://notifixio.us, powered by Superfeedr and Google AppEngine — Read more
http://notifixlite.appspot.com/

Git Immersion is a guided tour that walks through the fundamentals of Git, inspired by the premise that to know a thing is to do it.

I’ve been using git for about 18 months now and thought I knew it pretty well. Then we had Scott Chacon from GitHub over to do some training at LVS, a supplier/developer of betting/gaming software (where I’m currently contracting) and I learnt a ton in the first day.

As someone who’s always felt fairly comfortable in Git, I thought sharing some of the nuggets I learnt with the community might help someone to find an answer without needing to do lots of research.

Gerrit is a web based code review system, facilitating online code reviews for projects using the Git version control system.

Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer.

Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer. This functionality enables a more centralized usage of Git.

Git is a free distributed revision control, or software source code management project with an emphasis on being fast. Git was initially designed and developed by Linus Torvalds for Linux kernel development. Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.

GIT Distributed Version Control