Complete Git Tutorial – All You Need to Get Started

Git is a Distributed Version Control System (DVCS) used to save different versions of a file (or set of files), wherein any version is retrievable at will.

Git makes it easy to record and compare different file versions. Consequently, details about what changed, who changed what, or who initiated an issue are reviewable anytime.

What Is a Version Control System?

A Version Control System (VCS) refers to the technique people use to save a file’s versions for future reference.

Intuitively, many people already version control their projects by renaming different versions of the same file in various ways like blogScript.js, blogScript_v2.js, blogScript_v3.js, blogScript_final.js, blogScript_definite_final.js, and so on. However, this approach is error-prone and ineffective for team projects.

Moreover, tracking what changed, who changed it, and why it got changed is a tedious endeavor. Thus, the importance of a reliable and collaborative version control system like Git.

What Git Is Not

Git is not a Local Version Control System (LVCS) that saves file changes in a unique format on a local hard disk without collaborative support.

It is also not a Central Version Control System (CVCS) that centrally stores all its versioned files on a single server.

What Git Is

Git is a Distributed Version Control System (DVCS) that allows clients to clone an entire project’s repository onto their disk.

In other words, Git enables storing and manipulating a file’s versions on multiple servers (computers).

So, if a server dies, the project’s repository is still retrievable from another server with a copy.

Additionally, many DVCS—including Git—have remote repositories (an online folder) that foster collaborative work on projects with anyone, anywhere, anytime.

But what exactly is the difference between remote repos and local repositories? Let’s find out.

Remote vs. Local Repositories: What’s the Difference?

Remote repositories are like any local directory—they are just folders.

The main difference between the two repositories is that only the person with the system can access a local repository.

However, a remote repository—located on an open platform like the internet—is accessible by anyone, anywhere, anytime.

As such, remote repositories facilitate dynamic collaboration on projects.

Let’s now discuss the three states of a Git file.

What Are the Three States of a File in Git?

The three primary states (conditions) of a file in the Git version control system are:

Modified
Staged
Committed

What is a modified file state in Git?

A file in the modified state is a revised—but uncommitted (unrecorded)—file.

In other words, files in the modified state are files you have modified but have not explicitly instructed Git to monitor.

What is a staged file state in Git?

A staged file is a modified file you have selected in its current state (version) in preparation for being saved (committed) into the .git repository during the next commit snapshot.

Once you stage a file, it implies that you have explicitly authorized Git to monitor that file’s version.

CodeSweetly ads

What is a committed file state in Git?

Files in the committed state are files successfully stored in the .git repository.

In other words, a committed file is one in which you have recorded its staged version into the .git directory (folder).

Where Does Git Store Your Files?

The three key places versions of a file may reside while version controlling with Git are:

The working directory
The staging area
The .git directory.

What is a working directory?

The working directory is a local folder for a project’s files.

In other words, any folder you create anywhere on a system is a working directory.

What is the staging area?

The staging area is a file Git uses to store details about files it is about to commit into the .git directory.

What is a Git directory?

The .git directory is the folder Git creates inside the working directory you have instructed it to track.

The .git folder is where Git stores the object databases and metadata of the file(s) you have instructed it to monitor.

Let’s now see what a basic Git workflow looks like.

The Basic Git Workflow

Working with the Git Version Control System looks something like this:

Git basic workflow
diagram — The basic workflow of files while version controlling with Git

Modify files in the working directory.

Any file you alter becomes a file in the modified state.
Selectively stage the files you want to commit to the .git directory.
Note
- Any file you stage (add) into the staging area becomes a file in the staged state.
- Staged files are not yet in the .git database.
- Staging puts information about the staged file in a file (called “index”) located inside the .git repository.
Commit the files you have staged into the .git directory. In other words, permanently store a snapshot of the staged files in the .git database.

Any file version you commit to the .git directory becomes a file in the committed state.

So, now that we know Git’s basic workflow, we can discuss how to use it.

How to Use Git

Before you can use Git, you need to install it on your system—so let’s start with the installation process.

Installing Git

You can easily install Git from the Git download webpage.

A handy way to check the version installed on your system is to run the following:

