Git Commands Tutorials and Example: Git Reset – Git Revert

A committed snapshot can be undone with the git reverse command. Rather than removing the commit from the project history, it determines how to reverse the modifications made by the commit and adds a new commit with the resulting content. This prevents Git from losing history, which is critical for maintaining the integrity of your revision history and collaborating with confidence.

Reverting vs. Resetting:-

git revert

Use of Git Reset, Git Revert, Git Checkout & Squash Commit | by Ameet  Prajapati | MindOrks | Medium

It’s crucial to note that git revert just undoes a single commit; it doesn’t “revert” a project to its prior state by deleting all future commits. This is referred to as a reset rather than a revert in Git.

Compared to resetting, reverting offers two significant advantages. It is a “safe” action for commits that have already been published to a shared repository since it does not affect the project history. Please check the git reset page for further information on why changing shared history is harmful.

Second, although git reset can only go backwards from the current commit, git revert can target a specific commit at any time in the history. If you wanted to undo an old commit with git reset, for example, you’d have to erase all commits that came after the target commit, then remove the target commit and re-commit all subsequent commits. Needless to say, this isn’t a really elegant undo method.

git reset

git reset soft: When to Use Git Reset, Git Revert & Git Checkout - DEV  Community

If git revert is the “safe” approach to reverse changes, git reset may be considered the “dangerous” alternative. There is no way to recover the original copy when you undo with git reset (and the commits are no longer referenced by any ref or the reflog). When using this tool, be cautious because it’s one of the few Git commands that might cause you to lose your work.

What are Uses of:-

git reset:-

  • The selected file will be removed from the staging area, but the working directory will remain unaltered. This removes a file off the stage without overwriting any modifications.
  • The staging area should be reset to reflect the most recent commit, but the working directory should remain untouched. This upstages all files without overwriting any modifications, allowing you to re-create the staged snapshot from the ground up.
  • Back up the current branch tip to and reset the staging area to match, but don’t touch the working directory. Since then, all changes have been saved in the working directory, allowing you to re-commit the project history with cleaner, more atomic snapshots.

git reset –hard:-

  • To match the most current commit, reset the staging area and working directory. The –hard flag tells Git to overwrite all changes in the working directory, in addition to upstaging modifications. To put it another way, this deletes any uncommitted modifications, so make sure you truly want to get rid of your local changes before using it.
  • Reset both the staging area and the working directory to reflect the current branch tip’s position. This removes not just the uncommitted modifications, but also all subsequent commits.

Tagged : / / / / / / / /

Top 5 Git Version Control Software in Cloud

Version control is a way to keep track of changes to code so that if something goes wrong, we can compare across different code versions and go back to any previous versions we want. This is very essential where many developers are constantly working on/changing the source code.

Benefits of Version Control Software:

The main advantages of using version control software include streamlining the development process, managing the code for multiple projects, and keeping a history of all changes within a code.

A version control software saves all the changes in a repository. So, if developers make a mistake, they can undo it. Also, they can compare the new code with the previous version to resolve their grievance. It can reduce human errors and unintended consequences to a great extent. Very suitable for any web development company around the world.

In addition, it facilitates the management of the project’s centralized repository, file storage, documents, and other information related to the project.

Here is the list of Top 4 git version control software in cloud:

1. GitHUb

GitHub helps software teams collaborate and maintain a full history of code changes. You can track changes in the code, turn back the clock to undo errors, and share your efforts with other team members.

It is a repository for host Git projects. For those wondering what is Git? It is an open-source version control system with local branching, multiple workflows, and convenient staging areas. Git version control is an easy-to-learn alternative and provides faster operation speeds.


  • Drag and Drop Gist Code.
  • Creating a folder via the Web Interface.
  • Using Github Command Line Interface.
  • Linking Lines.

2. GitLab

GitLab comes with a number of useful features such as an integrated project, a project website, etc. By using GitLab’s continuous integration (CI) capabilities, you can test and distribute code automatically.

You can access all aspects of a project, view the code, receive requests and add conflict resolution.

This version control software is designed for the DevOps lifecycle. Meaning, your projects are quite complex and involve cloud engineering and the like. Gitlab provides basic features such as view code, pull requests, and merge resolution.

  • Development.
  • Security.
  • Ops teams collaborate
  • Build software
  • Reduce development costs

4. Beanstalk

Beanstalk is a perfect choice for those who need to work from remote locations. This software is based on browser and cloud, which allows users to code, commit, review and deploy using the browser.

It allows users to code, commit, review, and deploy code using the browser. For its ease of use, you can integrate it with any messaging or email platform for efficient collaboration.

