Why git

There was a time when I did not know anything about VCS, nor what it is, much less why it was for me. And he considered daddy with archives of versions the height of his achievements. By the time I became aware of the need for a version control system, I had already filled the cones and felt the need for such a tool. But the Borlandian analogue CVS did not impress me. Each file has its own version number. How do I get a cut of a specific release, I did not understand. Meanwhile, SVN triumphantly went through the minds of developers. Damn, that was what I missed so much. After reading the dock and starting to work, I just fell in love with her. Yes, there were difficulties and certain inconveniences, but where without them.
So I would work in SVN, but nothing stands still. The Internet has already flowed thin streams of news about Git. I don’t rush after every new technology, and a lot of time has passed before I used all the brains with this Git. I was curious, I first looked at, tried on, and then spat and started a new project on Git. I was tormented with the guys for 2 weeks, pumped up literature, wrote a cheat sheet ... nothing, got used to it, ... and then it kicked me out.

Now they regularly ask me to tell you about Git and what is in it. Already tired, so this post is for those who still doubt.


All locally
Repository, history, branches and commits.
From here 2 important consequences follow: everything is very fast, and the second - you get absolute control over the repository.

• Create a repository in the current directory - "git init". Everything.
• Just one daddy .git and no pornography in the form of .svn in each directory.
• Internet is not needed. Working alone is gorgeous - a local repository that takes place in a split second. Work in a distributed team - each has its own copy of the repository, no one depends on the availability of the central server.
• No need to think about creating a backup system. Each participant has a copy from which you can pick up the original.
  Raise your hands to those who raised the lost svn-repo from their copy of the git-repository .
• In your repository, you do whatever you want. Any branches, no one will see them.
  Hell, I remember how I was forbidden in SVN to create a separate branch to work on an experimental version.

Control
In Git, you can do anything with commits and history:

• Delete commit as if it was not there.
• Edit commit comment
• Swap commits
• Merge several commits into one, especially when you need to “dokommitit” something forgotten
• Split a commit into several

Branches:

• Transfer / copy commit from one branch to another
• Move branch to any location

It is very well described here: http://gq.net.ru/2009/12/16/ git-history-rewrite /
From such opportunities blows the head and it can seem to someone too dangerous. Yes, a couple of times I lost commits due to my inexperienced manipulations and then rummaged through the “basket” to restore them.
But as you get used to it and understand what and how it works, your wings grow and you begin to work much more efficiently, receiving in passing a lot of pleasure from it.
')

Branches
Git is branches. It is so simple, flexible and convenient that everything is done in the branches. From release to small tasks.

• Create a branch, switch into it, merge branches, go back - these are routine operations.
• Murjit is a pleasure. There are conflicts or not, everything goes very easily and nothing is ever lost.
• With the exception of release, most of the branches are very short and live 1-3 days.

Commit
To make a commit, you need to specify which changes you need to put there. Changes, not files. “Git add” should be called for both modified and new files. Thus, a temporary state is prepared, which I call a “temporary commit” (in the original “staging area” or “index”).
What is the advantage:

• I can always see what I will commit and what will not fall into the commit
• Since git accepts “changes”, I can put in a commit only part of the changes in one file, and roll back another part in the same file or put it in another commit.
  
  Last time I use only “git add -p” - Git shows a chunk after a chunk (a set of changes within the file) and asks whether to add to the commit or not. So I see that I have changed and will commit. And therefore I will never get a debugging code, comments, extra edits, spaces in my commit. And the commits are clear and atomic.
  

Dif and log

• I can look at the diff of an entire branch or group of commits, so as not to flip through a commit, especially if they are illiterately decorated.
• I can see the difference between 2 branches, see what commits they differ in.
• View differential without spaces (git diff -b -w), if someone became interested in formatting and turned the differential into one mess.
• I can configure a bunch of aliases in the config that will output logs of commits in different formats, for example, generate a change-log .

The log is generally an abyss of possibilities.


Stash
I am working on a task, disassembled a project into parts, and then I have to drop everything, switch to another branch in order to fix a bug or conduct a review. I save my edits in a temporary state (stash), switch, do everything I need, go back, restore my edits and continue to work.