git --version

After the installation, it is necessary to keep it up to date whenever there is a new version.

Updating Git

If you are using a Windows system and your currently installed Git version is 2.16.1 or higher, freely get the latest Git version with this command:

git update-git-for-windows

Once you have the correct version installed on your system, you can proceed with the setup process by initializing Git in your project directory.

Initializing Git

Initialization is to make Git ready to start monitoring files in a specified directory.

To initialize Git in a directory currently not under version control, you must first go inside that directory from your terminal.

cd path/to/the/directory

Afterward, initialize Git in that project’s directory by running the following:

git init

After running the command above, the computer will create a Git repository named .git in the project’s folder.

After the installation and initialization process, the next step is to configure Git. So, let’s do that now.

Configuring Your Project’s Git Username and Email

Here’s the command to configure your username:

git config --global user.name "Your Name"

And here is the command to setup your email:

git config --global user.email "[email protected]"

Suppose you want to change a specific project’s configured name or email address. How can you do this? Let’s find out.

Changing a Project’s Git Username

You can change a project’s username configuration by using the terminal to navigate into that project’s directory and run the following command:

git config user.name "The New Name"

Changing a Project’s Git Email

You can change a project’s email configuration by using the terminal to navigate into that project’s directory and run the following command:

git config user.email "[email protected]"

Let’s now see how to confirm your Git configurations.

Checking Your Project’s Git Configurations

You can view all your project’s Git configurations by running the following:

git config --list

Suppose you wish to confirm the value stored for a single configuration (for instance, your email). In such a case, use the git config <key> command like so:

git config user.email

So, now that you know how to configure your username and email, we can discuss using Git to track your files.

Tracking Your Files with Git

To begin tracking files in an initialized folder, go into that project directory from the terminal and run:

git add <fileOrFolderName>

After running the command above, Git will add the specified file (or folder) to the staging area.

Once Git adds a file (or folder) to its staging area, it means Git has started monitoring that file’s version for further modifications that may occur on it.

Git provides some options you can use with the git add command to help speed up the staging process—especially when you have multiple files to stage. Let’s discuss these options now.

What Are the Git Options for Staging Files Quickly?

The options developers commonly use to quicken the process of adding multiple files to the staging area are:

-A flag
-u flag
The . (dot) option
The * (asterisk) option

What does the `-A` flag mean when staging files in Git?

The -A flag is for staging all modified and untracked files in a project’s entire working directory—regardless of the current project directory in which you are.

git add -A

What does the `-u` flag mean when staging files in Git?

The -u flag is for staging only the modified files you previously committed.

git add -u

What does the `.` (dot) option mean when staging files in Git?

The . (dot) option is for staging all modified and untracked files located only in the current project’s directory in which you are.

git add .

What does the `*` (asterisk) option mean when staging files in Git?

Although you can use the git add * command to stage multiple files. However, to prevent unexpected results, it is best to avoid using it.

Important Stuff to Know about Staging Files in Git

Here are two essential facts to remember whenever you stage files in Git.

1. Staging does not save your files

Whenever you stage your files, it does not imply saving them in the Git directory.

Staging implies that you have added details about your staged files into an “index” file in the Git directory.

2. Git commits only the files you’ve staged

Only the file versions in the staging area get committed to subsequent historic snapshots—not the working directory’s versions.

In other words, whenever you run the commit command, Git will only save the file versions presently in the staging area—not the ones in your working directory.

Let’s now discuss how to commit files to Git.

Committing Files to Git

Committing files to Git means storing the staged version of your working directory’s files in the .git repository.

To commit a file that is currently in the staging area, run the following:

git commit -m "Write a message about the file(s) you are committing"

The -m flag allows you to write your message in-line with the commit command. If you omit it, Git will launch your text editor with comments prompting you to enter your commit message.

You can delete the editor’s comments and type in your commit message. Or you can leave the comments and add your commit message.

Once you’ve finished writing your commit message inside the text editor, exit it so that Git can create the commit.

Writing commit messages with a text editor allows you to write long notes—even with multiple paragraphs. However, for short commit messages, the in-line method is sufficient.

Let’s now discuss the three main parts of a Git commit message.

What Are the Three Main Parts of a Git Commit Message?

The Git commit message developers write in their text editor typically follow the same basic structure:

Summary: Short description of the commit
Body: Additional contextual description of the commit
Footer: Metadata details about the commit, such as external links and issue reference

Syntax of a Git commit message

<summary>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Example of a Git commit message

Use 50 characters or less to summarize the changes

Provide extra information about the changes you are committing. And you
should wrap this addon text at around 72 characters because Git does not
wrap text automatically. Although, some text editors, like VSCode, help
with text wrapping.

Remember that it is essential to use a blank line to separate each section
of your commit message (the summary, body, and footer).

It is okay to have multiple paragraphs in the body section. You can also
use bullet points. However, note the following:

 - Precede each bullet point with a space

 - Separate each bullet point with a blank line

 - People typically use a hyphen or asterisk to indicate bullet points

The footer is the last part of a long commit message. Use it for issue
references, external links, and other metadata details like so:

Resolves: #35

Note the following:

We typically write the footer in a <word-token>: <string> format.
The <word-token> typically uses hyphens (-) instead of whitespace characters to separate words—except while indicating BREAKING CHANGE. This convention helps to differentiate the footer section from the body of a commit message.
You can use whitespace and newline characters in your footer’s <string>.
You can use the BREAKING CHANGE text as your footer’s <word-token>.

Important stuff to know about Git commit messages

Here are six essential facts to remember when writing your commit messages.

1. Standardize your commit message by specifying its type

The Conventional Commits specification recommends prefixing the summary section of your commit message with a type.

Here’s the syntax:

<type>: <summary>

Here’s an example:

fix: Use 50 characters or less to summarize the changes

2. There are 11 `<type>`s developers often use

The eleven <type>s developers typically use to categorize their commits are:

build: for commits that impact your app’s build step or external dependencies—for instance, an update to your NPM package.
chore: for commits that implemented maintenance-related updates, such as updating your .gitignore file, or an existing API key.
ci: for commits that modify your CI (continuous integration) configurations.
docs: for commits that modify your project’s documentation.
feat: for commits that add a new feature to your codebase. This commit type is synonymous with a MINOR release in Semantic Versioning (SemVer).
fix: for commits that add bug fixes to your codebase. This commit type is synonymous with a PATCH release in Semantic Versioning (SemVer).
perf: for commits that improve your app’s performance.
refactor: for commits that refactor specific parts of your codebase—for instance, renaming a function.
revert: for commits that revert your codebase to a previous commit history. You may also add the commit SHAs you are reverting to the footer as references—for instance, Refs: 7b804hrw, b394c306.
style: for commits that modify your code’s style, such as adding semi-colon, white-space, or indentation.
test: for commits that modify your app’s test code.

3. How to indicate breaking changes in a commit message

Suppose a specific commit includes breaking changes. In that case, you can indicate it through one (or both) of the following ways:

Append the commit type with an exclamation mark—for instance, fix!
Add a BREAKING CHANGE: text to the beginning of your commit message’s body or footer section.

Here’s an example:

feat!: Use 50 characters or less to summarize the changes

BREAKING CHANGE: Provide extra information about the changes you are
committing. And you should wrap this addon text at around 72 characters
because Git does not wrap text automatically. Although some text
editors, like VSCode, help with text wrapping.

Resolves: #71
Refs: codesweetly.com/how-to-use-git, codesweetly.com/git-cheat-sheet

4. How to write long commit messages in the terminal

Below is the command line syntax for writing your commit message’s summary, body, and footer.

git commit -m "Write your summary" -m "Write your body" -m "Write your footer"

5. How to view the changes you are about to commit

Suppose you use the text editor to input your commit message. In that case, add the -v flag to the git commit command like so:

git commit -v

By doing so, Git will include the diff of your changes in the editor so you can see the exact changes you are about to commit.

In other words, use the -v flag to include—at the bottom of the text editor’s commit message template—the differences between what you are currently committing and your previous commit.

6. It pays to draft a good commit message

Crafting a good commit message will help your collaborators (and yourself—after some time) understand why you committed a specific version of your project’s files.