It can be integrated with messaging and email platforms for efficient collaboration regarding code and updates. It supports both Git and SVN and also comes with built-in analytics features. For security, it takes advantage of encryption, two-factor authentication, and password protection functions.


  • Variety of Application Deployment Options.
  • Wide Selection of Application Platforms.
  • Management and Updates.
  • Customization
  • Scaling
  • Compliance

4. HelixCore

Helix is one of the best version control systems. It provides an integrated platform for collaborative development and protection of intellectual property of any kind. It benefits from several new capabilities, support for both distributed and centralized development workflows. Helix also provides a complete Git ecosystem. And it comes in both on-premises and cloud versions.

Helixcore provides seamless team collaboration and support for both centralized and distributed development workflows. It is available for both cloud and on-premises deployments, which makes it scalable.


  • Work order management
  • Applications Management
  • Document Management
  • Access Controls
  • Procurement Management

5. Apache Subversion

Apache Subversion is another open-source version control system, founded a few decades ago by CollabNet. Both open-source arenas and enterprises consider it a reliable option for valuable data.

SVN is easy to implement with any programming language. Also, it provides persistent storage for handling text and binary files.


  • Inventory management
  • Security management
  • History tracking
  • User access controls
  • Data recovery
  • Workflow management

These are the best version control systems that a web development company should definitely consider using, according to the requirements.

Tagged : / / / / / /

List of Top 5 Git repository management systems in 2021

  1. GitHub.
  2. Bitbucket.
  3. Assembla.
  4. RhodeCode.
  5. DevZing Subversion.


Github is a collaborative coding tool with version control, branching, and merging all included.

GitHub is the best place to share code with friends, co-workers, classmates, and strangers.


Bitbucket is a cloud-based Git and Mercurial-based source code management and collaboration tool.

Bitbucket is a cloud-based hosting service for projects that use either the Mercurial or Git revision control systems.


Enterprise cloud version control for secure source code management in the cloud.

Assembla is the world’s only Enterprise Cloud Version Control (ECVC) provider, bringing multi-repository secure source code management to the cloud.


RhodeCode is a fast and powerful management tool for Mercurial and GITand SVN with a built-in push/pull server, full-text search, pull requests, and code-review system.

RhodeCode is a fast and powerful management tool for Mercurial and GIT and Subversion with a built-in push/pull server, full-text search, pull requests, and powerful code-review system. It works on http/https and has a range of unique features.

DevZing Subversion:-

High-speed, secure, available subversion hosting.

Your code is safe and secure and accessible from anywhere.

All plans support SSL (https) for connecting to your repositories.

Free import from other Subversion systems. Friction-free migration.

Send an email on every commit. Always know who is updating your repositories.

What is git?

Git is software for tracking changes in any set of files, usually used for coordinating work among programmers collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows.

Why do we need git?

Git is the most commonly used version control system. Git tracks the changes you make to files, so you have a record of what has been done, and you can revert to specific versions should you ever need to. Git also makes collaboration easier, allowing changes by multiple people to all to be merged into one source.

What is the role of Git repository managment systems?

  • 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.
  • It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.
  • A Git repository is the . git/ folder inside a project.
  • This repository tracks all changes made to files in your project, building a history over time.
Tagged : / / / / /

Enforce the JIRA issue id in a GIT commit message

Enforce the JIRA issue id in a GIT commit message

This can be done by using git hooks file location at .git/hooks/commit-msg. Following are the 2 way in whcih each Developers can set the Hooks in their developement envioronment.

Method – 1

# This hook will make sure that the commit message contains a JIRA issue.
# To enable this hook, rename this file to ".git/hooks/commit-msg".
# Make sure to add execution permissions to the file.

export MESSAGE=$(<$1)
export JIRA_ISSUE_TAG='ISSUETAG-([0-9]*)'

if [[ $MESSAGE =~ $JIRA_ISSUE_TAG ]]; then
echo -e "\e[32mGreat, your commit message contains a JIRA issue!\e[0m"
exit 0;

echo -e "\e[31mOh hamburgers ... You forgot to add a JIRA issue number!\e[0m";
exit 1;

Method 2 – This is another very good example to implement to force jira id in each commit message.

Tagged : / / / /

Best Branching and Merging strategies in Gerrit

Best Branching and Merging strategies in Gerrit

Step 1 – First Lets read this article about Best Branching and Merging strategies in git

Best Branching and Merging strategies in git

Step 2 – Now Lets learn the Gerrit Merge Types

Step 3 – Time to Learn the Types of Submit in Gerrit

Step 4 – Finally, You must read the recommendations below

