How did collaboration work before VCS?

In earlier days, when there was no concept of version control systems, people used different ways to collaborate, like using folders, email, pen drives, etc, to collaborate on a particular project (or code).
They used to maintain versions of files like ‘first.cpp’, ‘first_update_v1.cpp’, ‘first_update_v2.cpp’, like this, but all these led to redundancy, increased complexity, and loss of collaboration history.

The Pendrive Analogy in Software Development

In the above way, collaboration existed if and only if the collaborators used a common/shared resource to collaborate. What if the users reside in different geographical locations, and what if they can't share a common resource? This problem was resolved by using email and pen drives, where users can share files/codes with each other and collaborate. But still, the fundamental issue was that there was no track of who edited what and on which part of the file the changes occurred.
Let’s take a real-life scenario in a company where the junior developer sends his code to a senior developer, the senior developer makes some changes and sends a copy back to the junior developer, and the junior developer has a new version. Suppose the senior dev does some bug fixing, but the pen drive is with the junior dev, and he doesn’t know what changes the senior dev made.

Why Version Control Exists

To resolve the above problem, a version control system that kept track of all the changes made to a particular file was introduced. This system is called git. Git is responsible for keeping track of any changes that occur in files. Whereas GitHub is a remote version control system hosted on the cloud (Git is the backbone of GitHub), a few more remote VCS include GitTea, GitLab, Bitbucket, AWS CodeCommit, etc.
In Git, a single program is available, which is the single point of truth for any changes that occurred in the file.