It will also help clarify differences between the file versions committed.

Suppose you wish to commit your changes without staging them first. In such a case, you can skip the staging area. Let’s find out how.

Committing Files without Staging Them

You can skip the staging area while committing your files (that is, omit running the git add command) by adding an -a flag to your git commit command like so:

git commit -a

By so doing, Git will automatically stage all the files it is already tracking. After the automatic staging, it will then commit the files.

Suppose you do not want Git to monitor nor commit specific files or folders. How can you do this? Let’s find out.

Making Git Ignore Specific Items

We use a .gitignore file to tell Git the files or folders it should ignore—including not listing them as untracked.

Creating a `.gitignore` file

To create a .gitignore file, go into the root directory where the files you want to ignore are. Then, run the command below in your terminal:

touch .gitignore

Let’s now see how to specify the items you want Git to ignore.

Specifying the items you want Git to ignore

Open your project’s .gitignore file and write the filenames, folders, or file types you want Git to ignore.

Here is an example:

# In a ".gitignore" file, an asterisk (*) is a wildcard symbol that
# means zero or more characters—but not a slash (/)—can replace
# the asterisk.

# The command below will ignore any document starting with "abc"
# located anywhere in this project:
abc*

# The command below will ignore all ".txt" filetypes located anywhere
# in this project:
*.txt

# In a ".gitignore" file, an exclamation mark (!) means "important."

# The command below will track "readme.txt" filetypes, even though
# you've instructed Git—through the asterisk command above—to
# ignore all ".txt" files:
!readme.txt

# The command below will ignore any "package-lock.json" file located
# anywhere in this project:
package-lock.json

# The command below will ignore only the "passwords.text" file
# located in the specified directory:
directory/of/passwords.text

# This command below will only ignore the "NOTE" file in the current
# directory—not in any other folder—of this project:
/NOTE

# The following command will ignore all the content inside any folder
# named "modules":
modules/

# This command below will ignore all ".txt" files directly inside the
# folder named "mix":
mix/*.txt

# Note that the command above will still track all ".txt" files that
# are in the subdirectories of the "mix" folder. For instance, it
# will ignore "mix/test.txt" but will track "mix/real/test.txt".

# In a ".gitignore" file, double asterisks (**) mark—followed by a
# slash (e.g., **/)—is a wildcard symbol that means zero or more
# directories' names can replace the double asterisks.

# The command below will ignore all ".pdf" files inside both the
# folder named "doc" and in any of its subdirectories:
doc/**/*.pdf

# The question mark (?) in the command below means any single
# character—except a slash—can replace the question mark:
sea?.txt

# As such, the command above will ignore files like "seas.txt" or
# "seat.txt". However, it will not ignore files like "seats.txt".

# In a ".gitignore" file, a pair of square brackets "[...]" specifies
# the range of characters acceptable for a single character position.
# Below are some examples.

# The command below means the character after character "n" can
# either be character "s" or character "t":
plan[st].js

# Therefore, the command above will match files like "plans.js" or
# "plant.js". But it will not match "plane.js" nor "plants".

# The command below means the character after character "n" can be
# any character between numbers "3 to 9" inclusive:
plan[3-9].js

# Therefore, the command above will match files like "plan3.js" or
# "plan5.js". But it will not match "plan10.txt" nor "plan1".

# The following command means the character after character "n" can
# be any character between letters "f to z" inclusive:
plan[f-z].js

# As such, the command above will match files like "plank.js" or
# "plany.js". But it will not match "plan2.txt" nor "plane".

# An exclamation mark within a square bracket "[!]" means "negate".

# The command below means the character after character "n" cannot be
# character "s" nor character "t":
plan[!st].js

# Therefore, the command above will match files like "plane.js" or
# "plan2.js". But it will not match "plans.js" nor "plant".

Viewing a project’s commit history is a common practice while developing an app. So, let’s discuss how developers do this.

Viewing a Project’s Commit History

You can view your project’s commit history by running the following:

git log

After running the command above, if you get stuck on the Git console, just hit your keyboard’s Q key to exit.

Below are some options you can use with the git log command.

