If you try to develop software with more than one developer involved, you run immediately into problems. While working, developers change something and all the other developers involved in that project need to update it in some way. If the changes were not that good, there should also be a possibility to rollback to a previous state or to restore the code in other ways. The problems even get harder when the developers are spread in different time zones all over the world.
The first solution to that problem is a centralised repository. This repository is managed by a revision/version control system. Changes are usually identified by a number and are called revisions. For example, an initial set of files is revision 1. When the first change is made, the resulting set is revision 2, and so on. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merge (Figure 1).
Figure 1: Centralized Workflow (Image https://github.com/schacon/whygitisbetter)
There are different strategies to work with different versions of code. One important word in this context is commit. Commits are operations which tell the revision control system you want to make a group of changes you have been making final and available to all users. Depending on the strategy of the system, commits are "atomic" or "file based". There are pros and cons for each strategy.
If you have a big team of developers it is often the case that they are working on the same source code file. After a commit, the old and the new file have to be merged. This is easily possible in text files and nearly impossible in media files (images, sound, video).
Most projects have different versions of the software like a stable branch and a development branch. Therefore, it is necessary to have a kind of tagging feature in the system.
Distributed revision control
The repository is still central (the blessed repository), but in a distributed model the developer is allowed to have different versions/branches on the local workstation. The developer can decide whether the branches are public or local. This feature has a few advantages.
It is possible to
- create a branch, try out an idea, play around with it (commit, switch back), then merge it to the central respository.
- have branches from different states of the software
Depending on the size of the project, there has to be one person (integration manager) that pulls the changes of the developers in to the central repository (Figure 2).
Figure 2: Decentralized Workflow (Image https://github.com/schacon/whygitisbetter)
Dictator and Lieutenants Workflow
If the project is bigger, like it’s the case for Joomla!, another level of hierarchy is used. The first integrators (lieutenants) are running a subsystem to merge in all the changes. Afterwards the next integrator (the boss or the dictator), which is only able to merge the changes of the subsystem, is responsible for the central repository Figure 3).
Figure 3: Dictator and Lieutenants Workflow (Image https://github.com/schacon/whygitisbetter)
Software like GIT is called distributed revision control system (DRCS). Distributed version control or decentralised version control (DVCS) keeps track of software revisions and allows many developers to work on a given project without necessarily being connected to a common network.
The name and the history
Git was initially designed and developed by Linus Torvalds for Linux kernel development. The name git is British English slang for a stupid or unpleasant person
I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git.
GitHub is a web-based hosting service for the Git revision control system. GitHub offers both commercial plans and free accounts for open source projects. GitHub is a kind of Facebook or Google+ for developers, you will love it.
Joomla! and GitHub
In 2011 the Joomla! CMS and the Joomla Platform moved to GitHub - https://github.com/joomla
How to start?
Just create a user on GitHub and download the GitHub client to manage your local branches. In your local GitHub client you have to sign in and can start creating repositories. Try it - it's easy and fun (Figure 4)
Figure 4: Git Client (OSX)