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

First, I'll explain what a `git bisect` session might look like in the abstract before running through it on the command line in detail.

## Scenario

Let’s say you have a set of 100 commits on a `master` branch:


> **Not All Commits Shown** <div></div>
To make the graphs legible, I have not shown all 100 commits in a line. Where items have been skipped, I've put a pointer indicating that they are being skipped or were skipped. For example, in the above diagram, 48 commits were skipped between A2 and A50, and 50 commits were skipped between A50 and A100.

You discover a previously-unseen bug at point `A100` and want to debug it. One way to do this is to read over the code, add logging, etc. This can be time-consuming, and there is a simpler way to gather information about what change caused the bug.

### The `git bisect` command

The `git bisect` command is a useful tool for finding out where a bug was introduced. If you know where a bug was introduced, you can look at the diff of the commit that caused it and work out what the source of the problem is.

### How does it works?

It works by picking a starting point where the bug definitely did not exist (the "good" point). In this case, you’ll choose point `A1`. Then you pick a point where the bug definitely did exist (the "bad" point). In this case, that’s `A100`.

First, I'll explain what a `git bisect` session might look like in the abstract before running through it on the command line in detail.

# Scenario

Let’s say you have a set of 100 commits on a `master` branch:


> **Not All Commits Shown** <div></div>
To make the graphs legible, I have not shown all 100 commits in a line. Where items have been skipped, I've put a pointer indicating that they are being skipped or were skipped. For example, in the above diagram, 48 commits were skipped between A2 and A50, and 50 commits were skipped between A50 and A100.

You discover a previously-unseen bug at point `A100` and want to debug it. One way to do this is to read over the code, add logging, etc. This can be time-consuming, and there is a simpler way to gather information about what change caused the bug.

## The `git bisect` command

The `git bisect` command is a useful tool for finding out where a bug was introduced. If you know where a bug was introduced, you can look at the diff of the commit that caused it and work out what the source of the problem is.

## How does it works?

It works by picking a starting point where the bug definitely did not exist (the "good" point). In this case, you’ll choose point `A1`. Then you pick a point where the bug definitely did exist (the "bad" point). In this case, that’s `A100`.

Learn about "bisection" concepts at a higher level.

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

Bisecting: The Session at a High Level

Scenario