Flag	Description	Example
`-3`	Limit the number of commit histories displayed to the last three entries.	`git log -3`
`-p` (Short for `--patch`)	Display the diff (differences) introduced in each commit. Note: The `git log` command displays only basic commit history details—such as the author, date, and commit message. So, adding the `-p` flag allows you to include the differences introduced in each commit.	`git log -p`
`--color-words`	Make the `git log -p`’s output less cumbersome by only displaying each chunk’s modified words and their context—not each modified line and its context.	`git log -p --color-words`
`--abbrev-commit`	Display an abbreviated version of the commit hash instead of all 40 characters.	`git log --abbrev-commit`
`--pretty`	Display the default version of the commit history.	`git log --pretty`
`--pretty=short`	Display the shorter version of the commit history.	`git log --pretty=short`
`--pretty=full`	Display the full version of the commit history.	`git log --pretty=full`
`--pretty=fuller`	Display the fuller version of the commit history.	`git log --pretty=fuller`
`--pretty=oneline`	Display the one-line version of the commit history.	`git log --pretty=oneline`
`--pretty=oneline --abbrev-commit`	Display the one-line version of the commit history while also abbreviating the commit hash.	`git log --pretty=oneline --abbrev-commit`
`--oneline`	A shorthand version of `--pretty=oneline --abbrev-commit`	`git log --oneline`
`--name-only`	Display the names of the modified files. Note: The `git log` command displays only basic commit history details—such as the author, date, and commit message. So, adding the `--name-only` flag allows you to include the names of the files you modified in each commit.	`git log --name-only`
`--name-status`	Display the names of modified files and their modification status (added, modified, or deleted).	`git log --name-status`
`--relative-date`	Display the relative date format instead of the full date—for instance, 2 days ago.	`git log --relative-date`
`--stat`	Display the statistic of the changes that occurred in each commit.	`git log --stat`
`--shortstat`	Display a brief statistic of the changes that occurred in each commit.	`git log --shortstat`
`--graph`	Display the “branch and merge” history’s ASCII graph alongside the commit history.	`git log --graph`

Let’s now see how to compare a project’s commit history.

Comparing the Commit History of Two Git Branches

You can compare the commit history of one Git branch with another like so:

git log first-branch-name..second-branch-name

The code above tells Git to compare the commit history of first-branch-name with second-branch-name.

Therefore, Git will log out the commits present in second-branch-name but not in first-branch-name.

Other Git Commands You Will Find Useful

Below are other handy Git commands.

Checking the status of your files

git status

Checking where Git got installed on your system

which git

Comparing the file version in the staging area with the most recent version committed into the Git directory

git diff --staged

The command above will show the difference between the file versions in the staging area and those most recently committed to the Git directory.

Comparing the version of files in the working directory with those you added to the staging area

git diff

The git diff command shows the changes in a working directory’s files you’ve not yet staged.
By default, git diff will compare a working directory’s file version with those in the staging area. However, for any file currently not in the staging area, git diff will compare the working directory’s version with the one you last committed.
Suppose nothing shows after running the diff command above. In that case, it implies the same file version exists in the working directory and the staging area.
The git diff command does not show the entire content of a file. Instead, it displays only chunks.
To make the chunk less cumbersome, add the --color-words flag to the git diff command (that is, git diff --color-words). Thus, each chunk will include just the modified words (not lines) and their context.

Confirming if a specific item is in the `.git` directory

git ls-files | grep <fileOrFolderName>

Opening gitignore’s manual page

git help gitignore

Removing files from Git version control and the working directory

Use the following code to delete a file from your system and to stop Git from tracking the file.

git rm fileToDelete

Removing files from Git version control only

Use the following code to stop Git from tracking a staged file.

git rm --cached fileToDelete

Renaming a file

Here’s how to rename a file:

git mv currentFileName newFileName

How to skip writing a commit message

Suppose you made only minor modifications to your file and prefer not to write a commit message. In such a case, you can skip writing the commit text by adding the --no-edit option to your git commit command like so:

git commit --amend --no-edit

How to stage and commit at once

Here’s how you can stage and commit your file at once:

