Using a version control system is a must in modern development practices. If you haven’t incorporated its usage into your development workflow yet, I trust the following reasons will convince you to adopt one:

• It allows you to keep track of changes to files.
• You get a full record of what has been done on a project so far.
• You can revert to previous versions should you ever need to.
• It facilitates collaboration: multiple people can work on the same project and all changes will be merged into one source.

If your workflow often includes interacting with others, or even if you’re working on a project all by yourself, sooner rather than later you’ll learn to appreciate the benefits of using a version control system.

Which version control system to use?

Several distributed version control systems have been developed over the years to help teams stay as productive as possible. Some of the most popular/known ones -at the time of writing at least- are:

• Apache Subversion, also known as SVN
• Git
• Mercurial
• Perforce
• Etc

For web development the most widely used at the moment is very likely Git which will be our focus on this article. Why? Because, why not? Git is open source, all major online repository services (eg. GitHub, BitBucket, GitLab, Beanstalk, SourceForge, etc) support it, and its learning curve is moderate – it won’t take you weeks or months to get the gist on how Git works.

If you’re new to Git or to distributed version control systems in general, I recommend checking out GitHub’s Resources to learn Git to get started.

Using Git in your projects

Great! So now you’re using Git in your projects. But, how exactly should you be using it? Below I’ll be sharing some of my personal views on the matter, if you have any suggestions/observations feel free to leave a comment below.

Keeping track of changes

What to track and what not on a git repository? Should you just be tracking everything and that’s it? Well, the answer largely depends on the kind of project you’re working on.

For example, for WordPress based projects it’s recommended to exclude from the repository:

• Core WP files: WP files in the root directory, the wp-admin folder, the wp-includes folder, some folders inside the wp-content directory (exceptions being the theme folder and the plugins directory since those are being actively used in your project).
• The files/folders inside the mu-plugins directory (unless they’re actually being used in your project).
• The uploads directory, its files and folders belong only in the staging/production server.
• The upgrade directory.

In order to exclude said files/folders you’ll need to use a .gitignore file.

For most projects, WordPress or otherwise, you should also be excluding:

• OS related files (.DS_Store, desktop.ini, Thumbs.db, etc.)
• Node/Grunt/Bower/Composer dependency (vendor) directories (the developer cloning your repo can install these by themselves).
• Hosting related files/folders (eg. WPEngine’s _wpeprivate folder and the plugins they automatically install on the mu-plugins directory).
• Personal IDE configuration files.
• Log files and databases (.log, .sql, .sqlite, etc.)
• Packages (.zip, .dmg, .iso, .jar, etc.)

The GitHub team currently maintains a massive collection of useful .gitignore templates so when in doubt feel free to check them out and use the ones that better fit your needs.

Big Commits or small commits?

When working with Git repositories you’ll want to avoid committing changes that cover a lot of topics at once. Here’s why:

• Big commits are hard to revert. Typically you’ll need to undo only a subset of changes but if these are all grouped under a single big commit (eg. “Fix XSS vulnerabilities + accessibility fixes + adding unit tests for Y component + dependencies updated”) then you won’t be able to do so. You’ll have to manually undo whatever needs to be undone, when you could just use the revert command to undo specific changes.
• Big commits are harder to understand. If you’re reviewing a change (like a Pull Request for example), browsing a sea of code to make sure it can be safely integrated into the codebase can be challenging. Smaller changes are easier to understand and follow.
• Big commits are hard to summarize. When committing a set of changes, you’re given the option to add a summary of the modifications you’re pushing to the repository. If you made a lot of changes you’ll find it very difficult to summarize what you did in a way that’s helpful to others checking the repository at a later time.
• If you use Continuous Integration in your workflow, big commits are very likely to cause merge conflicts. Making small changes and putting them in single commits will minimize the chances of merge conflicts happening.

Working with branches

This topic deserves an article on its own. Fortunately I don’t have to write one as there are a lot of good articles on the matter out there already and I’m sure I won’t be adding anything new. Here’s one I can personally recommend: A successful Git branching model, by Vincent Driessen.

Happy coding!