Top 20 GIT Commands to Start With

As you might know, GIT is a distributed-version control system. The engineers use it for tracking changes that have been made in source code during the process of software development. If you are a developer, particularly if you are just getting into the profession, you must learn a few of the more useful GIT commands.

Let’s look at the best GIT bash commands about which you should learn.

For Setting Up the Project: An Explanation of GIT Prompts

Recommended for you: 5 Brilliant Free Apps That Will Help You Learn How to Code.

GIT INIT

Let’s say you’ve just created a project in your favorite IDE, and you need to know about PowerShell GIT prompts. You’ll have to set up a workable GIT repository.

As you do so, you must tell GIT which directory should be utilized and run. The git init feature is how you would do that. GIT will create a hidden. git directory and use it to keep its files organized as other subdirectories.

Here is a list of git init commands for the next popular editors:

CONFIG

After you have created your repository, perhaps you might configure some essential elements in it, like setting up your username. That’s why you’ll need a CONFIG command. Any command of a GIT list is going to include this.

You can set up your username by executing:

git config user.name=<replace_with_your_username>.

This will place the username in the nearby repository. However, note that afterward, if you want to create a second repository, then you will have to set up your user information one more time.

You do not need to do this if you add a global command option. It will globally set your information:

git config --global user.name=<replace_with_your_username>.

You can also use a CONFIG command to configure other aspects. You can place the command within the configuration file.

CLONE

To get a repository on your computer that is remote, you must set up a CLONE command. You do this with your git clone setting and by passing by the URL as a parameter. This command should clone the entire remote repository within your machine. This is another one of the GIT hub commands that will serve you well as a dev.

$ git clone git://git.kernel.org/pub/scm/git/git.git

ALIAS

With an ALIAS command, you can create shortcuts to your favorite commands. It’s a tool that helps you wrap a sequence of commands and save them under a name. This would be considered one of the common GIT commands that you’ll use often as a dev.

You could also add the aliases right in your config file. In that case, the directive in the example will be turned into the following configuration in the global configuration file. For example, you might set up the next shortcuts for the most common commands:

$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status

Commands for Doing and Undoing Changes

STATUS

This is the command that you would use if you wanted to display the state of the staging area and your working configuration. By using it, you’re able to look at what alterations have been staged and which ones haven’t.

ADD

Before you commit your modified or new file, it has to get added to your staging area. Do this by running a git add directive. You must pass the name of the file and directory as a parameter. You can input f_your_file>. At that point, your file will be removed from your “changes to be committed” list.

Adding -p (or —patch) allows you to select parts of each tracked file to commit. Then each commit contains only related changes.

COMMIT

Let’s say that you’ve completed some feature implementation, and you want to save the changes. Look at the “changes to be committed” list. Once that’s done, you’ll know that all of the needed files have been staged. That’s when you can execute git commit.

After you have executed this command, the default editor will open. You should then enter your COMMIT message.

If your message is short, include it in the GIT COMMIT command as follows:

git commit -m “Your_first_commit_message.”

You could also add the -a option. By doing so, you can ensure that GIT will look at your working tree. It will then perform GIT ADD for the new and modified files, as well as git rm for any deleted files before the commit.

Perhaps you forgot to add a file to your commit. You do not want to create another commit command for that file. You can use an amend option instead.

Public commits shouldn’t ever be amended. Remember that your colleagues might have based their work on that commit. You don’t want to confuse them because of any changes they’ve made.

RESET

git reset is another tool that should be handy for you as you’re beginning your work life as a dev. This is a command which helps you reformat changes. There are multiple ways it can be used, but a common example is when you provide a mode and the commit identification as though there were arguments, like this:

git reset <mode> <commit>.

There are multiple reset possibilities. To understand them, you should be aware of the three GIT trees.

STASH

Let’s say that you’ve been working for some time on a certain feature area. You see that there’s a bug that has to be fixed right at that moment. But your feature implementations are still in process and you do not want to inflict any unfinished branch alterations. Your git stash command is what you’ll need.

This method lets you keep your changes in the STASH stack. Afterward, you can make a list of them, along with the git stash list.

There aren’t restrictions for the branch on which you can apply your stash. You can stash the changes in one branch and apply those to a different one when you’d like.

To put stored changes into effect, use your git stash apply directive. It applies the most recent changes stored in the stack. If you wish to apply older changes, then you could specify the name like a git stash apply stash@{1}. This applies to another stash in the stack.

Once you apply a stash by utilizing an apply directive, it will not be removed from that stack. You can view this as a GIT flow command which you’ll be using frequently.

You may like: What’s the Trends About Mobile Application Development In 2020?

REVERT

Maybe you saw fit to push your completed alterations to its original branch and noticed that one of your commits did not need to be on there. Fix it through adding another directive that will get rid of the previous one. The REVERT directive assists you there. You must specify your commit id and undo as a parameter: git revert <commit_id>.

The command will figure out handy info, including the name of the branch, the number of commits that were made after or before it went remote. Also, you can see new and modified files as multiple lists:

Git Commands for Team Efforts

BRANCH

With git branch directives, your system will make use of the list of branches. If you want to look at the remote branches, then the git branch -r is how you do it. If you wish to see local and remote branches, then use git branch -a.

You could delete a branch by using: git branch -d <branch_name>.

