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

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!

Fix Common Git Mistakes

Knowing your everyday toolset increases your productivity as a developer. And Git is one of those tools you use on a daily basis. Mastering Git is tough; it has hundreds of different commands, often even inconsistent at how you pass in flags and configuration options. On the other side, there are a lot of good Git courses out there already, explaining all of these commands in detail. 

With this course, I aim at a different goal. You will walk through a series of scenarios which you’ll most commonly encounter in your daily work life as a developer. I’m talking:
 - updating your feature branch with the latest changes from master
 - polishing your git history to make it ready for being peer-reviewed
 - moving a set of commits to another branch
 - undoing accidental commits

The goal is not to cover everything, but those tasks that will greatly improve your daily productivity with Git.


Productive Git for Developers

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).

Practical Git for Everyday Professional Use

“Feel free to submit a PR!” - words often found in GitHub issues, but met with confusion and fear by many. Getting started with contributing open source is not always straightforward and can be tricky. With this series, you’ll be equipped with the the tools, knowledge, and understanding you need to be productive and contribute to the wonderful world of open source projects. Much of this series speaks about GitHub, but most of the concepts are generally applicable to contributing to any open source project, regardless of where it’s hosted.

So enjoy the course and start contributing to the projects you use and love today!

How to Contribute to an Open Source Project on GitHub

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.

Topics

Instructors

Content Type

git