As modern web developers, we are likely to use git on a daily basis. It's a wonderful distributed version control system, and with only a few commands in our toolbelt it is quite powerful and convenient.

In this course, you will learn the basics of using git, as well as some more advanced commands that you should find useful!

Check out these [**community notes for this course on Github**](https://github.com/eggheadio-projects/practical-git-for-everyday-professional-use-notes).

Getting started with Git requires you to add a .git folder to your project on your machine and then set up that folder to point to a remote repository. In this lesson, we walk through using `git init` and `git remote` to do this; we use GitHub for this remote repository as an example, but keep in mind that any Git repo hosting service will work.

Practical Git: Create local repos with git init

When working on code, we need a way to stay in sync across multiple devices and potentially multilpe team members. We also may need to work on our code offline. To do these things, we can "clone" a remote repo (from a git repo hosting service like GitHub or Bitbucket); git cloning means we make a copy of an existing remote repository onto our local machine with the `git clone` command. This command also automatically sets up the remote repo and branch tracking. Once our repo is cloned to our machine, we can work on the code in this directory offline or with teammates at the same time and then when we need to sync up we can push our code back to the central “remote" repo; we can also clone this same repo onto multiple machines and “pull” updates from the central “remote" repo whenever we want. In this lesson, we walk through how to do this.

Practical Git: Copy remote repos to local machines with git clone

When working with Git, the most common thing developers do is stage, commit, and push the changes they make to a code base - this "edit -> stage -> commit -> push" cycle is the main workflow when using Git; it lets developers make "snapshots" of changes to their codebase which they can share and revert back to. In this lesson, we make some changes to our codebase and then `git add` (stage), `git commit` (store in history), and `git push` (sync with our remote repository) those changes. We also use `git status` along the way to see an update of where our repository is at.

Practical Git: Capture code history snapshots with git add/commit/push

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

`git pull` lets us get the latest changes from our project's remote repo (most likely from co-workers or other developers working on our project) and merge (combine) them with our local code. It's kind of like Dropbox for code, but you tell git when you want it to get the latest changes from the remote when it is most convenient for you. In this lesson, we use `git pull` and discuss how it is a shortcut for running `git fetch` and `git merge`.

Practical Git: Sync local and remote repos with git pull

When working on a project, it is much easier to work on features and bugs in isolation of the rest of the project. We can do this with git branches; a branch is a copy of the working directory, staging area, and project history; we create a branch, then check it out, then add commits. After our feature has been built, we can then merge it back into the main stable branch - which is `master` by default. In this lesson we go over how to create a branch with `git branch {branch-name}`, viewing all branches with `git branch`, switching branches with `git checkout` plus a few helper commands.

Practical Git: Isolate feature development with git branch

Once a feature has been created inside of a branch, we can combine it back into the main `master` branch by using `git merge`. In this lesson, we go through a complete workflow of creating a feature branch and merging it back into the `master` branch.

Practical Git: Sync branches with git merge

Sometimes when you run `git merge` (also during a `git pull` which runs a `git merge`) you get a merge "conflict"; this means that the same line(s) of code were changed locally as in new changes in the remote (most likely from another developer working on a related feature); `git merge` can automatically merge all other changes but when the same line is modified in two places, you have to fix the conflict manually. In this lesson, we show how a conflict happening from a `git pull`, and then how to fix it using `git status` to update the conflict markers in our file(s) with conflicts. You can use a graphical app for this, but this lesson will show you how to resolve conflicts directly from the command line and your code editor.

Practical Git: Resolve merge conflicts with git status

Sometimes when we are working we need a way to pause and switch gears to deal with something more critical; often when this happens we aren't ready to create a `git commit`; instead, we can use `git stash` to save our uncommitted changes locally, switch branches and fix the critical issue, switch back to our incomplete feature, and finally run `git stash apply` to get our unfinished changes back into our branch without affecting the rest of the codebase. In this lesson, we show a real world example of doing this with a critical bug.

Practical Git: Save uncommitted changes with git stash

When using a git command that can have a large amount of output (like `git log`, `git diff`, or `git blame`), Git opens the command output in our terminal "pager"; on most modern Unix-based systems, the default pager will be ["less"](https://en.wikipedia.org/wiki/Less_(Unix)). Learning a few _less_ commands will help us deal with this git command output that opens in the pager. In this lesson, we show some of the most useful of the less commands: `q` (quit), `j` (down), `k` (up), `Ctrl f` (forward), `Ctrl b` (backward), `/{search}` (search), and `n`/`N` (next/previous search result).

This lesson only covers some of the most critical _less_ commands; there are more commands available. A good chunk of the commands (and "motions") of the Unix pagers are also used by vi (or vim) and other Unix programs.

Practical Git: Navigate git command pager output with Unix less commands

It's often helpful to view the history of a code project; with Git, we can use the `git log` command to view all commits in our repo. This lets us view information about each commit like the commit id (for use in other git commands), author, author's email, and commit message. We can format the git log commit output to display more or less information or filter to specific commits using `git log {arguments}` which will be covered in the next few lessons of the course.

Practical Git: View commit history with git log

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

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

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

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

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.

Practical Git: Run scripts on git events with git hooks

You can set up global "git config" settings that apply to all git projects on your system. In this lesson, we review how the `./gitconfig` file works. We then add our own git config settings: username, email, editor, and git aliases.

There are many other git config commands that can be used, but this lesson shows you pattern behind them all so you can view and edit your own settings.

Practical Git: Configure global settings with git config

Most projects have automatically generated files or folders from the operating system, applications, package managers etc. Usually, we don't want to include these types of things in our remote repos because they can clutter the git history/storage and are not applicable to everyone that works on the project. In this lesson, we show how to create a `.gitignore` file to ignore files and folders from being tracked by git.

Practical Git: Remove unnecessary git tracking with .gitignore files

If you regularly use code editors, GUI tools or other programs that automatically create files and folders, you may want to set up a global `.gitignore` file which will apply to every repo on your machine. In this lesson, we show how to do that by creating a `.gitignore_global` file with the dotfiles in our `~/` root directory, and then link it to all git repos using our global `.gitconfig`.

Practical Git for Everyday Professional Use

Instructor

Course content (22 lessons)

Instructor