Tagged : / / / / /

Best Branching and Merging strategies in git

Best Branching and Merging strategies in git

Step 1 – First you need to learn the needs of branches. This is very good read.


Step 2 – Now time has come to Learn best branching model in Git.


Step 3 – Now, Lets understand, what is the kind of merges we have in Git?


Step 4 – Are you still having a questions, Please post in the comment section.

Tagged : / / / / / / /

How to revert the changes once its submitted in Gerrit

How to revert the changes once its submitted in Gerrit

The Revert button is available if the change has been submitted. This Reverts the change via creating a new one. When the Revert button is pressed, a panel will appear to allow the user to enter a commit message for the reverting change.

Once a revert change is created, the original author and any reviewers of the original change are added as reviewers and a message is posted to the original change linking to the revert.

However, patchsets can not be reverted. so first you have to checkout one of the previous patchset. you can get the command from Gerrit review board at each patchset download panel. After checking it out amend it to generate new commit hash then pushed again as a new patchset.

If I have multiple patch set versions for one change in Gerrit, You can only submit the latest patch set version. The design assumes that the most recent patch set is the one developers will review and test, and as such older patch sets can not be submitted.

Good Read

Tagged : / / / / / /

What is a Change and Patch set in Gerrit?

Here is the short and quick description of Gerrit key teminology.


Every time you push a commit with a new Change-Id Gerrit allocates a new change. Every change has a unique Change-Id and a Change Number. The change contains a number of patch sets, comments on the patch sets and a code review rating (+2, +1, 0, -1, -2). Each change has a dedicated page that shows information about it called individual change page. This includes dependencies between different changes, patch sets and the review comments.


Once a change has received a +2 in the Code Review and no negative voting in the other categories the last patchset can be submitted. This means Gerrit will now try to cherry-pick your patch set and mark the change as merged.

Patch set

If you want to modify your change, you don’t have to push a new change to Gerrit but only a new patch set . Imagine a patch sets as different versions or revisions of a change. Each patch set can receive inline comments. Gerrit uses the Change-Id of a commit message to identify patch sets of a change. This is why all patch sets of a change have the same Change-Id.

To create a new Patch when new changes are submitted
Step 1: Install commit-msg hooks for gerrit

$ scp -p -P 29418 localhost:hooks/commit-msg .git/hooks/



Step 2: Create normal commit and push (for Patchset1)

for example:

git add
git commit -m "server added"
git push origin HEAD:refs/for/master



Step 3: After doing some changes to

Finally to create new Patchset (Patchset 2)

git add
git commit --amend
git push origin HEAD:refs/for/master
Repeat step 3 for further Patches

Understanding the Patch set in Git perspective

Git is a very advanced distributed source code control system. Maintaining patch sets (often called a topic branch) in Git. Git includes a rebase capability that is very useful for a number of different operations related to maintaining a branch of code including moving a branch forward, moving a branch around on an upstream branch to look for breakage, and merging changesets to create patch files.

Git: How to create and apply patches

Creating a patch

Make your changes and commit them.
Run $ git format-patch COMMIT_REFERENCE #to convert all commits since the referenced commit (not including it) into patch files.
$ git format-patch HEAD~~

This will create 2 files, one for each commit since HEAD~~, like these:

Applying patches
You can use git apply some.patch to have the changes from the .patch file applied to your current working directory. They will be unstaged and need to be committed by you.

To apply a patch as a commit (with its commit message), use git am some.patch. \
For all patches to be applied, simply run:
$ git am *.patch

Note that in some previous version you could pass the latest patch filename of a list of patches to apply all previous patches as wel
$ git am 0002-allow-users-to-be-locked.patch # May no longer work for you

You then have the 2 unpushed commits from the patch file created earlier.

Tagged : / / / /

How to update or pull current branch before committing in Git?

Best practice says that before you commit in git, you need to either do git pull or git fetch/merge. However, there is a way to find out wheather your branches is not in sync with remote.

To check the remote repo status you are really simulating a “fetch”
$ git fetch -v –dry-run

To bring your remote refs up to date
$ git remote -v update

This command will print whether the branch you are tracking is ahead, behind or has diverged with remote. If it says nothing, the local and remote are the same.
$ git status -uno

To pull
$ git pull origin <<branchname>>
$ git fetch origin <<branchname>>
$ git merge remote/<<branchname>>
$ git commit

Compare the two branches:
$ git log HEAD..origin/master –oneline

Tagged : / / / / / /

Advantages of Git over SVN and perforce

What are the advantage of GIT over Subversion and perforce?

