For quite a long time version control systems have been staying irreplaceable tool for software development artisans. They allow smooth team work, keep the history of changes and make the continuous integration and deployment possible. But in order for VCS to become a silver bullet, your team should have definitive set of rules of interaction within it. Here are my top 10 that may be applied to TFS, SVN or most of the other systems, yet the main target is Git: 
1. Create feature branches. It is better to start implementing new major features in a new branch, this will allow you to keep master branch stable and synchronized with your application in production. You will still have a possibility to fix urgent bugs and make minor best throw pillows to master without fear of unwanted changes. Branch name should exactly represent the changes branch was created for and may consist of not only the name but also some sort of namespace (‘add/registration’). It is also very important always to keep the repository in the working state. Sometimes you may need to pause your work, but still you would want to resume it from a different workspace. This may be the case when you need to create your own branch containing pending changes. 2. Give commits sane messages and descriptions. It is very important to name commits properly in order not to spend the whole lifetime looking through git log’s output. Convention of many open-source projects is to place an infinitive in the beginning of the message (‘add’, ‘remove’, ‘update’). In the big projects namespaces also may be handy. Being the first word, they will give you an idea of which part was changed in this commit (‘report: add total field’). I personally prefer lower-cased sentences, but many projects choose regular sentence case instead. 3. Single responsibility of commit. One of the most important rules for me is that changes made in commit should solve just one problem. This rule guarantees you a clean history of commits and gives possibility to name each commit exactly according to its content. It is always weird to see server-side core changes under commit message ‘update html template’ and I believe, you know what I’m talking about. Besides, this rule gives you a chance to safely revert separate commits without any fear of breaking any parts of application you are not aware of. Another point is to commit code style changes in separate commit. This may be spaces to tabs change or windows line endings to Unix one, still these changes deserve their own commit. 4. Look through pending diff before performing a commit. I always thought of this rule as a good one, but recently I have made it mandatory for myself. It is very common to change some configuration rules while testing certain features of your app, and the chances are that you will not bring them back. Furthermore, this rule will allow you to cover all the pending changes you’ve made in order to evaluate them and give your commit corresponding message. That’s why I advise you to always see diffs before the commit. Seriously, always. 5. Avoid committing unneeded files. I hope, that absolute majority of you is aware of .gitignore file which is there to contain the list of files, folders or wildcards which will not be pushed to repository. The first group of such files would be module dependencies which should not be added to repository, but instead installed via packet manager (npm, NuGet, composer etc.). Another group is configuration files for text editors and another development environment programs. I personally always add *sublime* wildcard to gitignore as other team members don’t use Sublime Text editor and these files are useless for them. The basic .gitignore files for different languages and environments could be found here: https://github.com/github/gitignore. 6. Reference issues in commit messages. Both of the most popular social coding platforms implement interface of mentioning issues within commit messages (e.g. ‘fix typo. Relates to #4’). There is also more advanced way of referencing – you can use form of verb close (‘close’, ‘closed’, ‘closing’ etc.) in order to actually close the issue in the tracker (‘add authentication. Close #43’). Even if you have no such integration of VCS into issue tracker, I still advise you to reference issues in commit messages, which will allow you in future to match the commit to a specific issue either manually or with help of some script. 7. Use hooks. Git allows possibility of implementing hooks for quite a variety of events (pre-commit, post-commit, post-checkout etc.) and it may be very helpful if you take advantage of them. The most popular among them is pre-commit hook which allows us to insert some build actions or checks before the actual commit will take place. There are plenty of git hooks bindings for different build systems, here is the one for Grunt on Node.js (https://github.com/rhumaric/grunt-githooks) which allows you to assign hook name to Grunt tasks. 8. Use cli aliases. I love git’s cli and prefer to use it most of times while performing active operations (commit, push, checkout etc.). There is a chance that you’ll get tired of typing the same command on and on and that’s when you find your life-saver represented by git aliases.
$ git config --global alias.co "checkout"
$ git config --global alias.cmm "commit -m"
$ git config --global alias.rh "reset HEAD"
$ git config --global alias.rhh "reset HEAD --hard"
9. IDE integration. In the previous rule I mentioned my love for cli git interface, but it may be extremely useful to have the integration of some operations like blame or diff view into your IDE. Not long ago I’ve discovered a brilliant package for Sublime Text (https://github.com/kemayo/sublime-text-git), which includes most of the functionality you will need. 10. Tagging. You may not be aware that gitallows tagging, which may be used to mark the certain moment in your application development. Most people use it to flag releases and it can be utilized in future by different tools. For example, GitHub has first-class support for git tags and allows one to download each archived release: It is also used by some package managers (e.g. bower) to allow the user to download a certain version of a package. Git is a very powerful version control system which offers you a lot of functionality. It is definitely better to learn it thoroughly so that it becomes your friend, otherwise it can bring you lots of troubles. For more concrete git tips I recommend reading this series of articles by LoicGiraudel: http://hugogiraudel.com/2014/03/10/git-tips-and-tricks-part-1/ http://hugogiraudel.com/2014/03/17/git-tips-and-tricks-part-2/ Node.js guru TJ Holowaychuk tips: https://medium.com/code-adventures/a940ee20862d