git add <fileOrFolderName> && git commit -m "A message about your commit"

How to undo a commit

Suppose you wish to undo a specific commit. In such a case, run:

git revert <commit-to-undo>

The snippet above tells Git to create a new commit that reverts the changes introduced in <commit-to-undo>.

The git revert command does not delete any data. Instead, it creates a new commit that reverses the changes added to the specified commit.
After committing the reverted changes, the HEAD pointer will move to the new commit.
In the snippet above, replace <commit-to-undo> with the commit you wish to undo—for instance, git revert b91ey04.
Use a --no-commit (or -n) flag to stop Git’s default behavior of automatically committing the reverted changes. The --no-commit flag will put the reverted changes in your working directory for you to edit further and commit manually.
Suppose you wish to use git revert’s default commit message. In that case, add the --no-edit flag to the command—for instance, git revert b91ey04 --no-edit. By so doing, Git will not prompt you to provide a commit message for the reverted commit.

Undoing the pushing of a commit upstream

You can undo a commit you’ve recently pushed to a remote repository by running:

git revert HEAD
git push origin main

The snippet above tells Git to do the following:

Create a new commit that reverts the changes made in the HEAD commit. (Note: The HEAD commit means your recent commit.)
Push the local branch (named main) to the remote branch (origin).

Undoing the staging of a specific file in the staging area

Here’s how to remove a specific file from your project’s staging area:

git reset HEAD fileToUnstage

The command above can be dangerous if you add a --hard flag.

However, using git reset without the --hard flag makes it a non-destructive tool that would not change any file in your working directory.

Alternatively, you can also use:

git restore --staged fileToUnstage

Undoing the staging of all files in the staging area

Here’s how to undo the staging of all the files in the staging area:

git reset

Viewing all the files currently in the staging area and the `.git` repository

git ls-files

Writing text into a file via the terminal

echo textToWrite >> fileToWriteInto

>> will append your text to the end of the file’s content.
> will overwrite any existing content of the specified file.
Suppose you wish to use symbols, such as an exclamation mark (!). In that case, prepend each with a backslash (\) mark. In doing so, Git will analyze the character as a text—not a command.

Here’s an example:

Write “Hello!!!” into a file via the command line:

echo Hello\!\!\! >> fileToWriteInto

Dangerous Git Commands

Commands that permit you to undo changes are generally dangerous because they can permanently delete your work—if you do it wrongly!

Therefore, be super careful with these commands!

How to amend your last commit

Suppose you forgot to include something in your last commit—for instance, a file. In that case, do the following:

Use the git add <fileName> command to stage the missing content.
Run the following code:

git commit --amend

After you’ve invoked the snippet above, a COMMIT_EDITMSG file will open, prompting you to update your previous commit message.

You can choose to update the previous commit message or retain it.

Once you’ve decided on the message to use, exit the COMMIT_EDITMSG file so that Git can create the commit.

Afterward, Git will automatically replace your last commit with this updated version.

How to forcefully push to a remote repository

You can forcefully overwrite a remote repository with your local .git repo by running the following:

git push --force

By so doing, Git won’t ask you to update your local branch before pushing to the remote repo.

In other words, Git’s default setting compels you to update your local branch with the latest commits of the remote repository to which you wish to push.

However, the --force flag allows you to override Git’s default configuration.

Keep in mind that git push --force is a dangerous command because:

It makes it easy to erase commits your collaborators recently pushed to the remote repo.
The local repo you are moving upstream will replace any old commit on which your colleagues’ new work still relies.

How to rebase Git commits

Git rebasing is a technique used to change the base of a specific commit from one branch to another.

In other words, Git rebase allows you to cut off one branch’s commit and reapply it to another.

The three main things people do with the git rebase command are:

Modify a previous commit message
Merge multiple commits
Delete redundant commits

Let’s discuss some helpful ways to use the rebase command.

How to modify a previous commit message

Suppose you wish to amend a previous commit message. In that case, use the rebase command like so:

git rebase -i HEAD~2

The snippet above tells Git to begin an interactive rebasing session from the two previous commits.

Once you’ve invoked the interactive rebasing command, a git-rebase-todo file will open in your text editor. The file will look like this:

