Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.
Self Hosted Git Management. Fast, secure and stable solution based on Ruby on Rails & Gitolite. Distributed under the MIT License.
glip, a git library in PHP, enables your PHP scripts to access git repositories. Written in pure PHP5, it works without even having git installed, thus making it the ideal git library to use with your el-cheapo web hosting service.
This project is an attempt to make the git command line a friendly place: it eases the learning process by providing guidance and high level commands.
Gitorious is an open source Rails application for managing your projects: Git repositories, wikis, timeline and more. Not identical to, but not completely unlike GitHub. Being open source means you can set up your own Gitorious, even in private mode and host all your company's projects. In this article I'll show you how to get it running.
Setting up Gitorious on your own server
This page gives brief, visual reference for the most common commands in git. Once you know a bit about how git works, this site may solidify your understanding.
This article provides an overview of the interna of a git repository.
My Evernote tech-tips folder and my Notational Velocity stash have been collecting a huge list of git tips, many of which I have to look up again and again. Until I finally give up and create aliases for them (by the way you can find some of my more advanced git aliases explained in my previous post).
I expect many git practitioners will find them useful as much as I do. Here we go, let’s start from tiny and simple things first.
In my pursuit to understand Git, it’s been helpful for me to understand it from the bottom up — rather than look at it only in terms of its high-level commands. And since Git is so beautifully simple when viewed this way, I thought others might be interested to read what I’ve found, and perhaps avoid the pain I went through finding it.
In addition to knowing how to effectively contribute to a project, you’ll likely need to know how to maintain one. This can consist of accepting and applying patches generated via format-patch and e-mailed to you, or integrating changes in remote branches for repositories you’ve added as remotes to your project. Whether you maintain a canonical repository or want to help by verifying or approving patches, you need to know how to accept work in a way that is clearest for other contributors and sustainable by you over the long run.
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.
An efficient workflow for developers in Agile teams that handles features and bugs while keeping a clean and sane history.
At Hashrocket we use git both internally and in our Agile mentoring and training. Git gives us the flexibility to design a version control workflow that meets the needs of either a fully Agile team or a team that is transitioning towards an Agile process.
There are many usable git workflows. Indeed, git is really “a tool for designing VCS workflows” rather than a Version Control System itself. Or, as Linus would say, git is just a stupid content tracker.
This is by no means a normative document or my attempt to define The One True Workflow. I have found this workflow to be productive and relatively painless, especially for teams that are still learning and transitioning towards a more Agile process. I invite you to comment below and describe the git workflow that works best for you.
When I first started working with Git in mid 2008 I was blissfully oblivious to the concept of a "rebase" and why somebody might ever use it. While at Slide we were crazy for merging (see diagram to the right), everything pretty much revolved around merges between branches. To add insult to injury, development revolved around a single central repository which everyone had the ability to push to. Merges compounded upon merges led to a frustratingly complex merge history.
With the rise of Distributed Version Control Systems (DVCS) such as git and Mercurial, I've seen more conversations about strategies for branching and merging and how they fit in with Continuous Integration (CI). There's a bit of confusion here, particularly on the practice of feature branching and how it fits in with CI.
I am able to use it more or less; but I always feel a little scared and confused about what's happening. I feel that I want more informations. I have followed some tutorial and read distractedly some book but, with too much information I always end up with just the feeling that I could do what I want to do. But I do not know how to do it.
This talk introduces the Git Version Control System by looking at what Git is doing when you run the commands you need to do basic version control with it. We'll look at how to use Git to do the basics, while seeing how it differs from Subversion, what staging and committing actually looks like, how it stores it's data, how it branches and merges so nicely and how it talks to a server when pushing and fetching. Then we'll look at how to look at your history with log in interesting ways. This should help Git newbies get acquainted with the popular VCS and other Git users get a glimpse of what's happening under the hood.