Version control

Git and Gitflow

The vast majority of front-end projects use the Gitflow branching strategy. I highly recommend using the command line helper for this, if possible, to remove a lot of the repetitive merging tasks and potential for human error.

Gitflow, in short, is a scheme that determines where code is branched from, where it merges to, and identifies a specific naming strategy for the branches in between.

• main (or master, on older projects) is production ready code. This branch is deployed to live and live-staging environments. Only release and hotfix branches may merge into main.
• develop is where feature-complete, but not necessarily well-tested code goes. This is code suitable to a QA environment. In git flow dogma, changes should never be committed directly onto develop, and should always be merged into it via release, feature, bugfix, or hotfix branches.
• release/ branches are used when taking code from develop, for preparation to merge into main. This is the code used for UAT purposes. Release versions should usually be named and git-tagged according to semantic versioning.
• feature/ branches are areas for active development of new features. Feature branches are merged into the develop branch upon completion.
• bugfix/ branches are for non-critical bug fixes and work identically to feature branches, being merged into the develop branch upon completion.
• hotfix/ branches are for critical bug fixes (that is, bugs on live that must be resolved promptly). Upon completion, these are merged into both the main and develop branches.

Older projects may have only used the main/master and develop branches. These can normally be migrated to using git flow without any architectural changes, with some exceptions.

Version controlling assets

Many of our projects have front-ends that work on the principle of having a source (src) directory and a distribution (dst or dist) directory.

The source directory contains the raw assets for the project, such as Sass code, TypeScript, unoptimised images, etc. It is the only one that is directly modified and should be stored in source control.

The distribution directory has everything that is needed for the website to function in a browser. Compiled CSS, JavaScript, optimised images and the like go in here. Destination directories should not be in source control, and their contents should be entirely generated by build tools on both developer machines and the build server.

Basically: Source is the only one that needs to be in source control, distribution is the only one that needs to be distributed anywhere, and never the twain shall meet.