pick 324c9db Create index.html file
pick 1d0923a Create Addition component

# Rebase 5b8c120..1d0923a onto 5b8c120
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified); use -c <commit> to reword the commit message
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.

The opened file allows you to specify the commits where the script should stop so that you can edit the previous commit message.

For instance, suppose you only need to modify 324c9db commit’s message. In that case, you would change 324c9db’s pick command to edit like so:

edit 324c9db Create index.html file
pick 1d0923a Create Addition component

Then, you would save and close the git-rebase-todo file.

Afterward, Git will go back to the 324c9db commit and drop you a piece of information on the command line that looks like this:

$ git rebase -i HEAD~2
Stopped at 324c9db...  Create index.html file
You can amend the commit now, with

  git commit --amend

Once you are satisfied with your changes, run

  git rebase --continue

In other words, run git commit --amend to modify 324c9db commit’s message. Then use git rebase --continue to finish the rebase process.

How to squash commits

The interactive rebase tool lets you squash (merge) two or more commits together.

For instance, suppose you began an interactive rebasing session from your project’s root commit like so:

git rebase -i --root

Let’s now assume that after running the snippet above, a git-rebase-todo file opened with four commit histories similar to this:

pick 7e8525d Create project directory
pick 5b8c120 Initialize NPM
pick 324c9db Create index.html file
pick 1d0923a Create Addition component

You can merge the two most recent commits with the third one by changing the word pick to squash like so:

pick 7e8525d Create project directory
pick 5b8c120 Initialize NPM
squash 324c9db Create index.html file
squash 1d0923a Create Addition component

Once you save and close the git-rebase-todo file, a COMMIT_EDITMSG file will open, prompting you to merge your previous commit messages.

In other words, your COMMIT_EDITMSG file would look like this:

# The first commit's message is:
Initialize NPM

# This is the 2nd commit message:
Create index.html file

# This is the 3rd commit message:
Create Addition component

You need to merge the three commit messages.

Here’s an example:

# This is a combination of 3 commits.
Create package.json, index.html, and Addition.js files

Afterward, save and close the COMMIT_EDITMSG file so that Git can finish the squashing process.

Splitting a previous commit

The interactive rebase tool allows you to split a previous commit into multiple commits.

For instance, suppose you began the interactive rebasing session from your project’s root commit like so:

git rebase -i --root

Let’s now assume that after running the snippet above, a git-rebase-todo file opened with three commit histories like this:

pick 5b8c120 Initialize NPM
pick 324c9db Create index.html and style.css files
pick 1d0923a Create Addition component

You can split the middle commit (324c9db) into two different commits.

In other words, you can split Create index.html and style.css files into two commits: the first will use “Create index.html file” as its commit message, and the second will use “Create style.css file”.

Here are the steps required to split your previous commit:

1. Change pick to edit

Change the pick command to edit for the commit you wish to split.

Here’s an example:

pick 5b8c120 Initialize NPM
edit 324c9db Create index.html and style.css files
pick 1d0923a Create Addition component

Save, and close the git-rebase-todo file once you’ve changed the command.

Afterward, Git will go back to the 324c9db commit and drop you a piece of information on the command line that looks like this:

$ git rebase -i --root
Stopped at 324c9db... Create index.html and style.css files
You can amend the commit now, with

  git commit --amend

Once you are satisfied with your changes, run

  git rebase --continue

CodeSweetly ads

2. Reset the commit

At this stage, reset the commit to the one before the HEAD pointer like so:

git reset HEAD^

The snippet above will move the HEAD pointer to the commit before the one you wish to split.

In other words, the git reset command will update your project’s staging area with the content of the commit right before the one you want to split.

Therefore, you can now create and commit new files individually.

3. Stage and commit files

Once you’ve reset your HEAD pointer, you can begin to stage and commit files.

For instance, you can split “Create index.html and style.css files” into two commits by staging and committing them like so:

git add index.html
git commit -m "Create index.html file"
git add style.css
git commit -m "Create style.css file"

4. Finish the rebase process

When you’ve finished splitting your previous commit, end the rebase process by running the following:

