Enterprise DVCS Workflows are settling and patterns are consolidating. The flexibility git gives teams is so broad that even within a single company different teams might use different approaches to code sharing and collaboration. I speak from hard evidence as this is exactly what happens at Atlassian. The Stash team works differently than the Confluence team which works differently from the Jira team. They all share a similar Agile process but have different approaches to branching, Continuous Integration and team organization. Differences not withstanding, common patterns are emerging. A recurring paradigm in the industry is the use of a centralized repository with a master branch, several stable lines of development and follow a feature branch workflow where new features and bug fixes can be developed independently. This provides quick integration and allows teams to leverage the efficiency boost that comes with DVCS. If you read this and ponder a bit you might ask: if a company is following the centralized repository workflow listed above, why would they still need forks? There are several reasons why forking is useful and vital even within the enterprise. Before I present them let me first backtrack a bit and provide some context and definitions. Table of Contents What is a Fork? Forks have won the Open Source workflow choice award Do you need Forks in the Enterprise? Guard core components but encourage innovation and adoption Organize cross department collaboration Reduce noise Streamline interaction with contractors Developer to developer interactions behind the firewall Conclusions What is a Fork? In recent DVCS terminology a fork is a remote, server-side copy of a repository, distinct from the original. A clone is not a fork; a clone is a local copy of some remote repository. This differs slightly form the general definition of forks in software development but is the meaning that I will refer to in the course of this piece. Forks have won the Open Source workflow choice award If you have been living under a rock for the past several years let me reveal to you an indisputable fact: forks have won the Open Source process choice award. They foster participation by drastically lowering the barrier of entry and the friction of code collaboration. Anybody can fork an open project and the original author does not incur in penalties or burdens because of it, the operation is transparent. He will potentially receive feedback or improvements in the form of pull requests but that’s it. Do you need Forks in the Enterprise? A fully distributed de-centralized approach is effective for loosely connected open source teams but what about enterprise teams all working in the same office with a central repository? Are forks useful in this setting? Forks are surprisingly useful also behind the firewalls of the enterprise. In abstract terms forks can be used within an organization to manage trust, track the maturity of codebases and facilitate cross team collaboration. Concrete examples include: Guard core components but encourage innovation and adoption. Organize Cross department collaboration. Reduce [...]
Previous Topic
