What is Version Control?
Imagine you and your team are working on a project. Think of how many ways a project changes from one iteration to the next: From self-imposed changes to requests from other departments to managerial editing there is never really just one version of a project.
Those not using version control probably already have a solution for this: Perhaps dated subdirectories, or renaming files to include the initials of the person who last updated the project. After all, consider why nearly all programs contain not just a Save but a Save as feature. Software is made knowing that projects change with time.
What version control provides is a better way. By using a centralized server, or repository, version control programs keep copies of each version of a project ready to fall back to, if necessary. Originally, version control systems featured the primary server, or host, that contained all versions of the project while letting users, or more specifically their client computers, copy over the version from which they need to work. Currently, most version control systems, such as Git, use a distributed approach:
Distributed version control means that, while the host still maintains the master copy of all versions of a project, when clients copy the project all of the project and all past versions are also pulled. This allows for additional backup versions that can be used to rebuild should the primary server fail.
One of the most commonly-used version control options today is Git, which allows for traditional version control, as well as non-linear options using Git’s branching feature. Branching lets users make their copy of a project diverge from the “origin” or “master” version of the project to try out experimental ideas, or so multiple people can develop their versions of a project concurrently. Branched projects can be pulled back into the original project and merged, or kept as separate work, and can be segmented into developing, staging, and production branches, so your version control can behave like your developing (or working) environment.
Git also has it is own built-in staging areas, so initial saves into the project are not “committed” to the project or branch. You can change multiple files, and make multiple changes, then review and commit only the changes you deem necessary. Moreover, all of this is included in what is a comparatively small, fast and local application.
Git in and of itself is a vast topic, and this blog post only covers a small magnitude of the power of Git and version control. Check back next week for a look at using Git with GitHub. Can’t wait until then? Check out Linux Academy’s Git and Gitlab course.