git rebase --continue

Replacing a working directory’s file with the last committed or staged version

git checkout -- localFileToDeleteAndReplace

Alternatively, you can also use:

git restore localFileToDeleteAndReplace

Sharing a Git repository online makes it easy for collaborators to collaborate on a project from anywhere, at any time.

Moreover, GitHub—a popular online platform used for sharing .git repositories—takes Git collaboration to a whole new height.

To share your Git repository (your project’s committed file versions) on GitHub, follow this How to Host a Git Repository on GitHub guide.

Cloning a Git Repository

Git Cloning is mainly about getting (downloading) a copy of a .git repository.

For instance, you may need a copy of a project you intend to modify. In such a case, getting a clone of the project’s .git directory puts in your possession all the file versions the project’s contributors have committed to the .git repository.

To clone a repository, run the following:

git clone <theGitRepoURL> <state the place to put the cloned git folder>

By so doing, Git will download a copy of the specified .git repository into the place you’ve identified.

Useful Resources

Support CodeSweetly

Complete Git Tutorial – All You Need to Get Started

What Is a Version Control System?

What Git Is Not

What Git Is

Remote vs. Local Repositories: What’s the Difference?

What Are the Three States of a File in Git?

What is a modified file state in Git?

What is a staged file state in Git?

What is a committed file state in Git?

Where Does Git Store Your Files?

What is a working directory?

What is the staging area?

What is a Git directory?

The Basic Git Workflow

How to Use Git

Installing Git

Updating Git

Initializing Git

Configuring Your Project’s Git Username and Email

Changing a Project’s Git Username

Changing a Project’s Git Email

Checking Your Project’s Git Configurations

Tracking Your Files with Git

What Are the Git Options for Staging Files Quickly?

What does the -A flag mean when staging files in Git?

What does the -u flag mean when staging files in Git?

What does the . (dot) option mean when staging files in Git?

What does the * (asterisk) option mean when staging files in Git?

Important Stuff to Know about Staging Files in Git

1. Staging does not save your files

2. Git commits only the files you’ve staged

Committing Files to Git

What Are the Three Main Parts of a Git Commit Message?

Syntax of a Git commit message

Example of a Git commit message

Important stuff to know about Git commit messages

1. Standardize your commit message by specifying its type

2. There are 11 <type>s developers often use

3. How to indicate breaking changes in a commit message

4. How to write long commit messages in the terminal

5. How to view the changes you are about to commit

6. It pays to draft a good commit message

Committing Files without Staging Them

Making Git Ignore Specific Items

Creating a .gitignore file

Specifying the items you want Git to ignore

Viewing a Project’s Commit History

Comparing the Commit History of Two Git Branches

Other Git Commands You Will Find Useful

Checking the status of your files

Checking where Git got installed on your system

Comparing the file version in the staging area with the most recent version committed into the Git directory

Comparing the version of files in the working directory with those you added to the staging area

Confirming if a specific item is in the .git directory

Opening gitignore’s manual page

Removing files from Git version control and the working directory

Removing files from Git version control only

Renaming a file

How to skip writing a commit message

How to stage and commit at once

How to undo a commit

Undoing the pushing of a commit upstream

Undoing the staging of a specific file in the staging area

Undoing the staging of all files in the staging area

Viewing all the files currently in the staging area and the .git repository

Writing text into a file via the terminal

Dangerous Git Commands

How to amend your last commit

How to forcefully push to a remote repository

How to rebase Git commits

How to modify a previous commit message

How to squash commits

Splitting a previous commit

1. Change pick to edit

2. Reset the commit

3. Stage and commit files

4. Finish the rebase process

Replacing a working directory’s file with the last committed or staged version

Sharing a Git Repository

Cloning a Git Repository

What does the `-A` flag mean when staging files in Git?

What does the `-u` flag mean when staging files in Git?

What does the `.` (dot) option mean when staging files in Git?

What does the `*` (asterisk) option mean when staging files in Git?

2. There are 11 `<type>`s developers often use

Creating a `.gitignore` file

Confirming if a specific item is in the `.git` directory

Viewing all the files currently in the staging area and the `.git` repository