What are the biggest challenges to distributed software collaboration?

We’re going to jump right in by discussing the challenges software developers face when they need to work together on a code base.

In the early days of computing, it was common for a single developer to plan, write and test an entire project on their own.

Although working on a project with team members offers many advantages. A diverse team can bring together many specialties, backgrounds and points of view to develop a successful project which a single person could never hope to achieve. However, by allowing many contributors to all work simultaneously on the same project we also introduce several challenges and difficulties.

The first time that a group of software engineers decided to work on a project together they discovered the range of challenges that we face when working on software collaboratively.

To overcome these issues, Version Control software was developed. There are many examples of version control software, such as Apache Subversion and Mercurial. This Blog focusses on one of the most powerful and widespread tools, Git.

Any software development project benefits from having a Version Control System in place to manage the files associated with the project. Although there are a variety of version control systems available, Git is by far the most popular. A 2018 survey by “StackOverflow” found that almost 90% of all professional software developers use Git as their version control system of choice, while less than 4% confessed to not using a version control system at all.

Git is simply a program like any other you might install on your computer. It can be installed on Linux, macOS or Windows and can be used by issuing commands through a terminal, a dedicated GUI or by using an IDE which has the Git commands integrated into it.

·        Git can provide an extremely detailed history of every change made to all the project’s files. This allows us to review changes, visualize the history using a graph view or revert our work to an earlier state.

·        Git can facilitate distributed collaborative working. A range of options permits multiple developers to simultaneously work on the same project without impeding each other’s progress. Git can help us deal with the conflicts that might arise when we are working on the same set of files.

Imagine you have joined a new team and you have been supplied with a current copy of the codebase. You will need to orientate yourself with the state of the project. This is part of the “onboarding” process that is common for software developers joining a new team. One of the ways which Git can facilitate onboarding is by helping you understand the project and its history.

A key tool to achieve this is the Git graph view.

There are several ways in which we can organize ourselves when we use Git in a project. We will briefly introduce several common arrangements developers use when they work with Git.

·        On small projects, there may be a lone developer who uses a remote repository as a backup or way of accessing the codebase from various locations.

·        On larger projects, such as many open-source projects, contributors make remote copies of the entire remote repository (a process known as “forking”). This provides the contributor with their own remote repository which they have full control over. When they have made changes to their own remote repository, they may make a request to have those changes integrated into the original repository.

Most workflows are described informally, using the authors’ preferred terms. This makes understanding and comparison of workflows difficult. The Git Workflows identified the 6 different lines of development commonly seen in software development projects.

Main

Description: This branch contains all the changes associated with the last stable release. It is a high-quality version of the code that is the primary source for people working on the code base.

Lifetime: Typically infinite lifetime. One per code base.

Common branch names: Master, Trunk, Baseline

Integration

Description: A line of development where changes that are not yet ready to be released are integrated, in order to understand how they all work together.

Lifetime: Either a single infinite line, or shorter-lived lines that are created as needed.

Common branch names: Develop, Development, dev

Change

Description: A line of development containing work associated with the development of a new feature.

Lifetime: Usually multiple such lines, created on demand.

Common branch names: Feature, Topic, Epic

Release

Description: Isolates all changes for a particular version in preparation for its launch.

Lifetime: May be infinite (in which case there is just one per code base) or shorter lived, with one line per major release. Not all commits on these lines of development are released. Tagged commits on these lines of development mark the commits which are actually released.

Common branch names: Production, Latest, Release

Validation

Description: Line of development for work associated with code review, testing, verification and approval of development work not necessarily ready for deployment.

Lifetime: May be a single infinite line, or multiple lines. May be created for specific Quality Assurance tasks.

Common branch names: QA, Candidate, Pre-production, Staging

Fix

Description: This line of development is used to correct bugs and other emergency fixes.

Lifetime: Typically multiple instances per code base, created as needed. Often (though not always) deleted after integration.

Common branch names: HotFix, BugFix

Finally, If you're interested in how to record code changes, work separately or synchronously with a team and integrate the work of an entire team, Git will be your assistant.