As the Agile Alliance states, “Version control (also known as source control) is not strictly speaking an Agile “practice”, insofar as it is now (fortunately) widespread in the industry as a whole. Here are our top 10 best practices for Source Control.

1. Source / Version Control:
Best Practices in Agile
© 2015 Intelliware Development Inc.

2. Introduction
As the Agile Alliance states, “Version control is not strictly speaking an Agile "practice", insofar
as it is now (fortunately) widespread in the industry as a whole. It must however be
mentioned…for several reasons:
• Though they are rare, one still occasionally stumbles across teams with outdated version
control tools or practices, and even teams who haven't adopted version control tools at all
• Version control is not merely "good practice" but an enabler of a number of Agile practices,
such as continuous integration
• The Agile community leans toward particular types of tools and practices, namely the same
as the Open Source community: systems that afford concurrent work ("merge" model rather
than "lock"), and more recently favoring distributed over centralized models
• It is therefore beneficial for an Agile team to explicitly reflect on its version control policies
and infrastructure, and ensure that they and its engineering practices work harmoniously
together
Here are our top 10 best practices for Source Control.
2See more at: http://guide.agilealliance.org/guide/versioncontrol.html#sthash.Zh3h1ijE.dpuf© 2015 Intelliware Development Inc.

3. © 2013 Intelliware Development Inc.© 2015 Intelliware Development Inc. 3
If it’s not in source
control, it doesn’t exist!
• Code sitting on your machine is of no
value to anyone else.
• Code sitting on your machine can be
lost.
• It is typically recommended to always
push your code before the end of your
work day.

4. © 2013 Intelliware Development Inc.© 2015 Intelliware Development Inc. 4
Commit often
• A commit, or "revision", is an individual
change to a file (or set of files).
• Commits should be a logical – usually small
– grouping of changes.
• Every commit is ideally a viable rollback
position.
• With a good branching strategy, this is
less important as each branch creates
an ideal rollback position.
• Frequent commits keeps merges small and
manageable.

5. © 2013 Intelliware Development Inc.© 2015 Intelliware Development Inc. 5
Verify your changes
before committing
• Use a different tool to inspect all
your changes to make sure you
are only committing what you
intend.
• Verifying your changes before
committing also helps to avoid
accidentally checking in changes
you meant to revert.

6. © 2013 Intelliware Development Inc.© 2015 Intelliware Development Inc. 6
Build and test before every
commit
• It should be reasonably safe to rollback
to any commit, so ensure it builds and
tests pass.
• Thus a commit should not have code in
an incomplete state.
• While unit tests should be run constantly,
you should only need to run integration /
end-to-end tests before a push.

7. © 2013 Intelliware Development Inc.© 2015 Intelliware Development Inc. 7
Branch.. Branch.. Branch..
• Most features – or important bug fixes – should be their own branch.
• You should NEVER work on the default / head / master branch.
• Branching isolates and insulates your work into clean, manageable
sections.

8. © 2013 Intelliware Development Inc.© 2015 Intelliware Development Inc. 8
Commit messages are
your friend
• Always describe in detail what
changes you have made in a commit.
• Prefix every commit with a reference
to the story / bug ID.
• Commit messages allow everyone to
see at a glance what work has been
done, and is invaluable for historical
lookups.

9. © 2013 Intelliware Development Inc.© 2015 Intelliware Development Inc. 9
Do not commit
generated artifacts
• Generated artifacts such as:
generated classes,
generated docs, compilation
output, etc.
• Use an ignore file to ensure
that these files are not
included.

10. © 2013 Intelliware Development Inc.© 2015 Intelliware Development Inc. 10
Do commit dependencies
where applicable*
• Other developers should not have to
manually install dependencies to get your
code to run.
• The build machine also needs access to
the dependencies.
*Unless your system uses a dependency
management system (such as Maven or
Bower).

11. © 2013 Intelliware Development Inc.© 2015 Intelliware Development Inc. 11
Version your database
• Whatever commit someone is at, their
database should be in sync with those
code changes.
• e.g. The code you pull references
a new column in the database;
this code will fail if the database
schema hasn’t been updated with
that new column.
• Automate revisions, “revision” table to
track DB state, etc.

12. © 2013 Intelliware Development Inc.© 2015 Intelliware Development Inc. 12
Source control is your safety
net. Use it!
• You always have a place to revert to, so
don’t be afraid to play around with an idea.
• You always have the code history so never
comment out code you don’t need – just
delete it.
• Always use the repository tools for
moving/renaming/etc.; otherwise, you risk
losing the history.

13. © 2013 Intelliware Development Inc.© 2015 Intelliware Development Inc.
About Intelliware Development Inc.
Intelliware is a custom software, mobile solutions and product development
company headquartered in Toronto, Canada. Intelliware is a leader in Agile
software development practices which ensure the delivery of timely high quality
solutions for clients. Intelliware is engaged as a technical partner by a wide
range of organizations in sectors that span Financial Services, Healthcare, ICT,
Retail, Manufacturing and Government.
/company/intelliware-development-inc-
/intelliware.inc
/intelliware_inc
/GooglePlusIntelliware
/www.intelliware.com
13

14. © 2013 Intelliware Development Inc.© 2015 Intelliware Development Inc.
Learn more about Agile in our Agile Methodology Series
14