Git workflow

1 Introduction

The topic covers not so much the details of working with git, but its differences from the development scheme of other version control systems, and the general approach (developed mostly by personal experience and the Git Community Book) to work.



')
Modern software development has become something more than just a set of program source code in a text editor; It has acquired a whole range of additional tools, such as bug trackers, project management systems and version control systems (SCR). The latter, perhaps, play a special role in the project, since they determine the course of work (or workflow).

2 Centralized Version Control Systems

A classic example of such programs in the open source world is CVS and its descendant Subversion (the project’s slogan is “CVS the right way”); proprietary analogues: Perforce or Clearcase. These systems are built around a centralized development model in which there is a single remote repository, in which all project developers make changes. Branching a project is possible, but not desirable and, as a rule, brings only additional complexity to the project.


The standard course of development looks something like this: pumping out the latest version of the repository; development of new functionality or correction of errors; re-appeal to the repository to resolve possible conflicts with the work of other developers; uploading another revision to the server.


The corresponding commands are: svn checkout (pick up the latest version), svn resolve (show that the conflict in the source code is resolved) and svn commit (create the next revision in the repository).


Such a linear approach to development is simple and obvious, but it limits the programmer greatly. But what if at any stage of the cycle you want to be distracted by another functional? Or urgently fix any bug in previous work?


There are different ways out of the situation. You can show firmness, and finish the current work, then to turn to the following stages; or, alternatively, load the current commit with a large number of changes.


In the first case, there is not enough flexibility; in the second, the search for an error in a commit is complicated, the logical integrity of the action is violated.


Roll back to the initial state is impossible - it means losing the work already done. Well, or, if you complicate it completely, make a separate copy of the project, correct the error in it (add functionality), commit, then erase the copy, and return to your previous work ... Is it difficult? Complicated. Not an option, in other words.


In addition, it is sometimes necessary to work without access to the central repository (remote work, travel, etc., etc.). What to do? Lose any development flexibility and fill in a monstrous commit commit per week?

3 Distributed approach

The solution to such problems was an alternative development scheme proposed by the so-called Distributed Version Control System.


Among the open development on this topic, you can remember git, Mercurial and Bazaar. The first project is especially interesting, it is used in some of the most complex modern software systems (Linux Kernel, Qt, Wine, Gnome, Samba and many others), it works extremely quickly with any amount of code and is now gaining popularity in the open world. For a while, the lack of documentation had a negative effect on the distribution of this program; but now this flaw can be considered eliminated.


So what is the global difference between git (and DVCS in general) from centralized counterparts?


Firstly, as the name implies, there is no main (in the sense that it is understood by developers who are used to SVN) repository. Each developer has its own full-fledged repository, with which it is working; work is synchronized periodically with (purely conditional!) central repository.


Secondly, the branching and merging operations are placed at the center of the programmer’s work, and therefore they are very lightweight.


By the way, habitual revisions also do not exist; But more on that later.

4 workflow in one face

, : , — .


:


git init


— .git , ( .svn, !). , , git add:


git add .


:


git commit -m " "


! . , - . :


git branch new-feature


( SVN):

git checkout new-feature


, , :


git status
git add .
git commit -m "new feature added"


, (master) ( ) . :


git checkout master
git merge new-feature


, ? , , diff .


, : , . . , , … — git stash. :

git stash


( stash):


git stash apply


. . «» (stash) ; .


; , . ( , ) . , , , : git tag ; git tag -a , - (). .


! , : «» , , . , .git , SVN.


, ., .. , ~/site-lisp, ; : work home; /etc. , git.

5

— , . github.com, , - git.


, :


git clone git://github.com/username/project.git master


, master project. . , , :


git branch new-feature
edit README
git add .
git commit -m "Added a super feature"


, , :

git checkout master
git pull
git merge new-feature


, .


git pull (remote branch), . .


() :

git push


, . , , .


, . , , «» , «» .


. : . , , , .

6

, , git ; . ; , .


, , . :)


UPD: Git
UPD2: , :)