четверг, 8 декабря 2011 г.

Using git: intro

You can google lots of info/manuals on Git everywhere across the Internet, but casual and easy understandable intros are not yet widerly available so I'll try to make a small contribution here by posting my own simple introduction to Git.

To start using Git, I guess, you have to switch from some other source control system like Subversion, Perforce etc. And that switch is not just about installing new software and migrating your data from one system to another. It is much more: you have to switch your mind from using one development approach to completely different. I believe many things that were very straightforward with Svn tend to become quite complicated with Git and vise versa.

So switching from Svn to Git is a process of figuring out how work processes are transformed to Git world and how can you deal with them.

Git is a decentralized source control system. What does it mean actually? Suppose you use centralized source control such as Subversion, Perforce or Cvs. The word "centralized" means that the development history for all your files is kept on some remote central server everybody uses to perform the majority of operations: to view your changes, to commit them, to merge from other branch and so on. On the other end, "decentralized" word means that the development history is not kept on some remote server but is stored locally by all project users.

Using Git is pretty much like using Svn with server installed locally by all users and synchronizing all those repositories together. So, in Git world commit, diff, merge, log are all local operations that work with your local development history database. The operations to synchronize your local database with some remote database are called pull (to apply changes from remote repository to your local repository) and push (to apply your local changes to remote repository). Those are in fact the only operations that require network. This is the source of Git good performance on regular operations.

In Svn when you make a change, you just run commit and get it published on remote server so that everyone will get it when updating. In Git you also commit the change, but it only becomes stored in local database. To actually publish your changes you'll have to make "push". You can make several commits before actually pushing. You can even do often micro-commits and do not think about spamming your continuos integration system (such systems are often setup to trigger a new build each time a new commit is available in main repository -- so people who are commiting very often are effectively breaking the benefit of building every commit: because of massive small commits the actual bad commit is unlikely to be tested at the time it is uploaded to main repository because it has to wait in queue for a long time)

Does being decentralized bring anything useful? Well, yes.
-- central repositories are slow when syncing from a remote repository that is installed somewhere very far (suppose updating in Portland something that is hosted in Berlin)
-- decentralized means "easy" branching/merging
-- decentralized means you do not break anything when committing because you are commiting locally

Комментариев нет:

Отправить комментарий