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

When you want to do a partial commit with git, but you can't "split" a hunk to just the lines you want to commit, you can *manually* edit a hunk in order to commit just a few lines of a larger change. This lesson covers how to manually edit a hunk in git, and how to fix errors like "Your edited hunk does not apply", "patch failed", or "patch does not apply".

Partially Commit a File with Git by Splitting It Manually

With the ability to run unit tests, automatic code formatting and linting, we should avoid ever committing code that does not adhere to our project standards or breaks our tests. In this lesson, we'll install and configure the Husky `npm` package and enforce these checks before a `git` commit is allowed.

Run Linting, Tests and Prettier in git Hooks with Husky

Having a boilerplate project on GitHub makes creating a new project as easy as cloning the project, making a few small adjustments and creating a new git repository for the clone. In this lesson, we’ll clean up the sample code we used to make sure everything was working along the way and then we’ll create a new project with all of the tooling and configuration in place by cloning the boilerplate.

Create a New Project by Cloning the Boilerplate Project

A Unix command used to search files for the occurrence of a string of characters that matches a specified pattern.

grep

When you have a bunch of text to sift through, standard Unix command line utilities like `grep`, `sed`, `awk`, `cut`, `sort`, and `uniq` can help extract the information you want. For example, with a git log for a project, you might want to group commits by day in order to see which days you're most productive, or find out how many commits you made last year. In this lesson, you'll learn how to combine these commands with the pipe operator to extract this data from git logs.

Analyze Git Logs with the Command Line

`git reflog` helps developers recover from their mistakes. The reflog keeps track of any changes or commits to each branch since cloning a repository. It's frequently used to keep track of changes made locally that are sometimes wiped out when pulling in remote changes.

This lesson demonstrates how to use git reflog to restore git commits and branches that have been lost. We will clone a repo, make some changes with commits and branches, remove all of those changes, and then use data from the reflog to restore them.

Restore Commits with git reflog

Git rebase is a super powerful tool, but one many devs shy away from for fear of messing up history. But when you know how to use it safely, you can make your pull requests much easier to understand and reason about.

For anyone interested in the gn log alias I use in this video, it's this:

git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

Rewrite Git History with Interactive Rebase

This lesson demonstrates how to use the git rebase command to reword a commit message deep in your git history.

Reword a Commit with Git Rebase

In this video you'll learn Git-based deployment for web applications for both front-end and back-end resources using AWS Amplify and the Amplify Console.

Hosting & Continuous Deployment for Front End and Serverless Back Ends using AWS Amplify

Whenever I need to make a change to a file that includes a part I don't grasp I try to gather as much informations as possible. One tool that turned out to be very helpful to build up context was seeing who wrote the code & when.

In this lesson I demonstrate you how this can easily be achieved using the VS Code GitLens extension and how to set it up in a way that it's not constantly bothering you.

Get Git Blame insights directly in VS Code using GitLens

If you make a mistake in a commit message but HAVEN'T pushed it yet, you can change that commit message with --amend:

`git commit --amend -m "New message"`

This won't change any of the files in your commit - but will rewrite the commit with the new message.

Change a Commit Message that Hasn't Been Pushed Yet

To add more files to the most recent commit, we can add them to the staging area with:

`git add -A`

and then rewrite the most recent commit to include them with:

`git commit --amend -m "My new message"`

Caution: only do this BEFORE you've pushed the commits - otherwise you will be re-writing history for people who may have already pulled down the old commits.

Add More Files and Changes to a Commit Before Pushing

If you've added files to the staging area (the Index) accidentally - you can remove them using `git reset`.

We'll first add a file to staging, but then back it out with:

`git reset HEAD filename`

in order to pull it back to the working directory, so it doesn't end up in a commit when we don't want it to.

Remove Files from Staging Before Committing

If we've already committed changes that we _don't_ want to push, we can also remove those with `git reset`, but we're going to reset back to a specific commit, either with:

`git reset HEAD~1`

or

`git reset [HASH]`

and that will effectively "undo" the commits before that hash. 

Then we can add and commit only the changes that we want.

Remove Changes from a Commit Before Pushing

`git reset` has three primary options that we might use: `--soft`, `--hard` and `--mixed` (the default).

We'll use `git reset` to undo the latest commit in all three ways, and compare the result of reseting with each flag.

Use and Compare the Different git Reset Options: --hard, --soft, and --mixed

If you've removed a commit with `git reset --hard`, it's still possible to recover the commit using `git reflog` to look up the commit hash.

Once we find the right commit hash, we can reset our branch _back_ to that commit hash with `git reset --hard [HASH]`

NOTE!  git will actually garbage collect abandoned commits (every 30 days or so - so not very often) - so you can't recover from a `reset --hard` forever; which is why it's recommended to avoid `--hard` if you ever want to references those changes.

Recover Local Changes from `git reset --hard` with `git reflog`

Once a commit is pushed, you do NOT want to use `git reset` to undo it - because `reset` will rewrite the history tree, and anyone who has already pulled that branch will have a bad tree.

Instead, we'll use `git revert` to make a "revert commit" (like a merge commit), which will "undo" a specific commit.  So the syntax is:

`git revert [HASH-TO-UNDO]`


Undo a Commit that has Already Been Pushed

If you want to pull over just a single commit from one branch onto another, you can do that with `git cherry-pick [HASH-TO-MOVE]`

We'll demonstrate that by making a commit on a feature branch, and then copying that commit (but not the entire branch) onto master.

Copy a Commit from One Branch to Another

We'll do some work and commit it - but then realize it was on the wrong branch!

To move a commit from one branch to another, we'll first `git cherry-pick` the commit we want, and then use `git reset` to remove the commit from the master branch.  

Then we'll be able to manually delete the changes that we don't want on the master branch.

Move a Commit that was Committed on the Wrong Branch

If we make a change to the same function both locally and remotely, then when we try to pull down the remote changes, we'll run into a conflict - and git won't pull the remote changes down.

So first, we'll use `git stash` to stash the local changes, and then `git pull` to get the remote changes.  To apply the stashed changed, we'll then use `git stash pop`

Since we changed the same function however, we'll get a merge conflict!  So we'll fix the merge conflict, and then add and commit that change.

Finally, we'll drop the change from the stash with: `git stash drop stash@{0}`

Use `git stash` to Save Local Changes While Pulling

To poke around in old code, we can checkout the hash of an old commit with `git checkout [HASH]` - but then we'll be in a "detached HEAD" state.

Detached HEAD just means that HEAD is not pointing to a branch.  That's problematic if we want to save the work that we do in that state - so we first have to make a new branch where we are with `git checkout -b my-new-branch`

Then, any changes we make can be committed to that new branched and saved.

Explore Old Commits with a Detached HEAD, and then Recover

If we try to make a pull request on github that has a conflict, there are a few ways to fix it.

We're going to first back out of the pull request, and then merge `master` into our feature branch.

We'll manage the merge conflict locally, and then do a new pull request (which will not have the conflict)

Topics

Instructors

Content Type

Free or Pro