A single repository?
A single Git repository for all technical documentation content maximizes reuse, consistency, and quality while simplifying collaboration across writing and dev teams.
Definition
Section titled “Definition”Ideally, all content should be placed in a single RepositoryThe place where a documentation team keeps its sources: shared folders, a CMS database, or a version-control system such as Git, which also stores the complete history of every file.View in glossary →, such as Git Version controlRecording every change to a set of files so that any earlier state can be restored, changes can be compared, and several people can work in parallel. Git is the most widely used version-control system; docs-as-code keeps documentation under version control next to the product code.View in glossary → software. This maximizes reuse, consistency, and quality. If the content is in DITA XML or DocBookA semantic XML markup language for technical documentation, organized in books, chapters, and sections rather than typed topics. It predates DITA XML and is the usual point of comparison when choosing a structured format.View in glossary → format, for example, the Single-sourcingGenerating multiple deliverables (PDF, HTML, help formats) from one source, rather than maintaining a separate source per output format.View in glossary → capabilities of these formats can be fully exploited to publish the content in the appropriate form.
Content becomes a network of information modules, and the relationships within this network need to be managed, particularly during updates.
Single Repository
Trade-offs
Section titled “Trade-offs”In practice, it appears that very few companies have taken this step. It is true that until structured formats are taught in secondary education, it seems unrealistic to expect all team members within a company to adopt them, especially if employee turnover is high. A CMS can help bridge the gap, but its reliability must be carefully evaluated.
Additional resources