In this module, you will get hands-on experience working with Git and its advanced concepts.

DevOps for Developers

Git is one of the most widely used version control tools, and is something that every developer should become comfortable with. In this module, you will get hands-on experience working with Git so that when it comes time to use it, you’ll be ready.

You’ll start by learning some of the more fundamental concepts such as initializing a Git repository, adding files to a repository, and how to commit changes. You’ll also learn how to clone a repository, and how to create branching.

You’ll then make your way to some more advanced concepts like Git stash, cherry-picking, working with multiple repositories, pushing code, and a lot more.

By the end of this module, you will have a proficient and working knowledge of Git which will serve you well throughout your career.

Git and GitHub

## What are branches?

In case you have not looked at a source control tool before, "branching" is a core concept.

### Repository with no branch

A series of changes to a repository might look like this:

> **Direction of arrows in Git diagrams**
<br>
The arrows in the above diagram point _backward_ in time. This is a convention standard in Git diagrams. It indicates that each commit depends on the previous commit back to the initial commit. In the above diagram, the last change `C`  depends on `B` which in turn is dependent on `A`.


The letters do not have a specific meaning here. They simply indicate multiple changes to lines that are grouped together.

Here, change `A` is made, then `B`, and then `C`. This might be informally called the _main line_. Most of the time, it’s called the “master” in Git.

### Adding branch to a repository

But let’s say someone wants to make an experimental change but does not want to affect the _main line_. They might _branch_ the code at point `C`:

# What are branches?

In case you have not looked at a source control tool before, "branching" is a core concept.

## Repository with no branch

A series of changes to a repository might look like this:

> **Direction of arrows in Git diagrams**
<br>
The arrows in the above diagram point _backward_ in time. This is a convention standard in Git diagrams. It indicates that each commit depends on the previous commit back to the initial commit. In the above diagram, the last change `C`  depends on `B` which in turn is dependent on `A`.


The letters do not have a specific meaning here. They simply indicate multiple changes to lines that are grouped together.

Here, change `A` is made, then `B`, and then `C`. This might be informally called the _main line_. Most of the time, it’s called the “master” in Git.

## Adding branch to a repository

But let’s say someone wants to make an experimental change but does not want to affect the _main line_. They might _branch_ the code at point `C`:

Become introduced to the concept of “branches” in Git.

Before We Begin

Introduction to Git

Git Basics

Clone a Repository

Git Branching

Merging

Git Stash

Git Add Interactive

Reflog

Cherry Picking

Git Rebase

Git Bisect

Fetching and Pulling Content

Working With Multiple Repositories

Pushing Code

Git Submodules

Pull Requests

Git Log

Squashing Commits

Bare Repositories

Cherry-Picking and Three-Way Merges

Git Hooks

Conclusion

Branches

What are branches?

Repository with no branch