How to Make Changes to a Previous Git Commit (Even Older Ones!)

Whether you forgot to update a file or want to clean up your commit history, Git gives you powerful tools to change past commits. Here’s how to do it safely and effectively.

There are 2 sets of instructions:

How to Change the Most Recent Commit
How to Change an Older Commit (Not the Latest One)

Follow whichever set of instructions makes sense for your situation.

1. How to Change the Most Recent Commit

Step 1: Make your changes to the code

Make the changes you want to make to your code then run the git add command:

# Make your code changes
git add .

Step 2: Add the changes to the latest commit

# Option 1: keeps the commit message the same
git commit --amend --no-edit

# Option 2: allows you to modify the commit message
git commit --amend

git commit --amend without the --no-edit flag opens your editor so you can modify the commit message.

⚠️ Important: Only amend if the commit hasn’t been pushed to a shared branch. Amending a pushed commit rewrites history, which can mess with other collaborators.

2. How to Change an Older Commit (Not the Latest One)

Step 1: Start an interactive rebase

To edit an earlier commit (e.g., the second one back), use interactive rebase:

git rebase -i HEAD~n

Replace n with how many commits back you want to go.

You’ll see something like:

pick a1b2c3 Fix login bug
pick d4e5f6 Update README
pick 789abc Add scraper module

Each line represents a commit.

Step 2: Change `pick` to `edit`

Change pick to edit on the line you want to modify:

pick a1b2c3 Fix login bug
edit d4e5f6 Update README
pick 789abc Add scraper module

This tells Git: “Pause at this commit so I can change it.”

❓ What if nothing happens when you try to type?

If Git opens Vim (default for many systems), here’s how to use it:

Press i to enter Insert mode – now you can type.
Change pick to edit as needed.
Press Esc to exit insert mode.
Save and exit by typing the following:

:wq

Then press Enter.

Step 3: Git Pauses the Rebase

After saving, Git will stop at the commit you marked for editing. You’ll see a message like:

Stopped at d4e5f6... Update README

Step 4: Make Your Changes

Make whatever changes you need to the code. Then:

git add .
git commit --amend

You can now update both the code and the message if you want.

Step 5: Continue the Rebase

Once you’re done:

git rebase --continue

Git will resume the rebase and replay the rest of your commits.

Made a Mistake?

To cancel the rebase and go back:

git rebase --abort

🧼 After Editing Commits: Push Carefully

If you’ve already pushed these commits to a remote branch, you’ll need to force push:

git push --force

⚠️ Use with caution – force pushing can overwrite others’ work. Only do this on branches you own or after coordinating with teammates.

How to Check if the Current Directory is a Git Repository

Use this command in your Terminal to determine if the directory you are currently in is a Git repository or not:

git rev-parse --is-inside-work-tree

The shell prints true if you are in a git repository’s working tree. It prints false if you are inside the ‘.git’ tree but not the working directory, and it prints a fatal error if it’s neither (not connected to any git repo).

Both ‘true’ and ‘false’ are printed on STDOUT with an exit status of 0, the fatal error is printed on STDERR with an exit status of 128.

Hiding API Keys in Environment Variables and Pushing Code to Github

To accomplish this, we will be using an npm package called dotenv.

Dotenv is a zero-dependency module that loads environment variables from a .env file into process.env

Install the dotenv package

npm i dotenv

2. Require dotenv in the server file

require('dotenv').config();

3. Create a new file in your project called .env

4. In the .env file, paste all of your API keys

API_KEY=4423b234y329324b32

5. Access the API key with process.env

const api_key = process.env.API_KEY;

6. Create a .gitignore file and add the .env file to it

The code in the .gitignore file:

.env

7. Upload to Github!

It’s recommended to include something that will help others understand what to do with .env variables whether that be using the README, .env_sample, etc.

About Github Pages

Github Pages is a free solution for deploying your websites to the Internet.

There are three types of GitHub Pages sites:

Project
User
Organization

Project sites are connected to an individual project hosted on GitHub. You can create an unlimited number of project sites. User and organization sites are connected to a specific GitHub account. You only get one user or organization site per Github account.

GitHub Pages source repositories have a recommended limit of 1GB.
GitHub Pages sites have a soft bandwidth limit of 100GB per month.
GitHub Pages sites have a soft limit of 10 builds per hour.

Github Pages publishes any static files that you push to your repository.

Create your own static files OR use a static site generator

You can create a site for yourself or your organization by creating a repository with Github Pages URL as its name and adding web content to its master branch

Benefits of Github Pages

