Day 8 Task: Basic Git & GitHub for DevOps Engineers.

What is Git?

Git is the most commonly used version control system. Git tracks the changes you make to files, so you have a record of what has been done, and you can revert to specific versions should you ever need to. Git also makes collaboration easier, allowing changes by multiple people to all be merged into one source.

So regardless of whether you write code that only you will see, or work as part of a team, Git will be useful for you.

Git is software that runs locally. Your files and their history are stored on your computer. You can also use online hosts (such as GitHub or Bitbucket) to store a copy of the files and their revision history. Having a centrally located place where you can upload your changes and download changes from others, enable you to collaborate more easily with other developers. Git can automatically merge the changes, so two people can even work on different parts of the same file and later merge those changes without losing each other’s work!

What Is Version Control?

Version control helps developers track and manage changes to a software project’s code. As a software project grows, version control becomes essential. Take WordPress…

At this point, WordPress is a pretty big project. If a core developer wanted to work on one specific part of the WordPress codebase, it wouldn’t be safe or efficient to have them directly edit the “official” source code.

Instead, version control lets developers safely work through branching and merging.

With branching, a developer duplicates part of the source code (called the repository). The developer can then safely make changes to that part of the code without affecting the rest of the project.

Then, once the developer gets his or her part of the code working properly, he or she can merge that code back into the main source code to make it official.

All of these changes are then tracked and can be reverted if need be.

Types of VCS

Git is not the only VCS in use. Moreover, Git is just a kind of VCS.

The types of VCS are:

• Local Version Control System

• Centralized Version Control System

• Distributed Version Control System

Local Version Control System

A local version control system is a local database located on your local computer, in which every file change is stored as a patch. Every patch set contains only the changes made to the file since its last version. In order to see what the file looked like at any given moment, it is necessary to add up all the relevant patches to the file in order until that given moment.

The main problem with this is that everything is stored locally. If anything were to happen to the local database, all the patches would be lost. If anything were to happen to a single version, all the changes made after that version would be lost.

Also, collaborating with other developers or a team is very hard or nearly impossible.

Centralized Version Control System

A centralized version control system has a single server that contains all the file versions. This enables multiple clients to simultaneously access files on the server, pull them to their local computer or push them onto the server from their local computer. This way, everyone usually knows what everyone else on the project is doing. Administrators have control over who can do what.

This allows for easy collaboration with other developers or a team.

The biggest issue with this structure is that everything is stored on the centralized server. If something were to happen to that server, nobody can save their versioned changes, pull files or collaborate at all. Similar to Local Version Control, if the central database became corrupted, and backups haven't been kept, you lose the entire history of the project except whatever single snapshots people happen to have on their local machines.

The most well-known examples of centralized version control systems are Microsoft Team Foundation Server (TFS) and SVN.

Distributed Version Control System 

With distributed version control systems, clients don’t just check out the latest snapshot of the files from the server, they fully mirror the repository, including its full history. Thus, everyone collaborating on a project owns a local copy of the whole project, i.e. owns their own local database with their own complete history. With this model, if the server becomes unavailable or dies, any of the client repositories can send a copy of the project's version to any other client or back onto the server when it becomes available. It is enough that one client contains a correct copy which can then easily be further distributed.

Git is the most well-known example of distributed version control systems.

Difference between Centralized Version Control and Distributed Version Control

What Is GitHub?

GitHub is a for-profit company that offers a cloud-based Git repository hosting service. Essentially, it makes it a lot easier for individuals and teams to use Git for version control and collaboration.

GitHub’s interface is user-friendly enough so even novice coders can take advantage of Git. Without GitHub, using Git generally requires a bit more technical savvy and use of the command line.

GitHub is so user-friendly, though, that some people even use GitHub to manage other types of projects – like writing books.

Additionally, anyone can sign up and host a public code repository for free, which makes GitHub especially popular with open-source projects.

As a company, GitHub makes money by selling hosted private code repositories, as well as other business-focused plans that make it easier for organizations to manage team members and security. We utilize Github extensively at Kinsta to manage and develop internal projects.

Importance of Git

