What the change can help with root cause analysis

What is version control ?Version control is the management of changes to a document or set of documents over time so that you can recall specific versions later. Version control systems (VCS) are a category of software tools that help a software development team manage changes to source code over time. Version control software keeps track of every modification to the code in a special kind of database. If a mistake is made, developers can turn back the clock and compare earlier versions of the code to help fix the mistake while minimizing disruption to all team members.Why use version control ?While it is possible to develop software without using any version control, doing so subjects the project to a huge risk that no professional team would accept. It would be like not having backups. Version control enables developers to move faster and it allows software teams to preserve efficiency and agility as the team scales to include more developers. Specific benefits of using VCS include:A VCS maintains a complete long-term change history of every file. This makes it possible for developers to know exactly what was done and who did it at every step of the software development process.Ability to branch and merge. This enables developers on a team to work independently on different features, bugs or chores without the danger of messing up the whole project if any of their contributions introduce bugs into the code base. This makes collaboration on a project much easier.Traceability. Software made using a VCS is much easier to maintain and debug because we would always know what we did at any given point in time. Being able to trace each change made to the software and to annotate each change with a message describing the purpose and intent of the change can help with root cause analysis and other forensics.Examples of Version Control SystemsThere are two types of VCS i.e Centralised Version Control Systems (CVCS) and Distributed Version Control Systems (DVCS). A CVCS uses a central server to store all files and this constitutes a single point of failure. A DVCS is more robust because it relies on multiple client computers to store files and manage collaboration. Examples of VCS include GIT and Mercurial. In this tutorial we will focus on GIT which is an open source DVCS.Getting started – Creating a Github accountIf you don’t have a github account use the following link to sign up: https://github.com/Having a github account will enable you to create remote repositories to which you can push all your work. This acts as an important back up incase something happens to your computer and your files become corrupted or you lose them altogether.Getting started – Installing GitIf you don’t have Git on your computer you need to install it. The procedure you use will depend on your operating system. The official Git website has complete instructions on how to install Git on various systems including Windows, Mac and various flavours of Linux. You can access it through this link: https://git-scm.com/book/en/v2/Getting-Started-Installing-GitCommon Git commandsOnce you install Git on your computer, you can run Git commands on your terminal/command prompt. You first type the command then you press the enter/return key to execute the command. It’s important to set up some configuration information for your Git environment. Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates.The first thing you should do when you install Git is to set your user name and email address. You need to do this only once if you use the –global option, because then Git will always use that information for anything you do on that system.$ git config –global user.name “Firstname Lastname”$ git config –global user.email [email protected] can then configure the default text editor that will be used when Git needs you to type in a message. If not configured, Git uses your system’s default editor. If you want to use a different text editor, such as Emacs, you can do the following:$ git config –global core.editor emacsOn a Windows system, if you want to use a different text editor, you must specify the full path to its executable file. Note: It’s important to learn how to use the default editor in your system e.g Vim. If you want to check your configuration settings, you can use the $ git config –list command to list all the settings Git can find at that point:$ git config –list   user.name=Firstname Lastname   [email protected] you ever need help while using Git, there are two equivalent ways to get the comprehensive manual page (manpage) help for any of the Git commands:$ git help $ man git-For example, you can get the manpage help for the git config command by running:$ git help configYou typically obtain a Git repository in one of two ways:You can take a local directory that is currently not under version control, and turn it into a Git repository, orYou can clone an existing Git repository from elsewhere.In either case, you end up with a Git repository on your local machine, ready for work. In order to initialise a Git repository in an existing directory, you navigate to that directory using the command:$ cd path_to_directoryFor example on Mac:$ cd /Users/user/my_projectYou then type the command:$ git initThat creates a new subdirectory named .git that contains all of your necessary repository files. Note that once you create a local repository and you want to be able to push your work to a remote repository then you must link them. Sign in to your github account and create a new repository. Copy the url to your github repository and link it to your local repository as follows:$ git remote add origin On the other hand, you clone a repository with git clone . For example, if you want to clone the Git linkable library called libgit2, you can do so like this:$ git clone https://github.com/libgit2/libgit2That creates a directory named libgit2 and initializes a .git directory inside it. If you want to clone the repository into a directory named something other than libgit2, you can specify that as the next command-line option:$ git clone https://github.com/libgit2/libgit2 mylibgitThat command does the same thing as the previous one, but the target directory is called mylibgit. Note that each file in your working directory can be in one of two states: tracked or untracked. The main tool you use to determine which files are in which state is the git status command. If you run this command directly after a clone, you should see something like this:$ git statusOn branch masterYour branch is up-to-date with ‘origin/master’.nothing to commit, working directory cleanIf you already have any files and folders in your project folder (my_project folder in the above example), you can add them to Git using the git add filename command. You can also create new files and/or folders in your project directory and then add them to git as follows: $ git add my_file.pyGit will now track any changes you make to my_file.py as well as all other files and folders that you add to the staging area using the git add command. Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged?—?any files you have created or modified that you haven’t run git add on since you edited them?—?won’t go into this commit. To see what you’ve changed but not yet staged, type git diff with no other arguments. In order to commit all the staged changes in your working directory you run the git commit command:$ git commit -m “your commit message here”If you run git commit without the -m flag, Git will launch a text editor which enables you to enter a multiline commit message. This is set by your shell’s EDITOR environment variable?—?usually vim or emacs, although you can configure it with whatever you want using the git config –global core.editor command which I explained above. To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The git rm command does that, and also removes the file from your working directory so you don’t see it as an untracked file the next time around.$ git rm filenameThe next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the staging area already (with git add filename), you must force the removal with the -f option. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git.$ git rm -f filename Note: git rm filename and git rm -f filename deletes the file from your working directory.Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your .gitignore file (explained below) and accidentally staged it, like a large log file. To do this, use the –cached option:$ git rm –cached filenameThe above command does not delete the file from your directory. Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named .gitignore. Here is an example .gitignore file displayed on the terminal using the cat command:$ cat .gitignore# Byte-compiled / optimized / DLL files__pycache__/*.pycod# C extensions*.so# Distribution / packaging.Pythonenv/.envbuild/develop-eggs/dist/downloads/eggs/lib/Brief explanation:*.so tells Git not to track files that have the extension “.so” and env/ tells Git not to track any folder named “env” together with all its contents and so on. Lines starting with the “#” character are comments used to group related files in the ignored list. You create a .gitignore file in the root folder of your project. Note: GitHub maintains a fairly comprehensive list of good .gitignore file examples for dozens of projects and languages at https://github.com/github/gitignore if you want a starting point for your project.Before we look at branching and pushing your code to different remote branches, let’s first look at commit history. After you have created several commits, or if you have cloned a repository with an existing commit history, you’ll probably want to look back to see what has happened. The most basic and powerful tool to do this is the git log command.$ git logcommit 295b422b55d3d2bd7b5c2024d8e86d2327a52dda (HEAD -> development)Author: Firstname Lastname Date:   Wed Jan 17 10:19:44 2018 +0300 add myfile.pycommit 3c459a14bcafbd050afb03a26f13efb1e5b73c23Author: Firstname Lastname Date:   Wed Jan 17 10:18:43 2018 +0300 delete myfile.pyBy default, with no arguments, git log lists the commits made in that repository in reverse chronological order?—?that is, the most recent commits show up first. The git log command has got a lot of options that enable you to customise its output. Execute git help log to see all the available options. Another important command with regard to project history is the git reflog command.$ git reflog295b422 (HEAD -> development) [email protected]{0}: commit: change URL3c459a1 [email protected]{1}: commit: remove migrations631d8c9 [email protected]{2}: commit: add urlc47721c [email protected]{3}: commit: add development env13bd222 [email protected]{4}: commit: add runtime and procfileThe command takes various subcommands, and different options depending on the subcommand. Execute git help reflog to see all available options.