Many times alternatives for version control systems are on topic, Git is a viable candidate. Arguments are not enough, though. One must answer the questions regarding then whats and hows?
Let us lay out a project utilizing Git for versioning source code, artefacts and assets etc.
First thing to mention: its distributed nature is not the first thing to talk about. It is the core feature, but not the most important quality to consider first. At the beginning it should be shown beforehand that it is able to fulfill the requirements of version control at all.
In addition to remote repositories, Git also treats each working copy as a repository, in fact, they are local repositories per se. This makes every desired state perfectly revisionable, even local ones. On the file system level, only one particular snapshot (e.g. development state) is available, but you can take arbitrary snapshots. Commit and update refers to the interaction within this local repository.
Having a desired changeset, diff to share, you can use the push and pull operations to branch and merge between repositories available on the network. So you can for example push your local changes to the repository you were forking it in the first place from, or you can pull and merge the changes available in between repositories.
Please note that we are still considering a centralized management of the branching strategy. I.e. there can be several team level but one project level branch, and there can be additional release branches for each released revision (and their follow up bugfixes), and there can be sandbox forks to play around, and so on, but all in all, there are rules for where you can push to and pull from, enforced by rules of thumb (a.k.a process), hierarchy of trust (a.k.a review) and access control (a.k.a roles).
Who does the pushing and pulling, and more importantly who resolves conflicts? Git allows a great deal of flexibility here:
You can have dedicated people responsible for pushing all the changes upstream or pulling all the changes from downstream, resolving conflicts as they arise. Or you can have each person responsible for pushing each change from downstream to the top by following the process, getting reviews and acquiring required roles, but also resolving conflicts as they arise.
And a mixed approach is also feasible where for example team level changes are usually not branched but just pushed into the master repository, albeit changes which should go into release branches are pulled by individuals responsible for the release branch.
So wherein lies the distributed nature of Git? By treating everything as a repository and giving flexibility on how to distribute responsibilities, upstream and downstream become relative terms. For the individual a clear hierarchy remains, can pull safe changes, and push resolved revisions. On the team level sub-teams and ad-hoc working groups find it intuitive to share code at any time, or just to fork a sandbox repository which can evolve on its own later on. Git can basically do whatever you expect from a centralized revision control system, but it heavily supports branching and merging across revisions. It does not force you to look at the project from the same perspective.
If you need tools to work with Git, its command line client is indeed sophisticated and once getting used to the terminology it serves as the best Swiss knife. However, GUI tools and enterprise integration is evolving at its best, you better check your environment and requirements, especially paying attention to the needs of every single one on the project beforehand.Views: 2300