Git is a speedy and efficient distributed VCS tool that can handle projects of any size, from small to very large ones. Git provides cheap local branching, convenient staging areas, and multiple workflows. It is free, open-source software that lowers the cost because developers can use Git without paying money. It provides support for non-linear development. Git enables multiple developers or teams to work separately without having an impact on the work of others.

What is the difference between the master and main branches?

The difference between the "main" branch and the "master" branch typically lies in the context of version control systems like Git. Prior to 2020, the term "master" was commonly used as the default branch name in many version control systems, including Git. However, in recent years, there has been a movement in the tech industry to replace the term "master" with more inclusive and neutral terminology.

As a result, many organizations and communities have transitioned from using "master" to using alternative branch names like "main" or "default" to refer to the primary branch in a repository. The motivation behind this change is to avoid any potential association with historical or ongoing racial connotations that the term "master" may carry.

In terms of functionality, both "main" and "master" branches serve similar purposes as the default branch in a repository. They typically represent the latest stable version of the codebase and act as the base branch for creating and merging feature branches or other development branches. The main difference is in the naming convention and the underlying message of inclusivity and respect that the use of "main" represents.

It's worth noting that the choice of branch name is not enforced by the version control system itself, and it's up to the developers and organizations to decide which naming convention to adopt. Therefore, you may still encounter repositories that use "master" as the default branch, especially if they were created before the transition to alternative branch names took place.

Difference between Git and Github?

 How do you create a new repository on GitHub?

To create a new repository on GitHub, follow these steps:

1. Sign in to your GitHub account or create a new account if you don't have one.

2. Once you're signed in, you'll be directed to your GitHub dashboard. On the right side of the page, you'll find a green button labeled "New repository." Click on it.

3. On the "Create a new repository" page, you'll need to provide some information about your repository:

   • Repository name: Choose a descriptive name for your repository.

   • Description (optional): Provide a brief description to explain what your repository is about.

   • Public or Private: Choose whether you want your repository to be public (visible to everyone) or private (visible only to you and collaborators you specify).

   • Initialize this repository with a README: If you check this option, GitHub will create an initial README file for your repository. It's generally recommended to check this option to provide some basic information about your project.

4. Once you've filled in the necessary details, click on the "Create repository" button.

5. Congratulations! You have successfully created a new repository on GitHub. The next page will provide you with some instructions on how to get started with your repository, including commands to clone the repository to your local machine, add files, and make commits.

Remember, after creating the repository, you can further customize it, add collaborators, configure branch protections, and manage various settings according to your requirements using the GitHub web interface.

What is the difference between local & remote repositories? How to connect local to remote?

A local repository and a remote repository are two distinct entities in the context of version control systems like Git. Here's an overview of their differences and how to connect them:

Local Repository: A local repository resides on your computer and contains the entire history and files of a project. It is stored in a directory on your local machine and allows you to make changes, track revisions, and manage the project's version control locally. You can perform various operations such as creating branches, making commits, merging changes, and more within the local repository.

Remote Repository: A remote repository is hosted on a remote server, typically on a platform like GitHub, GitLab, or Bitbucket. It acts as a centralized location where developers can collaborate, share their code, and synchronize their work. Remote repositories provide a way for multiple developers to work on the same project, making it easier to track changes, review code, and ensure everyone is working with the latest version of the codebase. Remote repositories also offer additional features like issue tracking, pull requests, and more, depending on the platform.

Connecting Local to Remote Repository: To connect your local repository to a remote repository, you generally follow these steps:

Create a remote repository on the hosting platform (e.g., GitHub).

Obtain the URL of the remote repository. It usually looks like: https://github.com/username/repository.git (replace username with your GitHub username and repository with the name of your repository).

In your local repository, open a terminal or command prompt and navigate to the repository's directory.

Run the following command to add a remote connection:

git remote add origin <remote_repository_url> Replace <remote_repository_url> with the URL of your remote repository.

Verify the remote connection by running:

git remote -v

This will list the configured remotes, and you should see the origin URL you added.

Push your local repository to the remote repository using:

git push -u origin <branch_name> Replace <branch_name> with the branch you want to push (e.g., main or master).

Once you've established the connection, you can use Git commands like git push to send your local changes to the remote repository and git pull to fetch and merge changes from the remote repository into your local repository.