GIT SHOULDN'T BE SO HARD TO LEARN.

When you're just getting started, something as straightforward as a merge can be terrifying. It can take a long time to really become comfortable using some of Git's more advanced features. (It took me a year or two.)

Once people achieve some level of Git enlightenment, they tend to make statements of the form 'Git gets a lot easier once you realize X' -- but that doesn't do much for people staring up Git's steep learning curve.

My goal with this site is to help you, Dear Reader, understand what those smug bastards are talking about.

If your company is hosting code in Github, I sure hope you aren't committing directly to master. This quick screencast demonstrates how to use pull requests so that teammates can review code before it gets merged into the master branch.

GitTracker, or git-tracker, is a Git hook that will scan your current branch name looking for something it recognizes as a Pivotal Tracker story number. If it finds one, it will automagically add it, in the special format, to your commit message.

I was wondering how to stop tracking files in Git, and actually found a pretty good little article on it at this site.

git rm --cached filename_here
This will remove it from the Git repository’s tracking; however, it will still keep the files intact in the actual folder.  The second step you’d probably want to pair with this is creating a .gitignore file and putting in the path or files you want to ignore!

A few months ago we completed a Drupal 5 to Drupal 7 migration project for a North Carolina museum website. Actually the Drupal 5 site was more of a Frankenstein site; the previous developers had more or less built their own CMS on top of Drupal. Fortunately, the superb Migrate module made writing migration code for this project a snap.
Getting a workflow together, however, was a bit more of a challenge. We had four people working on the project: two developers, a site builder, and a themer.
Because the project was complex and contained a number of different components, we agreed that development would work best with each developer building aspects of the site on their local machine. That way my work in writing migration code would not interfere with our themer's work, nor would it bother someone working on site building.
The key ingredients to a local development first workflow are git, drush, drush_make (now included in Drush 5), installation profiles, and Features.
In this blog post, we'll review some of the workflow and tools we used for development. We'll use a fictitous "MySite" project for our example.

En bra video för dig som vill lära dig versionshanteringssystemet Git:

Update 2011-10-07: SourceTree is good enough that it gradually displaced all other git clients. Developer Steve Streeting was productive and responsive, churning out stable improvements. This week, Atlassian (maker of JIRA and other stuff) announced that they had acquired SourceTree (and Steve Streeting). That is probably good news, because it means more resources behind ST. Even better, SourceTree is now free "for a limited time". So now there is really no reason not to get the best git client for Mac.

A BBEdit package to make working with Git easier
The great thing about BBEdit packages in BBEdit 10 is the fact that everything is gathered together in one place. This package contains useful tools for BBEdit & Git.

This package is part "code you can find elsewhere on the internet" (the Git Blame and diff language modules, for example), and new stuff that I just wrote.

One thing I hear a lot from teams that aren't using Git yet is that they've checked it out but it feels really complicated. I remember diving into Git at first and feeling overwhelmed, so I can definitely sympathize. There are so many concepts presented, and very often each article you read talks about a different way to use Git to control your source. In this article we'll talk about the workflow that we use here at Carsonified. We like to keep things simple, and hopefully this will help some teams that are thinking about jumping to Git make the switch.

Version Control
Everything you need to get started with Subversion or Git.

Drupal 7 and Drupal 8 recently added a default (and sensible) .gitignore file to the standard repository, and while this solves some problems, it has also caused some confusion. (issue)

Here's a link to the actual new .gitignore. Essentially, it excludes the sites/default/files and sites/default/settings.php files from git source control.

In this post I present the development model that I’ve introduced for all of my projects (both at work and private) about a year ago, and which has turned out to be very successful. I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management.

For close to a decade, the CVS version control system has been an integral part of every Drupal developer's workflow. Many site builders could get by downloading release versions of Drupal and assorted modules, but using bleeding-edge code, contributing modules, and submitting bug fixes or enhancements to existing projects all meant getting comfortable with CVS. In March of 2011, that all changed: all of the projects hosted on Drupal.org were migrated to the Git version control system! If you're struggling to get your bearings in the new Git world, this article should help with the transition.

With PHP Fog Deploy you can deploy any git repository anywhere. For free.

You can deploy your existing git repository to

PHP Fog - with existing beta account
Amazon Beanstalk
FTP
SFTP
All you do is give us a password and we give you a git origin that is tied to your preferred deployment.

This is my own version of GitX and it meets all my requirements on my day-to-day use of Git on MacOSX.

This is a tutorial on the Git version control system.

Git is quickly becoming one of the most popular version control systems in use. There are plenty of tutorials on Git already. How is this one different?

A Story

When I first started using Git, I read plenty of tutorials, as well as the user manual. Though I picked up the basic usage patterns and commands, I never felt like I grasped what was going on “under the hood,” so to speak. Frequently this resulted in cryptic error messages, caused by my random guessing at the right command to use at a given time. These difficulties worsened as I began to need more advanced (and less well documented) features.

After a few months, I started to understand those under-the-hood concepts. Once I did, suddenly everything made sense. I could understand the manual pages and perform all sorts of source control tasks. Everything that seemed so cryptic and obscure now was perfectly clear.

Understanding Git

The conclusion I draw from this is that you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.

Git is a powerful, sophisticated system for distributed version control. Gaining an understanding of its features opens to developers a new and liberating approach to source code management. The surest path to mastering Git is to immerse oneself in its utilities and operations, to experience it first-hand.

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.

GitHub with Pivotal Tracker is the killer agile combination.
With the just release Tracker v3 API update it is now easy to connect them.

You only have to configure GitHub Post-Receive Hooks so you can automatically deliver stories/bugs by providing the Tracker ID in the commit statement like: Fixes #TrackerId

It's a treasured geek secret that ssh can tunnel TCP connections like ssh all over the internet. What does that mean? It means that you can access machines and ports from your local machine that you never thought you could, including git repositories that are behind firewalls or inside VPNs.

Git is a distributed version control system. No, you don't need to know what that means to use this guide. Think of it as a time machine: Subversion or CVS without the cruft.
If you make a lot of changes, but decided you made a mistake, this will save your butt.
This guide is for people who want to jump to any point in time with their project/game/whatever, and want something to use for themselves.

I used Mercurial for three years, but started switching to Git about a year ago. I now grudgingly recommend Git to anyone who intends to be a full-time programmer. Git's interface is bad in many ways, which is the main complaint about it, and it's a legitimate one. It's just an interface, though, and this is a tool you're going to use all day, every day, in a wide variety of situations.

Here are all of the ways that Mercurial has harmed me, or that I've seen it harm others, and the ways in which Git does good where Mercurial does evil:

It's a land rush of revision control, I tell ya! Among the stable of eager candidates for best-loved DVCS, Git and Mercurial seem to be the two tools capturing the most programmer heart-share for now.

Git is admired because Linus Torvalds wrote it, but Mercurial is better because he didn't.