# Basic Git & GitHub for DevOps Engineers

## What is Git?

Git (Global Information Tracker) is a version control system that allows you to track changes to files and coordinate work on those files among multiple people. It is commonly used for software development, but it can be used to track changes to any set of files.

With Git, you can keep a record of who made changes to what part of a file, and you can revert back to earlier versions of the file if needed. Git also makes it easy to collaborate with others, as you can share changes and merge the changes made by different people into a single version of a file.

## What is GitHub?

GitHub is a web-based platform that provides hosting for version control using Git. It is a subsidiary of Microsoft, and it offers all of the distributed version control and source code management (SCM) functionality of Git as well as adding its own features. GitHub is a very popular platform for developers to share and collaborate on projects, and it is also used for hosting open-source projects.

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

Version control is a system that tracks changes to a file or set of files over time so that you can recall specific versions later. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more.

There are two main types of version control systems: centralized version control systems and distributed version control systems.

1. A centralized version control system (CVCS) uses a central server to store all the versions of a project's files. Developers "check out" files from the central server, make changes, and then "check-in" the updated files. Examples of CVCS include Subversion and Perforce.
    
    ![Centralized vs Distributed Version Control Systems | by Mateusz Lubański |  FAUN — Developer Community 🐾](https://miro.medium.com/v2/resize:fit:1400/1*GgaGcwh5L246YcU5NVDA5A.png align="left")
    
2. A distributed version control system (DVCS) allows developers to "clone" an entire repository, including the entire version history of the project. This means that they have a complete local copy of the repository, including all branches and past versions. Developers can work independently and then later merge their changes back into the main repository. Examples of DVCS include Git, Mercurial, and Darcs.
    
    ![What Is Git | Explore A Distributed Version Control Tool ...](https://www.edureka.co/blog/wp-content/uploads/2016/11/Distributed-Version-Control-System-Workflow-What-Is-Git-Edureka.png align="left")
    
    ## Why do we use distributed version control over centralized 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.
        

## **📝 Local vs. Remote Repositories:**

**Local Repositories:**

* 🏠 Reside on your computer.
    
* 📂 Have working copies of your project files.
    
* 🛠️ You make changes, stage, commit locally.
    
* 🧑‍💻 Mainly for your personal work.
    
* 📦 Can be created new or cloned from a remote repository.
    

**Remote Repositories:**

* ☁️ Hosted on a server accessible to all team members.
    
* 📁 Only contain the ".git" repository folder, no working files.
    
* 🚀 Used for sharing code with your team.
    
* 🔄 Changes from local repo are uploaded here to share.
    

🔗 **Connecting Local to Remote:**

1. 🌐 Create a remote repository on a hosting platform (e.g., GitHub).
    
2. 📎 Get the remote repository's URL.
    
3. ⌨️ Use `git remote add` to link your local repo to the remote:
    
    ```plaintext
    git remote add origin <remote_repo_url>
    ```
    
4. 📤 Push your local changes to the remote using `git push`:
    
    ```plaintext
    git push -u origin master
    ```
    

## Exercises:

**Creating and Cloning the Repository:**

1. Open your terminal (Terminal, Git Bash, etc.).
    
2. Navigate to the directory where you want to create the repository on your local machine.
    
3. Initialize a new Git repository:
    
    ```plaintext
    git init
    ```
    
4. Create a new repository on GitHub. You can do this by going to GitHub and clicking on the "+" button in the top right corner, then selecting "New Repository."
    
5. Follow the prompts to set up your repository's name, description, visibility (public/private), and other settings.
    
6. Once the repository is created on GitHub, you'll see the repository's URL. Copy it.
    
7. Connect your local repository to the remote repository on GitHub by adding the remote URL:
    
    ```plaintext
    git remote add origin <repository_url>
    ```
    
8. Clone the remote repository to your local machine:
    
    ```plaintext
    git clone <repository_url>
    ```
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1691853199507/520a0c1d-2406-43e7-92ea-c507a94ed6b1.png align="center")

**Making Changes and Committing:**

1. Navigate into the cloned repository's directory:
    
    ```plaintext
    cd <repository_name>
    ```
    
2. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1691853478903/a82c4ba5-5b3f-4844-8d46-832597876355.png align="center")
    
    Open the file you want to modify using your preferred text editor.
    
3. Make your changes to the file. Save the changes.
    
4. Stage the changes to be committed:
    
    ```plaintext
    git add .
    ```
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1691853870929/9dff98a5-e9ed-4e2e-8853-691c0b7596e4.png align="center")
    
5. Commit the changes with a meaningful message:
    
    ```plaintext
    git commit -m "Updated the file with my changes"
    ```
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1691853994863/8fa15d08-8501-443a-ab38-a2fadbdc080a.png align="center")

**Pushing Changes to GitHub:**

1. Push the committed changes to the remote repository on GitHub:
    
    ```plaintext
    git push origin master
    ```
    
2. You might need to provide your GitHub credentials for authentication.
    

And there you have it! You've successfully created a new repository on GitHub, cloned it to your local machine, made changes, committed them, and pushed the changes back to GitHub. 🎉

Remember to replace `<repository_url>` with the actual URL of your GitHub repository, and `<repository_name>` with the name of your repository.

Git is your time-traveling code buddy, and GitHub is your code's online home. Together, they make DevOps feel like a breeze. Start with the basics, have fun collaborating, and soon you'll be a DevOps superhero! 🦸‍♂️🦸‍♀️

Remember, practice makes perfect. So grab your keyboard and start your DevOps adventure! 🚀👨‍💻👩‍💻