Code development has its negative and positive sides, but anything that brings more relief and gains time in a project is the developer’s best friend. CVS was for a long time the best solution for version control, adopted by all programmers in major projects. While CVS has slowly evolved into other more successful concurrent version systems like Subversion, the latest trend that manifests across the development world is the usage of DCVSs (distributed version control systems) as the main project tracking managers.

Since its launch in the mid ‘80’s and till 2000, CVS was the only real alternative as a revision control system for programmers. Not a very good one, but better than anything else. Built in 2000 by CollabNet Inc., Subversion was marketed from the start as “a better CVS” and “CVS done right.” It was truly better than CVS; unfortunately, it didn’t bring in that many new features, and under the hood, nothing has changed its core.

Because of that, there was a surge in revision control software development at the start of the 2000’s, which led to the birth and development of many DCVS projects. GNU arch and Monotone where about the first to be launched, followed by Darcs and BitKeeper.

A serious step in DVCS’ development took place after the quarrel between Linux developers and BitKeeper’s management, after BitKeeper accused one of the Linux developers of reverse engineering one of their commercially licensed features. Soon after, Linux programmers led by Linus Torvalds himself released Git as an improved open source solution to BitKeeper’s soft. Besides Git, Mercurial and Bazaar were also very successful alternatives to SVN, sharing many of Git’s features, but lagging in performance.

While SVN (Subversion) was extremely popular at the beginning, it established itself as the premiere solution in code development. Soon after, as DVCSs were developed and released, users migrated to them, abandoning SVN, opting for the more loose and faster solutions.

Nevertheless, old CVS users still tend to linger around SVN due to its familiar interface and old coding habits established over the years. Many of them question to this day Git’s efficiency in quickly putting versions together, while Git supporters, on the other hand, criticize SVN’s stiffness regarding offline work.

In many cases, the debate between Git and SVN supporters usually starts with the following features, or lack.

Git features

Offline work: Git permits any developer to branch a project and store it in a local folder as a standalone repository. After doing all the work offline, the central server or storage unit, they can than simply merge it with the central repository committing all the changes already made. This permits developers that don’t have Internet access all the time to work on a project with ease.

Central project information: Unlike SVN, which uses a .svn folder in each directory, Git uses a central .git folder in the checkout root for all project data and logs. This way, it’s easier to track changes to specific folders, on specific dates or by certain development teams. Thus, project code management is much more simplified. This also allows easy renaming of files or folders, Git automatically transmitting these changes in its history.

Easy branching: Branches and tags are much easier to create and switch in Git.

Merge history: While SVN has a branch merge history, it records all the events as coming from one user (the merger). In case a user has previously worked on a file and has not merged it, if that file is merged by another user, all the changes will be attributed to the user that merged the branch. Git, unlike SVN, can remember file changes beyond a merging point and track every user’s actions beyond project commits. Git also automatically starts the next merge at the last point it recorded.

Disk space: When the Mozilla project was ported from SVN to Mercurial (very similar to Git in performance), disk space usage went down from 12GB to 420MB, 30 times smaller than the original size. Git is supposed to use the same storage algorithms, so file size should be around the same value.

Speed: This is a no-brainer. Because all operations except for push or fetch are performed locally, Git’s speed is overwhelmingly faster than SVN could ever supply.

Better access and administration: SVN relies on an authentication module and access lists to permit users to push and merge branches. Git reduces the time spent for providing commit access to users and just lets the administration team decide what to merge and from whom.

Synchronization: It can occur over various types of media like an SSH channel, over FTP, HTTP, WebDAV, or by emails holding attached patches.

SVN features

GUI: From the beginning, SVN users have been using a GUI when managing their repository. This feature is not found at all in Git, a port for TortoiseSVN still being in the works. Besides the lack of a GUI, Git, coming from a UNIX environment, has a very complicated CLI interface with many options and arguments for its base commands.

Single major repository: Other may say this is not a good thing, but it’s a strictly SVN-specific feature. While Git allows each individual user to copy the entire repository on their computer and work on the project’s code, Subversion has always relied on permissions being given to users to only work on one single repository stored online. This feature allows the developer to always be able to download the latest version of their project without having to wait for all that work on the project to log online, upload and merge their latest branch. This is very useful in fast development environments or application troubleshooting.

Partial checkouts: Git doesn’t offer the possibility to download only a single folder from the repository. This may be a disadvantage to developers not having great bandwidth or speed.

Version numbers: Another keeper from the UNIX fathers of Git is the complicated version control numbers. While SVN uses a simple incremented decimal system, Git employs an SHA1 algorithm to output a 40-character hexadecimal string as the version number. This could get very tiring when having hundreds or more versions.

