Bureaucrats, confirmed, Administrators
4,558
edits
Changes
no edit summary
The Git system (http://git-scm.com/) was originally developed by Linus Torvalds as a distributed version control system to replace BitKeeper for the Linux Kernel project
The bottom line is this: modern software development may take many "forms", but it usually boils down to [http://nvie.com/posts/a-successful-git-branching-model/ this]. Git enables such a branched workflow.
== Intro to Git ==
Why do we have git? Because [http://whygitisbetterthanx.com Git is better than X] Now that we have the "My DVCS is better than your DVCS" argument out of the way, you can actually get some valuable insights from that website if you are interested in comparing Git with Mercurial, Bazaar, Subversion or Perforce. If I had to single out one primary advantage of Git, it would be that it actually features branching and merging.
}'
</source>
== Documentation ==
* http://wildlyinaccurate.com/a-hackers-guide-to-git Helpful intro because it doesn't pretend that Git is just like Subversion
* http://git.or.cz/course/svn.html
* http://software.complete.org/software/wiki/site/GitGuide Git Guide (short) at Software Complete.org
* '''http://book.git-scm.com/index.htmlbook/en/v2'''
* http://git-scm.com/documentation
* http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
* http://www.kernel.org/pub/software/scm/git/docs/git-config.html
* http://github.com/guides/providing-your-ssh-key
=== Git and Subversion ===
* http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion
* http://flavio.castelli.name/2007/09/04/howto_use_git_with_svn/
== Git Repo Hosting ==
It seems everyone uses GitHub these days. It's not a bad solution, but there are some drawbacks, and whether you're just looking to host your own project or setup enterprise-wide git hosting, there are other ways to host your projects in Git. Let's take a look at some options.
The current Wikimedia Ops team is using [http://gitblit.com/ Gitblit] to drive https://git.wikimedia.org/ Gitblit is an open-source, pure Java stack for managing, viewing, and serving Git repositories.It's designed primarily as a tool for small workgroups who want to host centralized repositories. It comes in two options: GO is an integrated single stack solution so you can really get up and running in no time flat; and there is a WAR version (assumes you already have a servlet container like Jetty or Tomcat.) Gitblit requires a Java 7 Runtime Environment (JRE) Gitblit comes with a lot of [http://gitblit.com/features.html features] == Now what? Background ==
I got into Git to make managing Drupal projects possible. Now that we have a distributed VCS, we can actually collaborate in multiple ways (more than just a centralized model<ref>http://whygitisbetterthanx.com/#any-workflow</ref>), and we can work offline . We can easily branch and merge. We can pull in updates from the Drupal core maintainers. We can pull in updates from the Drupal community (module maintainers). We can track our own custom modules - especially if they are developed by more than one person. We can branch, tag and deploy these combined sources to multiple instances (dev, staging, production) across multiple instances of Drupal (e.g. client projects that should share the exact same codebase) and have complete clarity on where each project stands regarding patches and security fixes or updates. There have been several attempts in the Drupal community (credit to Moshe, Ben,<ref>http://drupal.org/node/197666</ref> Dries, et al.<ref>http://drupal.org/node/355154</ref>) to get this all working over the past year or so and I think we're finally seeing the tide turn in our favor. Drupal may actually start to be "easy" to maintain and deploy. Actually, the whole point is to BE up-to-date on all our projects. This only happens when it is feasible. Git makes it feasible.
* http://versioncontrolblog.com/2007/08/02/upgrading-drupal-52-with-git/
I pulled down the whole clone (which is only 26MB in size) of mikl's public history of Drupal in a few minutes.
With Git , it is even possible to manage projects which are composites of multiple sources <ref>http://git.or.cz/gitwiki/GitSubmoduleTutorial</ref> (Ever tried that with Subversion's 'externals'? -- Don't bother to try it with Subversion because it just doesn't work! Not only are externals feature poor, you'll still end up wanting to merge even more than before. And as we know, merging is not a feature in Subversion.)
Only in /var/www/drupal/sites: www.example.org
</pre>
== How it was done Building a Git server == (This recipe was from 2008. It may still work, but ymmv)
Generally following the series of instructions at