If at one point you were struck by the desire to implant a reasonable, kind, eternal, and transplant everyone from SVN to GIT, three problems immediately arise:
- Explain why developers and managers need this
- Introduce a new code handling scheme
- Teach unsuspecting developers new techniques.
Since we are using a very efficient scheme for working with code through git in one of the projects, I decided to implement it everywhere I reached where my hands were. list of commands and gestures for the developer with the new system.
The main postulates of working with the code:
- Each task is solved in its branch.
- Commit as soon as something got meaningful.
- In master, it is not the developer who is merging, but the second person who is reading and testing the change.
- All commits must be intelligently signed.
- The repository should keep dry and silky.
Since some developers for some reason work under Windows, it was necessary to describe including installation-setup-recipes when working under Windows.
With the instruction, I throw in all new and old developers, who give access to repositories with working code.
')
I warn you right away that the instruction answers the question “why” to a developer unfamiliar with DVCS, and not to the authorities.
It is also assumed that the master branch is never touched with --force, it is desirable that this was impossible at all (slaughtered at the level of gitolite).
Instructions - novice developers, not Tips & Tricks, from these considerations, I lowered the moments of "coming out of a self-created ass." I do not remember all the cases, it is much easier to settle on the spot in fact if something out of the ordinary.
Actually instruction:
Working with Git.pdf (135Kb) .
For those who want to adapt it to their situation, the source:
Working with Git.odt (90Kb) .
ps: I forgot to say about the license: Public Domain. Do whatever you want, just do not throw in the bush.
I would be grateful for any useful comments, an indication of ochepyatki and other feedback.