Exploring Git Basics: The Power of Distributed Version Control Systems (DVCS)

Version Control Systems

Version Control Systems (VCS) are a category of software tools that help software developers to work together and maintain a complete history of their work. Version control systems keep track of every modification to the code. 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.

Listed below are the functions of a VCS:

  • Allows developers to work simultaneously
  • Does not allow overwriting each other’s changes
  • Maintains a history of every version.

What is GIT

By far, the most widely used modern version control systems in the world today is Git. Git is a free and open source distributed version control systems designed to handle everything from small to very large projects with speed and efficiency.

Advantages of GIT

  • Distributed:
    Distributed VCS clients not only check out the latest snapshot of the directory but they also fully mirror the repository. If the server goes down, then the repository from any client can be copied back to the server to restore it. Every checkout is a full backup of the repository.
  • Open Source:
    It is available freely over the internet. You can use Git to manage property projects without paying a single penny.
  • Fast and small:
    As most of the operations are performed locally, it gives a huge benefit in terms of speed. Git does not rely on the central server; that is why, there is no need to interact with the remote server for every operation. Interaction with the server is required only to publish your changes and take the latest changes.
  • Data Assurance/Security:
    The content of the files as well as the true relationships between files and directories, versions, tags and commits, all of these objects in the Git repository are secured with a cryptographically secure hashing algorithm called SHA1. This protects the code and the change history against both accidental and malicious change and ensures that the history is fully traceable.
  • Branching and Merging:
    Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds.

GIT Workflow

Your local repository consists of three trees maintained by GIT:

  • Working Directory which holds the actual files
  • the Index which acts as a staging area
  • the HEAD which points to the last commit you’ve made.

The basic workflow of GIT:

  1. You modify a file from the working directory
  2. You add these files to the staging area
  3. You perform commit operation that moves the fies from the staging area. After push operation, it stores the changes permanently to the Git repository.
Image Reference: Git Tutorial

How to explicitly ignore files?

Git sees every file in your working copy as one of three things:

  1. tracked – a file which has been previously staged or committed;
  2. untracked – a file which has not been staged or committed; or
  3. ignored – a file which Git has been explicitly told to ignore.

Ignored files are usually build artifacts and machine-generated files that can be derived from your repository source or should otherwise not be committed. Some common examples are:

  • dependency caches, such as the contents of /node_modulesor /packages
  • compiled code, such as .o, .pyc, and .class files
  • build output directories, such as /bin, /out, or /target
  • files generated at runtime, such as .log, .lock, or .tmp
  • hidden system files, such as .DS_Store or Thumbs.db
  • personal IDE config files, such as .idea/workspace.xml

Ignored files are tracked in a special file named .gitignore that is checked in at the root of your repository. There is no explicit git ignore command, instead the .gitignore file must be edited and committed by hand when you have new files that you wish to ignore. .gitignore files contain patterns that are matched against file names in your repository to determine whether or not they should be ignored.

Note: If you don’t already have a .gitignore, you can make one right inside the root directory of the project: project/.gitignore.

Setting up repository on a local machine

  1. Navigate to the folder on a remote machine. This folder should be the one where you want the central repository for the project
  2. Create a bare repository: Initialize the directory to be a git repository using command git –bare init.
    It initializes the repository without a working directory.

Note: This directory cannot have any project files directly (by copying and pasting files into it). Also, you cannot clone this repository as it doesn’t have any files. Files need to be pushed from any of the local repositories to the bare repository, and then only it can be cloned.

  1. Navigate to the folder on a local machine. This folder should be the one where you want the local repository for the project.
  2. Initialize the directory to be a git repository using command git init.
  3. Copy and Paste all the project files to this directory.
    Note: Follow steps 2 and 3 if you are making a local repository to add files to the remote repository.
    If you want to make a clone of already existing remote repository, use the following command: git clone <path/to/repository>
  4. Add all the files to staging area using command git add *.
    Note: If you want to push only one file to the remote repository, you can add only that file to staging area using command git add fileName.extension.
  5. You can use command git status to check files in staging area and untracked files.
  6. Commit changes to the head of local repository (or local master branch) using command git commit –m “Commit Message”.
  7. Command git log can be used to check number of commits and commit details.
  8. Your changes are now in the HEAD of your local working copy. To send those changes to the remote repository, execute git push origin master.
    Note: Use the above command only if you have cloned an existing repository. If you have not cloned an existing repository and want to connect to a remote repository, you need to add it with git remote add origin <path/to/repository>.
    After setting the path of origin you can use git push origin master command to push your changes or files to the remote repository.
  9. If more than one person tries to push changes in same files and on the same line, it will show conflict.
    You are responsible to merge those conflicts manually by editing the files shown by git.
    After changing files, you need to push them again to the remote repository by executing add, commit and push commands.
  10. If a number of people are working on the same project, it’s a good practice to pull latest changes from the origin (or remote repository) and merge it with your local repository to avoid conflicts later on, before pushing your changes to the origin.
    Use command git pull origin master for fetching latest changes from origin.

Git Branching & Merging

Branches are used to develop features isolated from each other. The master branch is the “default” branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion.

Image Reference: Building Quality Into Drupal Development Workflow

Steps for creating and using multiple branches in a single repository

  1. Navigate to the local repository for which you want to create a branch.
  2. Create a local branch on your local repository using the command git checkout –b new_feature
    Note: If you want to see branches on your local repo, use command git branch
    In the output, notice the * is now over the new_feature branch.
  3. Push that branch to the remote using command git push origin new_feature
    A new branch will be created on the remote repo (new_feature).
    Note: If you want to check branches on remote repo, use command git branch -r
    Set the upstream branch to track (for binding both the branches)
    git branch –set-upstream new_feature origin/new_feature
    Now you can both push to/pull from the remote branch
  4. Merging new branch to the master branch
    git merge new_feature
  5. If you need to delete the remote branch
    git push origin :new_feature

Steps for cloning already existing branch from the remote repository

  1. Navigate to the folder on local machine. This folder should be the one where you want the local repository for the project.
  2. Clone the remote repository branch using command
    git clone -b new_feature <path/to/repository>.
  3. For pushing files to the remote branch, use the command git push

What is GitHub?

GitHub is a web-based hosting service for software development projects that uses the Git revision control system. It also has their standard GUI application available for download (Windows, Mac, GNU/ Linux) directly from the service’s website.

Link for creating account: https://github.com/

Popular Git GUI Clients: GUI Clients

Share your love
Aliasger Rangoonwala
Aliasger Rangoonwala
Articles: 4