The abovementioned features are only a scratch on the surface when discussing about the version control system war between CVS/SVN supporters and DVCS users. More on the topic can be read here, which puts all the major platforms’ features next to one another so they can be compared.

Let’s now take a look at the parties involved and analyze their impact on the current programming and development world.

Subversion, as of 2009, was recently included in the Apache Incubator project, mainly because of its long usage history in most of the Apache Foundation’s projects. More details are available in one of my past articles on this topic. Other famous open source or commercial projects that have a weakness for SVN include market players like Ruby, Mono, Free Pascal, ExtJS, Tigris, PHP, MediaWiki, GCC, Django and FreeBSD. All having their source code administrated from an SVN repository.

On the other hand, the community’s favorite project, Git, is currently expanding its horizon every day, recently taking GNOME and The Perl Foundation away from SVN, placing them alongside other notable Git-powered projects like Android, Linux, openSUSE, Yahoo User Interface, x264, Digg, jQuery,, Samba, Ruby on Rails, CakePHP, Fedora, Merb, Freenet, GIMP, Parrot, Qt, rsync, Wine and VLC.

Other Git-like products like Mercurial (originally designed to replace BitKeeper for Linux development) have also been adopted by major corporations and programs like Mozilla, OpenJDK, OpenSolaris, Netbeans, OpenOffice, Vim, SAGE, Growl, Wget, Symbian OS and Adblock Plus. In 2010, The Python Foundation is going to join this list, migrating from SVN.

Another Git-like DVCS platform, generally regarded by the community as being slower than Git, but much easier to learn is Bazaar. This is a product developed especially for Ubuntu, but which saw adoption in many other projects around the web, some of them like Squid, APT, MySQL, GNU Emacs, Gnash and Inkscape.

The trend is easy to see. DVCSs are adopted in more and more projects, while SVN is headed for the history books alongside its precursor, CVS. The final battle in this version control systems war is being waged on the grounds of project storing platforms the likes of SourceForge, Google Code or CodePlex. The winner of this confrontation will surely decide whether SVN will be used in the coming future or whether it will fade away from our minds like the early PC consoles.

Currently, SourceForge and GNU Savannah have the biggest and widest hosting platforms, providing version control platforms like CVS, SVN, Git, Bazaar and Mercurial to all of their users free of charge. For SourceForge, by default, a project will be hosted on Subversion. The same happens in Google Code, where SVN is the default, but the Mountain View-based crew also provides Mercurial as a DVCS alternative. Renowned hosting platform, CodePlex, provides SVN, Mercurial and Microsoft TFS hosting, while the smaller service on Project Kenai offers SVN, Git and Mercurial.

Also lately, due to high technical costs, services are starting to opt only for one version control system, putting some heat in the discussions between the CVS communities. The list is as follows: Mercurial has exclusivity on Bitbucket, Bazaar on Launchpad; Git on Github, Codaset and Gitorious, and SVN on BountySource, Freepository, GridyZone and Origo. A slim crop for SVN, but being the default service on Google Code and SourceForge might give it a fighting chance against the up-and-coming Github.

Some of you might not agree with the previous claim that this is a “battle” and should not be at all compared with the browser wars, but the community deeply rooted in the tech world already knows this is more of a fact than a myth. As proof of concept, we bring you this video from a conference at Google back in 2007, where Linus Torvalds, the inventor of Linux and Git, made some outrageous statements regarding SVN, and especially its users.

If you don’t have the time to view this one-hour long video, we’ve listened to the conference and taken some interesting quotes from Mr. Torvalds: “Subversion has been the most pointless project ever started,” continuing with “Subversion used to say CVS done right: with that slogan there is nowhere you can go. There is no way to do CVS right” and ending with “If you like using CVS, you should be in some kind of mental institution or somewhere else.”

Not very heart-warming comments from a public person like Linus Torvalds. Especially being made in the headquarters of one of the companies that have ignored Git and failed to include it in the Google Code project. Nevertheless, Mr. Torvalds might also be under the influence of an inner demon, specific to most UNIX users to prove that any project developed and coming from a Linux environment is better than anything else.

True or not, Git has seen a rise in usage, as proved by the 2008 and 2009 surveys, which had it ranked above any other versioning control platform like SVN, Bazaar and Mercurial, and with a crushing 94.6% rate of overall satisfaction toward the Git user experience. As a conclusion, it is generally acknowledged that future versions of Git will be adopted in more and more environments, and Git will have to fight only against other DVCSs for supremacy in the programming world.

One more good link for Advantahe of git over SVN(Subversion) …

Tagged : / / / / / / / / /