Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Learn Git

In the last lesson, we learned how to _format_ the git log output; in this lesson we will learn how to _filter_ down to a specific set of commits. By default, `git log` shows every commit in a repo. We will walk through using a bunch of options to filter our git log commits to a more meaningful set (`-n`, `--after`, `--before`, `--author`, `--grep`, `-S`, `-G`, `--no-merges`, `{ref}..{ref}`, `{files}`). We will also show how all of the formatting and filtering options can be composed together to query exactly what you are looking for in your commit history.

Practical Git: Filter commit history with git log arguments

When you find a bug in an open source project, you know exactly the change you want to make. Other times you just want to find a way to contribute. Either way, you’ll need to know how the project maintainers want to run the project and work with them to come up with an implementation for the fix/feature. And if you don't even know what project to start contributing to, check out [this blogpost](https://medium.com/@kentcdodds/what-open-source-project-should-i-contribute-to-7d50ecfe1cb4) for inspiration on how to identify a good project to contribute to.

Identifying How to Contribute to an Open Source Project on GitHub

You cannot push code to repositories that you don’t own or have sufficient permission to. So instead, you make your own copy of the repository by “forking” it. You are then free to make any changes you wish to your repository.

How to Fork and Clone a GitHub Repository

Before you start making your changes, you often need to set up your environment for the changes. This is where the repositories' contributing instructions come in really handy. In this lesson we’ll get our environment set up and ready for changes.

Setting up the project locally

Often when making a change, you want to verify your approach with the maintainer or ask them for help. In this lesson we’ll make a change and commit that WIP change. Then we’ll create a pull request requesting help from the project maintainer.

How to create a Pull Request on GitHub

It’s not often that you’ll get a Pull Request on GitHub just right the first time you try. You generally will iterate with the project maintainer on your solution before your PR gets merged. In this lesson, we’ll explore some of the tools that projects use to manage contributions to open source projects on GitHub.

How to Collaborate on a Pull Request on GitHub

Once you’ve made your code updates locally, all you need to do is commit those changes and push that commit to your Pull Request branch. In this lesson we’ll also talk about how to skip git hooks that may be included in the project when you just need help.

How to update a Pull Request on GitHub

Sometimes your Pull Request can fall behind master in a repository and occasionally that will result in merge conflicts which you have to manage yourself. In this lesson we’ll learn how to use `git rebase` to update our pull request branch to the latest version of master and resolve merge conflicts with git.

How to rebase a git Pull Request branch

Often, project maintainers prefer that a single pull request be represented by a single commit. It makes the git history cleaner and easier to understand. So before your pull request is merged you’ll want to do an interactive git rebase to squash all of your commits and fix your commit message.

How to squash multiple git commits

Let’s look at the GitHub commits and list of contributors now that our pull request has been merged. And we’ll wrap this series up with a few tips. Feel free to practice on [stack-overflow-copy-paste](https://github.com/eggheadio-github/stack-overflow-copy-paste), and see the Pull Request demonstrated in this lesson [here](https://github.com/eggheadio-github/stack-overflow-copy-paste/pull/9).

Getting a Pull Request Merged and Wrapping up

When working on a file, we often want to know who made certain changes last; we can use `git blame` to see details about the last modification of each line in a file. In this lesson, we show and example of using `git blame` to see who made the last change on a line in a file, and then we use the output of `git blame` to use in other tools like `git log` to see the full context of why the change was made and what other parts of the code base were effected at the same time as the line from `git blame`.

Practical Git: Show who changed a line last with git blame

Using `git tag` we can create references to commits that are immutable; this is usually used for making public releases. In this lesson, we show how to use `git tag` and go over common Semantic Versioning (AKA semver) conventions.

Practical Git: Use semantic versioning with git tag

Sometimes its nice to clean up commits before merging them into your main code repo; in this lesson, we go over using `git rebase` to `squash` commits together and then rename the condensed commit message. We also talk about potential issues with rebasing and where to be careful.

Practical Git: Clean up commits with git rebase

Sometimes you find a bug in your project that has been around for a while without being noticed; it can be hard to track down where that bug was introduced and why just by searching through logs and diffs. Git has a slick tool called `git bisect` that can be used to find out which commit introduced problem in our code - it creates a binary search where the programmer can mark each search commit as `good` or `bad`; by the end of the bisect, Git shows you exactly which commit introduced the issue. In this lesson, we walk through an example of using `git bisect` from start to finish.

Practical Git: Diagnose which commit broke something with git bisect

It can be helpful to see the changes between two sets of code; `git diff` lets us do this by comparing two Git references and outputting the differences between them. In this lesson, we show how to use `git diff` along with the `--stat`, `--cached`, `HEAD`, `origin/master`, `file(s)/dir(s)` options.

Practical Git: Compare file changes with git diff

A Git repo is much more useful when you know what it is; it has become a convention to add a `README` markdown file to the root of your repos which explains what the project is as well as anything else you want to add. In this lesson we create a `README.md` file and push it to our remote repo for others to see.

Practical Git: Document repos with README files

Because semantic-release requires a specific message format, it's easier to follow this convention using a tool called commitizen. In this lesson, we'll use it to write our first conventional commit message.

Writing conventional commits with commitizen

If you make a mistake with a commit and need to make changes or you'd like to update the commit message of the most recent comment, you can do this with the `git commit --amend` command.

Git: How to change the most recent commit with `--amend`

In this lesson, we'll add a new feature to our library and use commitizen to generate our commit message that follows the convention for semantic-release to know it needs to bump the minor version.

Committing a new feature with commitizen

When running the `git log` command, we can pass in options as arguments to _format_ the data shown for each commit. In this lesson, we show how to use the `oneline`, `decorate`, `graph`, `stat`, and `p` options with `git log`.

Practical Git: Format commit history with git log arguments

Git lets us run scripts on git events like `pre-commit`, `pre-rebase`, `post-commit`, `post-merge`, `post-checkout`, etc. You can do this by adding an executable file to the `./git/hooks` directory which has a name matching the git hook name. In this lesson, we walk through this process by setting up a `pre-commit` hook which runs our `npm test` and `npm run lint` npm scripts to ensure we don't have any failing tests or lint errors before committing.