Learn Python

# Version Control

#Basic#Version Control

We have been coding for quite some time, mostly on our own at our own machines. However, it's common to work with colleagues on the same project when we join the workforce in future. To facilitate the managing of file edits, we usually use some version control systems.

A version control system serves the following purposes, among others.

  • Version control enables multiple people to simultaneously work on a single project. Each person edits his or her own copy of the files and chooses when to share those changes with the rest of the team. Thus, temporary or partial edits by one person do not interfere with another person's work. Version control also enables one person you to use multiple computers to work on a project, so it is valuable even if you are working by yourself.

  • Version control integrates work done simultaneously by different team members. In most cases, edits to different files or even the same file can be combined without losing any work. In rare cases, when two people make conflicting edits to the same line of a file, then the version control system requests human assistance in deciding what to do.

  • Version control gives access to historical versions of your project. This is insurance against computer crashes or data lossage. If you make a mistake, you can roll back to a previous version. You can reproduce and understand a bug report on a past version of your software. You can also undo specific edits without losing all the work that was done in the meanwhile. For any part of a file, you can determine when, why, and by whom it was ever edited.

References:

# Two types of version control systems

# Centralized Version Control System

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

Subversion (or SVN) is a well-known centralized version control system.

# Distributed Version Control System

Distributed version control systems do not necessarily rely on a central server to store all the versions of a project’s files. Instead, every developer “clones” a copy of a repository and has the full history of the project on their own hard drive. This copy (or “clone”) has all of the metadata of the original.

Git (opens new window) is a well-known distributed version control system.

# A Typical Workflow

In order to have Git working properly, we need to define the author name and email.

git config --global user.name "<name>"
git config --global user.email "<email>"
1
2
  1. When we start working on a new project, create empty Git repo in the current directory.
git init .
1
  1. List which files are staged, unstaged, or untracked.
git status
1
  1. To access the history, we display the commit history.
git log
1
  1. When we are ready to put some edits in history, we stage the changes.
git add .
1

or

git add <some-file>
1
  1. Commit the staged snapshot and use <message> as the commit message.
git commit -m "<message>"
1

If we use GitHub (opens new window) for our remote repository, we set it up by adding a remote url.

git remote add <name> <url>
1

where <name> is an arbitrary label for the remote sever, and <url> is the address of that remote server.

And we can push to the remote for the first time

git push -u <name> <branch_name>
1

Later on, we can simply

git push
1

VS Code has a Source Control (opens new window) tab to work with Git using a simple GUI. We will demo it in class.

GitLens (opens new window) and Version Lens (opens new window) are two handy extensions we can install to work with Git.

# Version Control Best Practices

  • Use a descriptive commit message
  • Make each commit a logical unit
  • Avoid indiscriminate commits
  • Incorporate others' changes frequently
  • Share your changes frequently
  • Coordinate with your co-workers
  • Remember that the tools are line-based
  • Don't commit generated files

← A Tiny Challenge →