My Git Workflow Git’s great! But it’s difficult to learn (it was for me, anyway) – especially the index, which unlike the power-user features, comes up in day-to-day operation. Here’s my path to enlightment, and how I ended up using the index in my particular workflow. There are other workflows, but this one is mine. What this isn’t: a Git tutorial. It doesn’t tell you how to set up git, or use it. My brief history with Git I started using Git about six months ago, in order to productively subcontract for a company that still uses Perforce. Each of these systems has flaws. Git’s problem is its complexity. Git without the index I got through my first four months of Git by pretending it was Subversion. $ cat ~/.gitconfig [alias] ci = commit -a co = checkout st = status -a $ git ci -m 'some changes' Adding Back the Index Git keeps copies of your source tree in the locations in this diagram. The data store that’s new, relative to every other DVCS that I know about, is the “index”. Well, probably.
The Differences Between Mercurial and Git April 6, 2008, 7:28 p.m. I realized recently that I've been using distributed revision control for several years now. It's always been an exciting landscape for me, although it's been a bit lonely. Neither darcs nor gnu arch were particularly fast systems, but they did a reasonably good job. I heard about git on the darcs list a while back, but didn't see what it provided that was so great. But I eventually did start looking at git, only because there were projects to which I contribute that also use git. Technical Differences The primary difference between distributed systems and centralized systems is in granularity. i.e. in a centralized system, there's no distinction between saving a change and making it available. History is a DAG In both git and mercurial, the history is just a directed acyclic graph, but mercurial attempts to provide a linear history and this has a negative effect in a few places. And I believe this is where mercurial has gone wrong. Mutability Tools
OGRE Git Tutorial Posted on 2008-07-13, last modified 2008-08-01. This is a recording of the Git tutorial given by Bart Trojanowski for the Ottawa Group of Ruby Enthusiasts. The talk was hosted by Jay Lawrence of Infonium. Special thanks to Richard Guy Briggs for help with this recording. UPDATE: Richard has posted photos of the talk I was working with some new equipment for this recording and I'm afraid that the audio suffers from some clipping. The videos are also available in Ogg Theora/Vorbis format for downloading (right-click, save as...): [Git the basics Part 1 - 76,473,624] [Git the basics Part 2 - 248,230,749] Tags: Video Git
GitTips - GitWiki See also: GitFaq (Frequently Asked Questions) page. GitWorkflows which attempts to describe actual, useful, real-world things that people do with git, step by step. ExampleScripts - You can do a lot by writing a simple script. Table of contents: How to fix the most recent commit Git allows you to easily fix up the most recent commit you've made on a branch with the --amend option: For example the following command will allow you to alter the commit message at the top of current head: $ git commit --amend while $ git commit -s --amend will let you alter the commit message and will also automatically add a sign-off message for you. How to change commits deeper in history Since history in Git is immutable, fixing anything but the most recent commit (commit which is not branch head) requires that the history is rewritten from the changed commit and forward. Or you can use rebase to do that. git filter-branch can also be useful. How to get only merges in gitk? With recent version of git you can use
Calendar about nothing Preface Git is a version control Swiss army knife. A reliable versatile multipurpose revision control tool whose extraordinary flexibility makes it tricky to learn, let alone master. As Arthur C. Clarke observed, any sufficiently advanced technology is indistinguishable from magic. This is a great way to approach Git: newbies can ignore its inner workings and view Git as a gizmo that can amaze friends and infuriate enemies with its wondrous abilities. Rather than go into details, we provide rough instructions for particular effects. I’m humbled that so many people have worked on translations of these pages. Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick, Andy Somerville, Ralf Recker, Øyvind A. François Marier maintains the Debian package originally created by Daniel Baumann. My gratitude goes to many others for your support and praise. or from one of the mirrors:
Git subtrees Building your own online transit planner with a bike and a GPS Fellow Navarra member William Lachance has been featured in an awesome article in The Coast about hbus.ca, his new online public transit planner for the city of Halifax. The catch? Now, in my experience, once you've made someone look stupid, as Will has unfortunately done with the transit people in Halifax, they'll get even more defensive. ...in Halifax, that is. iPhone app, anyone? April 2, 2009 19:33 I tried Joel's salary scale method, and the results were... ...mixed. ;) Joel Spolsky recently published an article about the public salary scale system at Fog Creek Software. At it happens, I've been following Joel since he first wrote about that system back in 2002 or so, and my software company at the time used a salary system modeled after his. The NITI Employee Level System Joel has plenty of rationale for his system. And you know what? That's true even if you don't have a public scale. But back to jealousy. It worked. Epilogue
Tv's cobweb: Howto host git on your Linux box Warning This solution is obsolete. Use gitosis instead! Gitosis is basically git-shell-enforce-directory's big brother, and an actual software project. Use it. Updated to drop --use-separate-remote from git clone, it's the default. Updated to add --read-only to git-shell-enforce-directory. I've run repeatedly into cases where I want to provide services to people without really trusting them. Instead of trying to run the version control system over HTTPS (like Subversion's mod_dav_svn that will only work with Apache, which I don't run), I want to run things through SSH. Now, I said I don't want to create a unix user account for every developer using the version control system. For Subversion, I submitted an enhancement to add --tunnel-user, to make sure the commit gets identified as the right user, and then used command="..." with the with arguments, like this (all on one line): With git, the author of the changeset is recorded way before the SSH connection is opened. And you're done!
Git Submodules: Adding, Using, Removing, and Updating I’ve spent a little more than a month working with Git now. I can honestly say that while there are many things that I like about Git, there are just as many things that I personally find to be a pain in the butt. Submodules specifically have managed to be a thorn in my side on many occasions. While the concept of submodules is simple, figuring out how to actually work with them can be a chore. What are Submodules? The concept of submodules is brilliant. My profession is working with WordPress themes. Each theme that we produce is kept in its own Git repository. For example, we have a theme called FlexxBold. As I mentioned before, not everything in Git is easy to work with. Adding Submodules to a Git Repository Fortunately, adding a submodule to a git repository is actually quite simple. There are three main parts to this command: git submodule add – This simply tells Git that we are adding a submodule. Let’s check to see how the repository is doing. Using Submodules Removing Submodules
Software Branching and Parallel Universes Source control is the very bedrock of software development. Without some sort of version control system in place, you can't reasonably call yourself a software engineer. If you're using a source control system of any kind, you're versioning files almost by definition. The concept of versioning is deeply embedded in every source control system. You can't avoid it. But there's another concept, equally fundamental to source control, which is much less frequently used in practice. Suppose it's your job to maintain a handbook for a particular division of your company. If you don't ever use the branching feature of your source control system, are you really taking full advantage of your source control system? I find that almost every client I visit is barely using branching at all. Parallel universes offer infinite possibility. The DC comic book series Crisis on Infinite Earths is a cautionary tale of the problems you can encounter if you start spinning off too many parallel universes.
Compiling Git on Snow Leopard Monday, 31 August 2009 • Permalink These are instructions for compiling and installing Git, a free, fast, and efficient distributed version control system, on Mac OS X 10.6 (Snow Leopard). The benefits of manually building Git yourself in /usr/local are detailed here and here. Prerequisites Before following these instructions, you will need: Mac OS X 10.6 Snow Leopard The latest Xcode Tools (from the Snow Leopard DVD or downloaded from Apple — the 10.5 version won’t work) Confidence running UNIX commands using the Terminal If you want to learn more about UNIX and the command line, check out my PeepCode screencast on this topic. Step 1: Set the PATH Launch Terminal.app from the /Applications/Utilities folder. We need to set your shell’s PATH variable first. If you’re using TextMate like you should be and have installed the UNIX mate command, then you can create and start editing the file like this: mate ~/.profile To the end of this file, add the following line (or verify that it’s already there):
Subversion to Git I never liked CVS—the limitations and design flaws become obvious almost as soon as you start using it—but after years of use it was a familiar model that worked well enough in practice. Then came Subversion. It worked like CVS but fixed the glaring problems, providing atomic commits, the ability to move files and folders, checksumming, revision numbers that represent whole trees, and easier tagging and branching (albeit by shoe-horning them into the tree). Switching was an easy decision. Then I heard about Git when I happened to watch a video of its creator, Linus Torvalds. What I found is that Torvalds’s bragging is justified. Beyond just the distributed model, Git’s implementation is beautiful. Git’s implementation is compact. The user interface is currently a bit rougher than Subversion’s, but it’s not too bad, and some things are actually nicer. In order to migrate from Subversion I needed to install LWP: sudo perl -MCPAN -e shell install Bundle::LWP