Home :: Agile-Book :: version_control

(book cover)

Order it now!

Welcome to the The Art of Agile Development website. Think of this as the "special features" DVD for the book, only without the DVD. (If you haven't bought the book yet, that's okay... we won't tell if you don't.) Here, you'll find a cornucopia of bonus material, such as downloadable posters, behind-the-scenes material, and new insights.

For more bonus material, see the table of contents. New entries are posted most Wednesdays.

(If there's nothing else on this page, this chapter has yet to be posted. Try the table of contents instead.)

 Print

The Art of Agile Development: Version Control

by James Shore

23 Jul, 2008

in 99 words

To support collective ownership, use a concurrent model of version control. Support time travel by storing tools, libraries, documentation, and everything else related to the project in version control. (On-site customers' files, too.) Keep the entire project in a single repository.

Avoid long-lived branches, particularly for customized versions; they'll cripple your ability to deliver on a timely schedule. Instead, use configuration files and build scripts to support multiple configurations.

Keep your repository clean: never check in broken code. All versions should build and pass all tests. "Iteration" versions are ready for stakeholders; "release" versions are production-ready.

Rant

Paranoia, Control, and $30,000 of Tooling

Inside the Book

  • Version Control
  • Sidebar: Version Control Terminology
  • Concurrent Editing
  • Time Travel
  • Whole Project
  • Customers and Version Control
  • Keep It Clean
  • Single Codebase
  • Appropriate Use of Branches
  • Questions
    • Which version control system should I use?
    • Should we really keep all our tools and libraries in version control?
    • How can we store our database in version control?
    • How much of our core platform should we include in version control?
    • With so many things in version control, how can I update quickly when I need to?
    • How should we integrate source code from other projects? We have read-only access to their repositories.
    • We sometimes share code with other teams and departments. Should we give them access to our repository?
  • Results
  • Contraindications
  • Alternatives
  • Further Reading


Loading...

Home :: Agile-Book | Comments (...)

Loading comments...