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

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'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

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

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.

Completely Remove a File from Pushed git History

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

hub is a command-line tool that makes git easier to use with GitHub. In this lesson we cover a couple of the commands in a real-world scenario at the start of a project.

Initializing a new git repo with Github's hub CLI

Gatsby is a blazing fast static site generator built with React. Gatsby gives you all of the modern JavaScript tools you want; set up and ready to go out of the box.

gatsby

We initialize a new Gatsby project while covering a few of the tripping points such as ignoring .cache and public using a .gitignore file.

Initialize a new Gatsby project with a gitignore in yarn workspaces

`git` is an interesting tool for a developer - it's definitely the most widespread version control solution and even after using it for **years**, there's always something new to learn.

In this lesson we're going to learn a quick trick - how to use `-sb` flag in order to modify the `git status` command so it returns a shorter, more succinct info about the state of our changes. 

We're also going to learn how to create an alias for `git status -sb` command so we won't have to type more in order to get a shorter output.

Use -sb flag to get a shorter git status output without unnecessary noise

We scaffold out a new GitHub repo to deploy netlify functions and a small index.html file, while covering Makefile basics and netlify.toml. The lesson ends with a working Netlify site.

Setting up a new GitHub repo to deploy functions on Netlify with Make and netlify.toml

Using the [GitHub CLI](https://github.com/cli/cli) and a shell script, we will automate the process of monitoring pull requests in repositories we maintain. Specifically, open PRs we have created and those awaiting our review.

Monitor Pull Requests with the GitHub CLI

Magit is an emacs git client. It lets you diff your changes and stage/commit them seamlessly.

Diff, Commit, and Push a Change to Git with Emacs Magit Client

By default, git provides `master` as the default branch. This lesson shows how to get round that and use an alternative as the default branch.

The key is to switch to a new branch before you add your first commit, I choose `main` in this lesson. When I push `main` up to Github as the first branch, it gets set to the default.

Configure a New Github Repo to Use a Different Default Branch

By default, git provides `master` as the default branch. This lesson shows how to get round that and use an alternative as the default branch for an existing repo.

Configure an existing Github repo to use a different default branch

Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

express

In this lesson, we will use Auth0 to generate a JWT that we can use to validate future requests to our server.

We will then return that token and test that it works when authenicated by our middleware.

During the lesson, we'll also briefly look at a strategy to keep your credentials out of source control using a .gitignore file. 

Get a JWT From Auth0 in Express to Be Used in Authentication

You can create diffs in markdown to show what has changed in a code snippet. I use this in blog posts to highlight changed lines for readers. This works for code snippets in most markdown packages and on Dev.to.

To show a line of code changing in a function, you can do this:

```diff
function addTwoNumbers (num1, num2) {
-  return 1 + 2
+  return num1 + num2
}
```

First, instead of specifying the programming language, use diff after the backticks. Then at the beginning of any lines of code you want to show as removed, add a -. At the beginning of any lines of code you want to show as added, add a +.

The code would look like this:

````
```diff
function addTwoNumbers (num1, num2) {
-  return 1 + 2
+  return num1 + num2
}
```
````

Create a Diff in Markdown to Show What Has Changed in a Code Snippet

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

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.

Topics

Instructors

Content Type