Day8-90Days of DevOps Challenge /GIT & GitHub for DevOps

Day8-90Days of DevOps Challenge /GIT & GitHub for DevOps

What is Git?

Git is a distributed version control system for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files. Its goals include speed, data integrity, and support for distributed, non-linear workflows.

For example, you could be working on a website's landing page and discover that you do not like the navigation bar. But at the same time, you might not want to start altering its components because it might get worse.

With Git, you can create an identical copy of that file and play around with the navigation bar. Then, when you are satisfied with your changes, you can merge the copy to the original file.

What is GitHub?

GitHub is a web-based Git repository hosting service, which offers all of the distributed revision control and source code management (SCM) functionality of Git as well as adding its features.

GitHub lets you store your repo on their platform. Another awesome feature that comes with GitHub is the ability to collaborate with other developers from any location.

What is Version Control? How many types of version controls do we have?

Version Control Systems are process management systems that maintain changes recorded in a file or set of files over a period of time. Each change is maintained as a version. Users can track specific versions later. Version control systems do not require any other repository systems and can be cloned as per the need and availability. This is extremely helpful in case of failure and accidental deletions.

There are two main types of version control systems:

  1. Centralized version control systems
  2. Distributed version control systems.

Centralized version control systems:

Centralized version control systems contain just one repository globally and every user needs to commit to reflecting one’s changes in the repository. It is possible for others to see your changes by updating.

Two things are required to make your changes visible to others which are:

  • commit
  • update

Distributed Version Control Systems:

Distributed version control systems contain multiple repositories. Each user has their own repository and working copy. Just committing your changes will not give others access to your changes. This is because commit will reflect those changes in your local repository and you need to push them in order to make them visible on the central repository. Similarly, When you update, you do not get others’ changes unless you have first pulled those changes into your repository.

To make your changes visible to others, 4 things are required:

  • commit
  • push
  • pull
  • update


Why should we choose distributed over central version control?

  1. Better collaboration:In a DVCS, every developer has a full copy of the repository, including the entire history of all changes. This makes it easier for developers to work together, as they don't have to constantly communicate with a central server to commit their changes or to see the changes made by others.
  2. Improved speed:Because developers have a local copy of the repository, they can commit their changes and perform other version control actions faster, as they don't have to communicate with a central server.
  3. Greater flexibility:With a DVCS, developers can work offline and commit their changes later when they do have an internet connection. They can also choose to share their changes with only a subset of the team, rather than pushing all of their changes to a central server.
  4. Enhanced security:In a DVCS, the repository history is stored on multiple servers and computers, which makes it more resistant to data loss. If the central server in a CVCS goes down or the repository becomes corrupted, it can be difficult to recover the lost data.

Overall, the decentralized nature of a DVCS allows for greater collaboration, flexibility, and security, making it a popular choice for many teams.

Task1:Install GIT

  • Open your Linux terminal.
  • Depending on your distribution, you can use a package manager to install Git. For example, on Ubuntu-based systems:

 sudo apt-get update         
sudo apt-get install git        

  • Verify the installation by typing git --version.

Create a GitHub Account:

  • Open your web browser and go to github.com
  • Click on the "Sign up" button.
  • Provide the required information, such as username, email, and password.
  • Complete any necessary verification steps.

By following these steps on your Linux system, you'll have Git installed, and a GitHub account created.

Exercise 1: Create a New Repository on GitHub

  • Log in to your GitHub account.
  • Click on the '+' icon in the top-right corner and select "New repository."


  • Fill in the repository name, a description (optional), and other settings.
  • Choose between making the repository public or private.
  • You can choose to initialize the repository with a README, which is recommended for starting projects.
  • Click on the "Create repository" button.


Exercise 2: Clone the Repository to Your Local Machine

On the repository page, click the green "Code" button.

  • You can either choose to clone with HTTPS or SSH. Choose the one that suits your preference. Click the clipboard icon to copy the URL.


  • Open your terminal on your local system.
  • Navigate to the directory using cd command where you want to clone the repository
  • Use the git clone command followed by the repository URL to clone the repository.

 git clone <paste_the_copied_url>        

Press Enter to execute the command.

  • If the repository is private, GitHub might ask for a username and password.
  • Once the repository is cloned, you will have a copy of the GitHub repository on your local system.

Exercise 3: Make Changes, Commit, and Push

Now that you have the repository cloned locally, you can make changes to the files and commit them to track the modifications. Follow these steps:

  • Create a file in your repository you cloned before through the text editor.
  • Use the git status command to see which file is added and left unstaged.

  • Use the git add <your_file_name> command to stage the file you created for further actions.

  • Use the git commit -m "<commit_message>" command to commit the staged file. The file will be tracked after the commit.

  • Finally, use the git push command to push the committed changes back to the repository on GitHub. For example: git push origin main or git push origin master, depending on the branch name.

  • Completed Day 8 of the #90DaysOfDevOps challenge. Today, you learned the basics of Git and GitHub, including creating a new repository, cloning it to your local machine, making changes, committing them, and pushing them back to GitHub. These fundamental exercises are essential for version control and collaborative software development.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了