Checking Out

This is another regularly used GIT directive. To work in the branch, you must execute a switch. git checkout is how one switches easily from a branch to a different one. You could use it to peruse files, as well as commits. Git checkout <name-of-your-branch> is how it is executed.

Remember the following if you want to switch between branches successfully:

The changes in the current branch can be committed or stashed when you switch

Any branch you check must exist in your local

There’s also a shortcut command which allows you to create and switch to a branch in one time:

git checkout -b <name-of-your-branch>.

This is a command which creates a different directive in your local (-b stands for the branch). It looks over the latest branch directly after it is created.

PULL

With the git pull directive, you do a fresh data download through a remote repository and an integration with the nearest one. When you run this command, you refresh the local branches, along with any alterations from your remote terminal.

There is a default way to integrate the new alterations too. Use a merge. You can change it to rebase if you use the option: git pull –rebase.

It’s recommended to always put changes in a clean nearby repository without uncommitted changes in it.

COMMIT

This is a directive that might “snapshot” or record the file in your version history. You input git commit -m “[ Type in the commit message]” thereby using it.

It’s the command which commits any files you have added, along with the GIT ADD command. It also effectively commits the files that have changed since then.

PUSH

After you have committed any alterations, probably, you want to push to a remote repository. This way, they’re available to your teammates.

If you run GIT PUSH, that will “push” the recent changes of a current area to its remote. If through the creation of a branch locally, you push the whole branch to a remote repository, that’s fine. This directive lets you do that: git push -u origin <replace_with_branch_name>.

This is how you push a branch that has a specified name to the origin repository. The remote branch should use the same name as the local one.

MERGE

We also had to put MERGE on this list of GIT prompts. You’ll wish to integrate the feature branch or fix any bugs on another branch at some point. Merging your branch lets you do that. Running a git merge command is what you’ll need to do.

After running the command, two varieties of the merge can occur the three-way merge, or the fast-forward one.

A fast-forward merge is for when there’s a linear path between the branches you wish to merge. Let’s say you’ve created a bugfix branch from the master. You have fixed the problem, and you’ll want to merge it into a master. However, nobody has done an update of the branch. GIT can merge a branch itself, which will fix the problem.

A three-way merge takes place when there is no linear path between branches. Like with the last example, you devised a bugfix branch from the master version. You corrected the bug, and now you need to merge it with git merge <branch>.

Perhaps you discover that someone updated the master. To connect the branches, GIT must create a new commit where the alterations combine.

That’s when a problem comes about. Both branches have changed the identical code block. GIT can’t mash the alterations together without your help. Accepting one change is the easiest way to do that.

However, you can also combine the changes. When this occurs, GIT modifies the affected files with some visual indicators. This lets you easily locate issues. Some visual markers are used:

<<<<<< — shows the place the conflict began
====== — separates changes from different branches
>>>>>> — shows where the conflict ends

Once you resolve the conflicts and get rid of the markers, the conflicted areas will be added to your staging area with git add.

If an error was made, or you want to go in a different direction, run git merge –abort. By doing so, your branch won’t get modified.

If not, then use git commit commands. It will conclude the merge, creating a new commit.

Another helpful command is the git mergetool command simply launches an external merge helper in case you have issues with a merge in Git.

You may also like: Best Programming Language for iOS App Development.

REBASE

Integrate changes through using REBASE first and then merge. With REBASE, you’re rewriting the program’s backstory. Public commits shouldn’t ever be rebased as, for example, a team member could base their work on them.

Instead of choosing to merge a specific branch into your own, you can rebase your branch onto a specific one. But what is it that’s doing this rebase protocol that you’re using?

What will happen is that changes will get integration from one specific branch into another one. The base of the second branch will be changed from one commit to a different one. It will seem like the second branch was created from the first one. This gives you clear, linear history.

Git rebase <name_of_branch_to_rebase_on> is the way you execute the command.

This is the first or standard mode of the rebase command. Then, there’s the second mode, also called the interactive mode. You can use it to easily modify a sequence of commits before you include them in another branch, otherwise known as the remote one.

After Committing Commands

LOG

This directive is for listing the version history of the current branch. To execute it, input git log –follow[file].

This directive lists a file version history. The renaming of files will be included. git log does print a commit history.

Several options can be used in this scenario. One of them is the git log –stat. For each commit in history, a list of names will be printed. The files which have been removed, modified, or added will be accessible. The line amounts that were removed or added can be seen. You will notice that there is also a summary that you can peruse.

SHOW

The Show prompt that devs use can show details for various objects. When we say “objects,” we are talking about commits or tags. git show can be used to display an older file version. For instance, you could use this command to show a version of a file from two commits ago.

Hopefully, this GIT commands tutorial has helped serve as an introduction to this tool. As a dev, the more you learn about GIT, the better position you will be in to get hired by a team looking for a dependable programmer.

As you get more advanced in this field, you’ll learn more GIT prompts, and your programming will get a lot smoother. You’ll be able to write usable code that can be added to by your teammates.

This article is written by Slava Vaniukov. He is the Co-Founder, and CEO at Softermii, software, and app development agency. He has over 9-years of experience in the web and mobile development industry. Besides that, he is one of the authors for the Softermii blog and tech blogger featured at a wide range of other web resources. You can follow him on LinkedIn.