Using source code repository

While working with source code repositories one should remember about few basic rules starting from what should be stored in Git to project repository layout.

What to store

Everything that is necessary to do a build should be in the repository including not only code but also test scripts,properties files, database schema, install scripts, and any third party libraries (which are not handled by Maven's dependency management). That is, as stated by Fowler [Martin Fowler. Continuous Integration. Technical report, ThoughtWorks, May 2006], it should be possible to walk up to the project with a virgin machine, do a checkout, and be able to fully build the system.

Source code repository is the primary area of storage for the project artefacts and should contain:

• Source code
• Test scripts
• Database scripts
• Installation scripts
• Project schemas
• External libraries (if and only if Maven dependency management cannot handle them)

What not to store

Repository must not contain any direct results of the build i.e. jar/war files, logs etc. In case of Maven driven projects, adding the target folder to .gitignore solves most of the problems. For Maven projects you should also ignore Eclipse's project files (.project, .classpath, .settings) - as they are dynamically created and updated by the m2eclipse plugin.

Developers must not commit to the repository the following artefacts:

• Results of builds (.jar, .war files, logs)
• External libraries that can be handled by Maven dependency management
• IDE’s project and configuration files

Branches

Branches are used to manage work that may be later merged back into the main trunk or originating branch. Using branches helps preserve the integrity of the trunk.

There are two basic scenarios for using branches:

• Feature branches – used to implement particular feature which might not be ready before next release. Name of given branch should start with a word ”feature” and contain identification of JIRA issue which describes given feature, e.g., feature_PROJECT_IDENTIFIER-1.
• Bugfix branches – each new release should result in creation of branch which contain a stable, editable snapshot of software at the time of release. This branch would be the base for further maintenance releases. Bugfix branches names should start with a prefix ”bugfix” followed by the particular version number associated with release e.g. bugfix_1_0.

Tags

Used for bookmarking or taking reference (non-editable) snapshots.

Tags are used to mark specific releases or phases of development, in order to be able to retrieve and inspect a past release exactly as it was. Unlike branches, tags do not impose any maintenance costs, so they should be used liberally in order to track the release history.

Git

Git is free and open source distributed version control system. In opposite to centralized version control systems it supports multiple workflows (creating local branches that are independent on each other) and local staging. Because there is no a central server, each developer possesses entire copy of the whole re-pository. Elimination of the single point of failure significantly increases the security of the repository. Lo-cal staging means that even different parts of a single file can be committed independently [06]. Since majority of operations is performed locally, Git is definitely faster than other centralized systems. Be-cause of all its features, Git is not recommended for projects implemented by a single developer.