Free!!
Can use custom domain
HTTPS support
Ingrained version control in your site

Reasons not to Use Github Pages

You probably think that Github Pages seems perfect, right? Well, it is… for certain types of websites. For small static websites, such as a portfolio website, Github Pages is a perfectly suitable option, but for more involved web applications with complex server implementation, Github Pages is rendered inadequate.

GitHub Pages sites shouldn’t be used for sensitive transactions like sending passwords or credit card numbers.

GitHub Pages is not intended for or allowed to be used as a free web hosting service to run your online business, e-commerce site, or any other website that is primarily directed at either facilitating commercial transactions or providing commercial software as a service (SaaS).

GitHub Pages does not support server-side languages such as PHP, Ruby, or Python.

How to Run a Project from Github

There’s a lot of benefit in looking at, using, and learning from other people’s code/projects. One of the best places to find such projects is Github.

First, make sure you have npm installed. If you don’t, run this command in Terminal:

npm install npm@latest -g

Installing the Project

Clone the repo

git clone https://github.com/AlanBayWalker/film-cloud.git

2. Run npm install inside project root directory

npm install

3. Start the server

npm run start

4. Explore

Have fun :)

Automatically Fix Vulnerable Dependencies in your Github Repositories

It can be a little alarming at first to see a glaring message from Github warning you of potential security vulnerabilities in the dependencies within your package.json file.

So we know that GitHub sends Dependabot alerts when they detect vulnerabilities affecting your repository. But what exactly do they mean by “vulnerability”?

A vulnerability is a problem in a dependency project’s code that could be exploited to damage the project and thus other projects that use its code (like yours). Vulnerabilities vary in type, severity, and method of attack.

When your code depends on a package that has a security vulnerability, this vulnerable dependency can cause a range of problems for your project or the people who use it.

Letting Github Handle Alerts

You can navigate to your security alerts by clicking the “See Dependabot alerts” button in the yellow warning message at the top of the repository.

Or go to the Security tab > Dependabot alerts

You should see an alert(s) like this:

Make sure you have the “Dependabot security updates” option set to allow Github to automatically initialize pull request updates for vulnerable dependencies:

When Github has found a solution to the vulnerability, it will put a notification in the Pull Request section of your repository. Navigate to this section and you should see a pull request put here by Github:

Merge this pull request into your project and the problem should be solved!

Pushing Local Project to a Github Repo

Github is a tool that allows you to create a remote repository, a repository that’s hosted on somebody else’s server or computer.

You must create an account in order to follow the rest of the tutorial.

In the top right corner of the Github interface, select the “+” icon, then select “New repository.”
Give your new repository a Name and a Description. Choose to make your repository either Public or Private. DO NOT create a README.md file.
After you press “Create repository,” Github will take you to a page with comprehensive instructions on how to create/push to a repository in the Command Line.

In Command Line:

cd your-project-directory

git init

git remote add origin https://github.com/your-username/RepositoryName.git

git add .

git commit -m "Initial commit"

git push -u origin master

You should be all set in Github!

Git in the Command Line for Beginners

Create a new folder using this command (insert your folder name in the placeholder):

mkdir folder-name

Now we’ll use this command to initialize an empty Git repository within our new folder:

git init

This command initializes an empty Git repository within the folder. The folder is now considered a “working directory.”

Working directory: The directory the .git directory is placed in

You won’t be able to see the .git file in the file system, though. In the Command Line, you have to type the following command to see the hidden files within your working directory in order to see the .git file:

ls -a

In order to commit your files so that you can start tracking changes in them, you must first add your files to the staging area.

Staging area: intermediate place where you can pick and choose which files inside your working directory that you want to commit

Use this command to see which files are currently untracked:

git status

Untracked files will show up in red.

Use this command to add files to your Git staging area (insert your file name in the placeholder):

git add your-file

Use this command to commit all files within the staging area to Version Control:

git commit -m "Initial Commit"

It’s recommended to add a commit message whenever you make a commit so you can differentiate the purpose behind different commits in the same project.

Use this command to see any previous commits you’ve made:

git log

When you have multiple files, it can get tedious adding each one of them to the staging area individually. You can use this command to add every (untracked) file in the working directory to the staging area:

git add .

Files flow in this sequence: Working directory -> staging area -> local repository

Even if we mess up our file(s), we still have access to any versions that were saved under Version Control. We can get access to these previous versions of our files using this command:

git checkout your-file

If you wanted to look at the differences between the current version of a file and the last version saved in Git Version Control, you can use this command:

git diff your-file