Advanced Git Tutorial

Deploying your project via a remote repository lets you flexibly manage every bit of it. Bug fixes, feature updates, file deletion, teamwork, open-source contributions, code deployment, and more are now at your fingertips with a strong knowledge of Git.

So, you’ve been using Git but want to know more? Here are some more advanced Git tips that’ll make your project version control a breeze.

Git Branch

A Git branch prevents you from pushing directly to the master branch. It’s helpful if you manage a project with a team of developers. You can create as many Git branches as you want and then merge them to the master branch later.

Create a Git Branch

To create a Git branch, use:

git branch branch_name

Switch to a Git Branch

Use checkout to switch to a Git branch:

git checkout branch_name

After switching to a branch, you can stage your changes using git add –all. Then commit them using the git commit -m “commit name” command.

Compare a Branch With Master

Use the git diff command:

git diff master..branch_name

To compare specific files:

git diff master..testb -- main.html

Comparing two branches is similar to how you compare a branch with the master:

git diff branch1..branch2

To see the differences in a specific file between two branches:

git diff branch1..branch2 -- main.html

Push Changes to a Remote Branch

You might want another developer to look at the changes you’ve made to a file in your local branch before pushing them live. A good practice is to shove your local Git branch to a remote replica so they can have a look.

Let’s assume that you’ve previously created a local branch named changes. You can switch to that local branch, adjust all the files you want, then stage and commit them to that branch.

You can then push those changes to the remote version of the branch:

git push origin changes

Merge Remote Branch With Master Using Pull Request

So another programmer has audited the changes in the remote branch (changes). But you want to merge it with the master branch and push it live.

Remember that your remote branch inherits the name of your local Git branch (changes). Here’s how to merge the changes:

Switch to the master branch:

git checkout master

Pull the origin or HEAD of the branch (changes) to merge it with the master branch:

git pull origin changes

Push this merge live to the master branch:

git push origin master

Use Git Merge Instead

To merge a branch with the master using the merge command:

Migrate to the master branch:

git checkout master

Merge it with the branch (changes):

git merge changes

Then push the merge live to the master branch:

git push origin master

Ensure that you replace changes with the name of your branch.

Once a merge is successful, you can then delete the branch locally and remotely if you don’t need it anymore:

Related: How to Rename a Branch in Git

Git Rebase

If you have multiple branches with outdated commits, you can rebase or refocus the head/refs of those branches to inherit the head/refs of an updated one.

Rebasing, therefore, comes in handy when you need to update some branches with the base of a current one.

Rebasing shouldn’t be a frequent action, though, especially if you’re working with a team as it can disrupt the entire workflow. But if you work alone and you’re familiar with your workflow and branches, rebasing shouldn’t wreak havoc if you know where and how to use it.

For instance, assume that you have two branches; branch1 and branch2. Now, you’ve not made any changes to branch1 for some time. But you consistently commit changes to branch2, including recently.

So you decided to carry branch1 along with the flow. Rebasing branch1 to branch2, therefore, means you’re telling branch1 to ignore its previous commits and inherit the recent commit made to branch2.

Here’s how you can do that:

Switch to the abandoned branch (branch1):

git checkout branch1

Then rebase branch1 to the updated branch2:

git rebase branch2

Git Squash

Git squash lets you merge multiple commits into one. It helps when you run git commit many times on a single update. A practical example is when each bug fix or code refactor for a single feature has a separate commit.

But you might not want to push the HEAD commit with the accompanying ones as they all have the same purpose. A recommended approach is to squash them into one to avoid confusion when tracking commits.

The best way to squash commits is via the interactive rebase mode. Take a look at the example below to understand this better.

In this example, assume that you have five bug fixes. And there’s a commit for each of them. Here’s how you can squash these five commits into one:

Run git reflog to view the hash code of your commits:

git reflog

Here’s the result in this case:

Now your aim is to squash the last five commits, starting with first fix up to fifth fix.

To do that, copy the hash code of the commit just below first fix (0a83962). Then press Q to quit the reflog.

Now run git rebase –interactive on that hash.

git rebase --interactive 0a83962

Git then opens an interactive rebase file that looks like this:

To squash the commits, excluding the first fix, replace pick with s for each of the other commits:

Save and close this file.

Another file then opens for you to rename the squashed commit:

Clean those and type in a preferred name for the squashed commit:

Save that file. Then close it and you should receive a success message in your terminal.

Note: The interactive file may open within the terminal. But if you’re on Windows, you might want to force your terminal to globally open files to your favorite text editor to make the squashing easy.

To do that, open your command line and run:

git config --global core.editor "'path to choice text editor' -n -w"

Git Fork vs. Git Clone

Forking and cloning are two different terms in Git. You can’t fork your repository as it’s there with you already. You can, however, fork other people’s repository and clone it afterward.

Forking a repository means you’re grabbing a copy of someone’s repository and making it yours. Once you get a copy of that repository, you can then clone it like you would any of your git repositories for local changes.

Here’s how to clone a remote repository on GitHub and initiate a download to your local directory:

git clone

Restore a File to Its Default State

If you want to clear the changes in a file after the last commit, you can use the git restore command:

git restore filename

Amend a Commit

You can fall back to a previous commit if you forget to make changes to some files while staging them.

Make changes to the file you forgot. Then use git amend to review a commit:

git add file_forgotten
git commit --amend

Unstage Files

You can remove specific files that you’ve staged for a commit using git rm command:

git rm --cached filename

You can also remove several files at once:

git rm --cached file1 file2 file3 file4

Remember to append the relevant file extension to any file you’re exempting. For instance, a plain text file should be filename.txt.

Related: How to Clean Git and Remove Untracked Files

Git Reset

Using git reset is helpful if you want to drop all the files that you’ve staged for a commit at once:

git reset

Git reset HEAD, however, points the HEAD of a branch to a specific commit in your working tree. For instance, if you’ve not yet pushed your current commit, you can fall back to the recently pushed commit:

git reset --soft HEAD~1

Replace –soft with –hard if you’ve pushed the current commit already:

git reset --hard HEAD~1

Git Revert

Unlike the reset command, git revert maintains the integrity of your commit history. It’s handy if you want to amend a commit due to errors or bugs.

It doesn’t abandon the target commit or make a new one. Instead, it reverts to the recent changes you make without deleting or renaming such a commit. It’s a great way to keep your commits cleaner, plus it’s safer than resetting all the time.

To revert to a commit:

git revert HEAD~1

Where HEAD~1 points to a specific commit in your working tree.

Delete a Tracked File or a Directory

You can use git rm -f to delete any tracked files in your working tree. Note, however, that Git can’t remove untracked files, as it doesn’t cache them.

To delete a staged file:

git rm -f filename

To remove a staged folder:

git rm -r -f foldername

Git Logging

To view your commit logs and history in Git:

git log

To log the activities in a specific branch:

git log branch_name

Related: How to Inspect a Project’s History With git log

Sometimes you might want to revert to an abandoned commit. So to view abandoned commits, including the relevant ones:

git reflog

To view ref logs for a particular branch:

git reflog branch_name

Manage Your Project Versions Like a Pro With Git

With Git offering many advantages, you can manage your project releases remotely without burgling files and folders on-premise in your main branch. Additionally, it lets you run projects easily with a team.

As you’ve seen, Git has many features that you can explore. But be careful to use these features purposefully. Otherwise, you might end up breaking things. That said, you can still spin up a demo remote repository and play around with these features.

Author: Idowu Omisola

Source: Idowu Omisola.” Advanced Git Tutorial”. Retrieved From

All Rights Of This Article Reserved To MakeUseOf

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: