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.

This workshop will start by breaking down the four states in which a file can exist, and we'll build up our mental model of git from there. Then, we'll look at how to move files between those states in different ways.

Once we've developed a new model for how git operates, we'll be able to purposefully get ourselves into some sticky situations, and then gracefully recover from them.

If you can handle git add/commit/push, but not much more - then this workshop is perfect for you.

You can finally get some proper git training, and will never have to worry about losing data or messing up the repo again!

Aleksander Ageev

Taylor Bell: Hey Chris, thanks for joining me today.Chris Achard: Yeah, thanks for having me.Taylor Bell: Yeah. So I wanted to ask you a little bit about your new course on Fixing Common Git Mistakes. So what are some of these common mistakes that you've seen?Chris Achard: Yeah, that can be anything from just typos in commit messages to messing up entire commits or merge conflicts and anything where you're worried that you're going to lose the data that you already have and git, that's what this helps with.Taylor Bell: Cool. So you talk a little bit about the mental model of git, could you give me like kind of the elevator pitch on building a better mental model?Chris Achard: Sure. So part of the problem, when I was looking at my own understanding of git, was I didn't understand all the different states that a file could be in. So I kind of start with a file exists on your computer in a repository, git has a staging area and then you have your working directory and then you have the same thing on the server. You have a full repo on the server and then locally you also have this stash area. And so kind of knowing that you can have files in any one of those places with differences helps you because then you can learn about moving those patches, those differences between the different states.Taylor Bell: Cool. And can you walk me through what journey the learner will take in your course? How do you teach these things about git?Chris Achard: Yeah. So we go through a very small little sample project and the code is fairly generic. You don't have to necessarily understand the code, but it's more like we start a new project and we just start making some of the mistakes that you may make on normal projects. And so we have a commit that we want to change the message of, and then we have a commit where we want to add more files and then we accidentally push a bad commit. And so we do all these different things that you may do in a real project just on a much smaller scale.Taylor Bell: Cool. And what kind of next steps would you suggest after somebody takes your course?Chris Achard: After this, you should have a hopefully much better mental model of git. And you may not memorize all the different ways that you can change things, but you should know, for example, that you can, if you want to go back and change old commits, then you can interactive re-base and do that. And you know how to do that now. And so hopefully it just makes your git usage much more robust in your team or yourself, your own projects.Taylor Bell: Cool. Well, thanks for joining me today and I look forward to upgrading my git knowledge and I can stop Googling these same three things over and over again.Chris Achard: That's right. Yeah. Thanks.

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

fix-common-git-mistakes-resources-sketchnote

Sketch Notes

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

We'll make a new feature branch with:

`git checkout -b new-branch`

and then when we make changes and commit them, we can try to push that branch with:

`git push`

However, in order to get the branch to exist on github as well, we need to set the upstream of the local branch at the same time with:

`git push --set-upstream origin new-branch`

Push a New Branch to github that Doesn't Exist Remotely Yet

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)

Fix a Pull Request that has a Merge Conflict

We've made a pull request and now we can clean up the branches by deleting the feature branch.

Branches are just pointers to commits - so we can safely delete branches without losing the underlying commits (once the commits are merged back into master).

So we'll use the github interface to delete the branch remotely, and to delete it locally we'll use `git remote prune origin --dry-run` and then `git remote prune origin`

That will tell us that the remote is gone, and we can finally clean up the feature branch with: `git branch -d feature-branch`

Cleanup and Delete Branches After a Pull Request

We'll go back into our history with

`git log --oneline`

and then we can pick a previous commit and change its commit message with an interactive rebase.  (Note: you shouldn't try to do this on commits that have already been pushed - only commits you still have locally)

To start the interactive rebase, we'll use:

`git rebase -i HEAD~3`

and then change `pick` to `reword`.  Then we can reword the commit message and the commit will be rewritten for us.

Change the Commit Message of a Previous Commit with Interactive Rebase

We make a .env file and accidentally push it to github.  

In order to remove the .env file, we first have to add it to our .gitignore file - but that's not enough, because the .env file will still be on the branch on github.

So we can remove all of our files from our git cache with:

`git rm -r --cached .`

and then add back all the files we want with:

`git add -A`

(that will exclude the .env file this time - because of the .gitignore file).

Then we can commit that change (which is effectively the same as removing the .env file), and push it, which will remove the .env file from the mater branch.

IMPORTANT! If you have secrets in a file that you remove in this way, you should still consider those secrets compromised, because anyone could have pulled them already - and they are also still in the git history.

git Ignore a File that has Already been Committed and Pushed

We're going to pick a previous commit and enter an interactive rebase with:

`git rebase -i HEAD~2`

and change the word `pick` to `edit` on the commit where we want to add a file.

Then during the interactive rebase, we can add the file, and amend the commit we stopped on with:

`git commit --amend --no-edit`

and then once we're happy, continue the rebase with:

`git rebase --continue`

Add a File to a Previous Commit with Interactive Rebase

We'll enter a more complicated interactive rebase with:

`git rebase -i HEAD~2`

and intentionally cause a merge conflict in a previous commit.

Then we can fix that merge conflict like normal, but finish up the rebase with:

`git rebase --continue`

Fix Merge Conflicts While Changing Commits During an Interactive Rebase

We have created 3 commits that we want to squash together before we push them to github.  We can enter an interactive rebase with:

`git rebase -i HEAD~3`

and then change `pick` to `squash` for the last two commits (we want to squash "down" into the first one).

Then we'll be given the chance to make the commit message for that commit, and once we save the message we'll be left with just a single commit that contains the changes from all three commits.

Squash Commits Before they are Pushed with Interactive Rebase

If we want to completely remove a file from github - including all history - there is a tool that we can use called the BFG.

The github help article is here:

https://help.github.com/en/github/authenticating-to-github/removing-sensitive-data-from-a-repository

And the BGF itself is available here:

https://rtyley.github.io/bfg-repo-cleaner/

We'll start by downloading the BFG jar file, and then cloning a mirror of our repo with:

`git clone --mirror [repo-url]`

Then we can delete our .env file with:

`java -jar ~/Downloads/bfg-1.13.0.jar --delete-files .env my-repo.git`

which will delete the .env file. Then we can use the following command to prune the entire history and garbage collect the remains:

`git reflog expire --expire=now --all && git gc --prune=now --aggressive`

And finally, use `git push` to push that change to github, and remove the .env file from all of the history on github as well.

Fix Common Git Mistakes

Chris Achard

What you'll learn:

Prerequisites:

Credits

Course Content