Bisect
The command for finding the commit in which the error was made. I indicate the commit where I know for sure that this error does not exist. And a commit where this error already exists. Next, Git selects the commit for checking by binary search, switches to it and offers to answer whether there is an error here or not. And so on until an erroneous commit is found. If possible, you can write a script that will automatically check for an error and return the appropriate code. Give this script to the bisect and get a broken edit.


git-svn - for those in the underground
You can work locally in Git and commit it in SVN. No one will even guess if you yourself do not sweep through your happy face. You can easily unite with your colleagues underground workers and share branches and edits from your repositories.


Submodules
Git allows you to include other projects in the project. They are connected as submodules:

   $ git submodule add git: //github.com/maxim-oleinik/sfDoctrine2Plugin.git plugins / sfDoctrine2Plugin

Git will create the “plugins / sfDoctrine2Plugin” directory and deploy another repository there, and put the revision hash under control. If you go to this directory, we will get into another project. There you can work and commit as usual, only in the parent project Git will show that the subproject has been updated and will offer to save the link to the new commit.

• It is convenient to work in the main project and commit at the same time to different submodules.
• In Git, you cannot connect specified directories from another project, as svn: externals does. Only the whole project.
  That's the point, to allocate independent modules and arrange them into separate repositories. True, it becomes a little inconvenient to work when the submodules have their own submodules, etc.

GUI and console
I honestly don’t know what Git GUI is. I have never used it and recommend not depriving myself of the pleasure of working with Git in the console. Do not turn into monkeys who are looking for the right button or tick in the interface, instead of just typing a command in the console.
Okay, no offense. I just wanted to say that working in the console is much richer and more convenient.
Who does not have a normal console ... well, then choose a GUI, IDE or ... OS, which has this console.
The only window I regularly use is gitk-all &. It shows a commit tree with branches and tags. It is very convenient to see where you are now, where are some branches and how they intertwine. There is a simple search and viewing differential.


Teamwork

• In git, you cannot block access to a specific branch or module. Or all or nothing. But this has never caused me any problems. If someone made a mistake and commanded the wrong place to where he should have been (as we agreed in advance), then I will simply roll back these edits as if they never existed, and will have an explanatory conversation.
  Alternatively, you can select a separate repository with limited access and working - for all.
• All tasks are done atomically in the branches and in the same form are transferred to the review and merge. That is, if desired, no commit will fall into the main trunk without a review.
• It is very convenient to conduct a review of the task, which is performed in a separate branch. View the full diff of all commits, fix something , comment, send back for revision, and then merge individual commits and merge into the main branch.

Github
This is a cool platform where you can post and publish your repository for free. Where a lot of projects live, which are forged, developed and discussed. Now there are all my projects.
Free for open projects and min 200 rub / month to close access.



This is certainly not all that Git can do. There is a lot of everything that I have not told, and which I still do not know yet. I tried to highlight the main points.
Git, of course, has certain drawbacks and difficulties, but without them there is no. Yes, they are not significant. Most often this is a git-way question.
True, Git has one serious drawback - it is not for the lazy. So think ahead before offering Git to these guys.

What's next

Next - start working. You can read a bunch of reviews and discuss as much as you like, but until you start working, nothing will change.
In one day I rummaged through the dock and started working, I got used to it for 2 weeks, after a month I taught the others, after 3 weeks I spread my wings.

How to start

1. Download, install and configure, I think no one will have problems. Read more articles in this blog about settings and other features.
2. Read any book listed below. True, read. Though diagonally, but you will know that in general there is. This is easy to do in a couple of hours.
3. And start working on a new project or transfer an existing one (import is not difficult).

There is a cheat that will help with the teams for the first time. There is a "git help <command>". I recommend not to be lazy and regularly read the help for each new team, and then read and reread. So I learned most of the possibilities, subtleties and nuances.
Well, write, if something is not clear. It is very difficult for me to understand what obvious things to me are not understandable to beginners. For the second article will not matter.

References:

• The book " Pro Git "
• Git Community Book
• The book " Pragmatic Version Control Using Git "
• The book "Git Magic", found here: http://habrahabr.ru/blogs/Git/80909/
• Git-SVN command comparison
• Editing history in git
• My rules for commits and branches
• My cheat sheet