One place for hosting & domains

      How to Revert the Last Git Commit


      Git is a widely used Version Control System (VCS) known for its versatility. Git utilizes local clones of central repositories to bring more effective collaboration. It also keeps track of all the committed changes along the way, so things are readily recoverable.

      You might need that recoverability after an inadvertent commit, or to undo the most recent commit for any reason. Git has the ability to revert the last commit, and this tutorial shows you exactly how. It covers methods using both the revert and reset commands, and explains the differences.

      Learn more about Git generally in our guide
      Git vs SVN: Pros and Cons of Each Version Control System.

      For a more general, and thorough, coverage of reverting Git commits, take a look at our guide on
      How to Undo a Git Commit.

      Before You Begin

      This guide gives example output for the commands it describes. To get the best effect, you can follow along using a similar Git repository.

      These next few steps set you up with an example Git repository similar to the one used for the examples in this tutorial. The commit IDs may be different, but the contents of the repository should otherwise be the same.

      The steps presume you have already installed Git and done basic configuration (e.g. user email address and name). If you have not done this yet, you can learn how in our guide
      How to Install Git and Clone a GitHub Repository.

      1. Create a new directory for your Git repository, and change into that directory. Here, the new directory, git-example is created in the current user’s home directory:

        mkdir ~/git-example
        cd ~/git-example
        

        From here on, you should execute the given commands while working in this directory.

      2. Initialize the new Git repository:

        git init
        
      3. Use the touch command to create some new empty files:

        touch example-file-1.txt
        touch example-file-2.txt
        
      4. Add the files to the Git staging area, then commit the staged changes:

        git add .
        git commit -m "Initialized repo."
        
      5. Make some changes to the first file, adding some content to it. Then stage and commit those changes:

        echo "Some example text for the first file." >> example-file-1.txt
        git add example-file-1.txt
        git commit -m "Added text to first file."
        
      6. Do the same for the second file:

        echo "Some example text for the second file." >> example-file-2.txt
        git add example-file-2.txt
        git commit -m "Added text to second file."
        
      7. You now have a Git repository with a couple of files and several commits, which you can see listed with:

        git log --oneline
        
        f4391b2 (HEAD -> master) Added text to second file.
        e3c534a Added text to first file.
        0b24777 Initialized repo.

      How to Use revert on the Last Git Commit

      Git’s revert command undoes a commit by comparing the changes made in that commit to the repository’s previous state. The command then creates a new commit that reverts the changes.

      Thus, to use revert to undo the last commit, you first need the ID for that commit. You can get this with the log command. Here, the command is used with the --oneline option to make each commit display on a single line:

      git log --oneline
      
      f4391b2 (HEAD -> master) Added text to second file.
      e3c534a Added text to first file.
      0b24777 Initialized repo.

      The line at the top of the screen, with an ID of f4391b2 in this example, represents the last commit.

      From there, you can revert that commit using the revert command with that commit’s ID, as in:

      git revert f4391b2
      

      Git starts a new commit to revert the changes. It may present you with a text editor allowing you to edit the description for the new commit. When you are satisfied with the description, exit the text editor to complete the reversion.

      [master e86542a] Revert "Added text to second file."
       1 file changed, 1 deletion(-)

      Use the log command again, and you can see that there is now a new commit to revert the previous commit:

      git log --oneline
      
      e86542a (HEAD -> master) Revert "Added text to second file."
      f4391b2 Added text to second file.
      e3c534a Added text to first file.
      0b24777 Initialized repo.

      You can even check the modified file to see that the changes have been reversed. In this case, that is example-file-2.txt:

      cat example-file-2.txt
      

      How to Use reset to Undo Git Commits

      Git’s reset command can also be used to revert the last commit. The command is more radical than revert and works by removing commits entirely from the repository’s commit history. Essentially, reset “rewinds” you to a previous commit, eliminating later commits and history along the way.

      With the reset command, you have access to the HEAD~1 alias. This alias stands in for the ID of the previous commit, providing easy access when trying to revert to the last commit.

      The reset command comes with three flags that define how the command deals with changed files in the working directory and staging area.

      • Use the --soft option to roll back to a previous commit, while preserving file changes in the working directory and staging area.

        git reset --soft HEAD~1
        
      • Use the --hard option to likewise roll back to a previous commit. However, this option results in all file changes being reverted as well. Changes to files in the working directory as well as staged changes are both discarded.

        git reset --hard HEAD~1
        
      • Use the --mixed option to, again, roll back to a previous commit. Here, a middle ground is adopted for file changes. As with the --hard option, changes made to files in the working directory are discarded. However, like the --soft option, staged changes are preserved.

        git reset --mixed HEAD~1
        

      After any of the above reset commands, you can see that the last commit has been removed from the Git commit history:

      git log --oneline
      
      e3c534a (HEAD -> master) Added text to first file.
      0b24777 Initialized repo.

      The difference is that, if you ran the --soft option with the command, you can still find the changes to the file in the working directory. For this example, that is the example-file-2.txt file:

      cat example-file-2.txt
      
      Some example text for the second file.

      reset vs revert

      The main difference between the revert and reset commands is the commit history.

      The revert command aims to maintain a full commit history, undoing a commit by assessing changes and making a new commit that reverses them. This actually means that the revert command adds to the commit history. It gives you full transparency to past commits and their reversions.

      The reset command, on the other hand, discards commits even from the commit history, making them impossible to recover later. And reset can even do the same for local file changes. This option keeps you from seeing reversions and the original commits that are reverted.

      Generally, it is recommended that you use revert for backing out a commit. It keeps a record of the removed commit and leaves the possibility of assessing and accessing the commit history later.

      By contrast, the reset command should be used sparingly. Take a good look at the situation to ensure that it cannot be remedied by the revert command before you make the decision to apply reset. The reset option might be preferred, however, for immediately undoing mistaken commits, when there is less chance that you need options for recovering the changes.

      Conclusion

      That covers all you need to revert recent Git commits. Moreover, the techniques covered in this tutorial can also help you manage Git commits more generally. The revert command can be useful for precisely removing past commits while retaining your commit history. The reset command, on the other hand, provides a more radical option, completely reverting a repository to a previous commit, including the commit history.

      To keep learning, refer to the links at the beginning of this guide. These give you more on Git generally as well as more on the commands covered in this tutorial.

      You may also want to look at our entire lineup of
      guides on version control. These cover everything from the fundamentals to particular use cases, and provide steps to deepen your version control knowledge.

      More Information

      You may wish to consult the following resources for additional information
      on this topic. While these are provided in the hope that they will be
      useful, please note that we cannot vouch for the accuracy or timeliness of
      externally hosted materials.



      Source link

      How to Undo a Commit in Git


      Git is one of the most common and versatile version control systems (VCS), but it is not always simple and easy to use. You can run into trouble when you commit an undesirable change to a repository. There are several different strategies you can follow to restore your repository. This guide discusses how to undo a git commit and explains the advantages and any drawbacks to each approach.

      Important Git Background for Undoing a Local Commit

      Version control software allows users to manage and track changes to computer source code, documentation, web sites, and other systems. Git is an industry-standard, open-source VCS that uses a distributed architecture. Every Git project is represented by a repository. A repository stores all information about the project, including the source files and change history. The history is stored as metadata information, including the time stamp, comments, and the person who made the change.

      The entire project team contributes to a shared repository, known as the remote repository. However, each developer maintains their own repository containing the local changes they are working on. Git is known for its optimized performance, integrated security features, flexibility, and efficiency. Some Git commands are very powerful and can handle difficult tasks including stream splits and merges. Unfortunately, Git can also be complex and difficult to learn.

      Updates can be propagated between the branches through a series of Git commands. Before anyone can use Git to undo a local commit, they must first be clear about how Git normally works. There are three different locations for files.

      • The working directory: This is an area where users can make any changes they want to their files with no restrictions. They can create new files or modify new ones, test their changes, and delete anything they do not want.
      • The staging area, or Git index: Users must add new files or changed files to this area before they can perform a commit. It is an intermediate area between the working directory and the local repository.
      • The local repository: Users commit the changes in the staging area to this repository. Each commit represents a snapshot of the project at a particular point in time. From here, files can be pushed to a remote repository.

      The git add command is used to move changes to the working files, along with any new files, to the staging area. At this point, the working directory and the staging area are in sync, but the changes are still not in the local repository. When the changes are complete, developers can use git commit to move their changes to their repository. Each commit tracks the new changes, and ensures the current snapshot is available in the future. A commit represents the repository at the time it was made. However, it does not move the changes to the shared repository yet.

      Changes to the local repository are not automatically propagated to any remote repository. Developers can potentially port their changes to the remote repository using git push. This allows other users to view and incorporate the commit. Changes must always be committed before they can be pushed. An organization might institute additional requirements before git push is run, such as code reviews or automated testing.

      When users have only made changes to their working directory, nothing is recorded in the history. No additional steps have to be taken to undo anything. Even when files have been added to the staging area, there are still several options to roll back the changes. However, after the changes are committed to the repository, certain git commands must be used to undo the changes. If the commit has already been pushed to a remote repository, there is only one acceptable git command to undo it.

      Users can view the change logs for any file in a repository using some variation of the git log command. Each commit is identified through a unique 40-character string. This string is equivalent to the SHA-1 checksum for the commit. The current version of a file is known as the HEAD commit. When applied to a branch, HEAD indicates the current version of the branch as reflected in the local repository. For more information on Git, see the
      Git website.

      How to Undo a Git Commit

      There are several ways to use git to undo a local commit. The right choice depends on the following factors:

      • The changes might be required in the future. Some options preserve the commit while others completely erase it.
      • A clean commit log is considered advantageous.
      • The changes have been committed to the remote repository or not. If someone has pushed the changes already using git push, there are fewer options available.

      The most common methods of using git to remove the last commit are git revert or some variant of git reset. However, an organization might have standard best practices regarding what command should be used. More detailed information about all these commands can be found in the
      Git documentation.

      Reviewing Previous Commits Using Git Log

      Before undoing any commits in Git, familiarize yourself with the change history of any relevant files. The git log <filename> command displays the entire history of filename, but git log --oneline is usually more readable and useful. It displays the commit identifier and the comments for each commit together on a single line. The following command displays all previous commits to testfile1.txt and identifies the HEAD version of the file.

      git log --oneline testfile1.txt
      
      6f819a796 (HEAD -> git-test) Second revision of file
      705dfa037 Initial draft of file

      Undoing a Git Commit Using a Soft Reset

      The git reset command is a handy way to undo recent changes and restore files to an earlier version. The reset command can be used for a hard reset, a soft reset, or a mixed reset which falls somewhat in the middle. Many experts advise against using git reset as it throws away the changes, but in many cases this is not a problem.

      The git reset --soft <version> command resets the HEAD commit on a local branch to the previous commit. The specified version becomes the current commit and the HEAD version in the log. More recent commits are discarded, along with their history. However, this command preserves all changes in the working directory and the staging area. The changes can be subsequently committed when they are ready. Although the command is typically used to rewind to the previous commit, an earlier version can be specified. So git reset --soft HEAD~3 restores the HEAD of the local repository to the third-most recent commit.

      A soft reset is the best choice for unwinding accidental commits. A good example is when a file is committed before all testing is complete or if some files are unintentionally omitted. A new version can be committed later when all changes are complete. This updates the repository and history with the correct commit.

      If the changes have already been pushed to the remote repository, this approach is not suitable. git reset does not update the remote file, so the local workspace is now out of sync. The next time files are fetched, the unwanted commit is erroneously restored.

      The following example demonstrates how a soft reset might be used on testfile1.txt.

      1. Review the file contents before the soft reset.

        File: testfile1.txt
        1
        2
        3
        4
        
        First line of text.
        Second line of text for check-in 2.
        Third line of text for check-in 3.
            
      2. Verify the Git log for the file. It displays three commits.

        git log --oneline testfile1.txt
        
        73536b193 (HEAD -> git-test) Third revision of file
        6f819a796 Second revision of file
        705dfa037 Initial draft of file
      3. Execute a soft reset using the commit that immediately preceded the current version. This version is HEAD~1, which is an alias for the second most recent commit.

        git reset --soft HEAD~1
        

        Note

        It is possible to undo multiple commits. Use either the commit identifier or the HEAD~n notation to identify the commit.

      4. The log now reflects the results of the reset operation. The earlier version has become the current version. This version is now the HEAD.

        git log --oneline testfile1.txt
        
        6f819a796 (HEAD -> git-test) Second revision of file
        705dfa037 Initial draft of file
      5. Verify the state of the file using git status. The output confirms the changes are still staged and ready for another commit.

         git status testfile1.txt
        
        Changes to be committed:
          (use "git restore --staged <file>..." to unstage)
            modified:   testfile1.txt
      6. The contents of the local directory are also unchanged.

        cat testfile1.txt
        
        File: testfile1.txt
        1
        2
        3
        4
        
        First line of text.
        Second line of text for check-in 2.
        Third line of text for check-in 3.
            

      Undoing a Git Commit Using a Hard Reset

      The git reset option also has a --hard option. git reset --hard <version> also rewinds the HEAD version to the specified version the same way a soft reset does. The earlier commits are still removed from the log and the local repository. However, in a hard reset the changes are also removed from both the working directory and the Git index. This means any changes made to the file after the target version are lost.

      This command should be used whenever the recent commit is incorrect, not simply incomplete or too early. It is the right choice to permanently undo changes that are not intended for a future commit. As with a soft reset, this approach is not suitable for a file that has been pushed to a remote repository.

      The following example demonstrates how a hard reset results in a different outcome than a soft reset.

      1. Before the reset operation, the log of the current file displays three commits.

        git log --oneline testfile1.txt
        
        3aa5652f2 (HEAD -> git-test) Third revision of file. Take 2
        6f819a796 Second revision of file
        705dfa037 Initial draft of file
      2. The working copy of the file displays the text from the recent commit.

        File: testfile1.txt
        1
        2
        3
        4
        
        First line of text.
        Second line of text for check-in 2.
        Third line of text for check-in 3.
            
      3. To undo the changes, perform a hard reset using the --hard option. Specify HEAD~1 to revert to the commit preceding the current commit. If the reset is successful, Git displays information about the current version.

        git reset --hard HEAD~1
        
        HEAD is now at 6f819a796 Second revision of file
      4. View the log to confirm the older commit is now the current version. Information about the third commit has disappeared.

        git log --oneline testfile1.txt
        
        6f819a796 (HEAD -> git-test) Second revision of file
        705dfa037 Initial draft of file
      5. This time, the commit no longer appears in the git index.

        git status git testfile1.txt
        
        On branch git-test
        nothing to commit, working tree clean
      6. The commit has also been undone in the working file. It reflects the contents of the HEAD~1 commit.

        cat testfile1.txt
        
        File: testfile1.txt
        1
        2
        3
        
        First line of text.
        Second line of text for check-in 2.
            

      Undoing a Git Commit Using a Mixed Reset

      The command git reset --mixed <version> performs a mixed reset. In addition to rolling the local repository back to the specified version, it removes changes associated with the commit from the staging area. This is equivalent to undoing both the git add and git commit commands on the file. However, it is similar to the soft reset because it does not remove the changes from the working directory. This makes it easier to add back the changes and commit them again in the future. The mixed mode is the default setting for a reset if no options are specified.

      A mixed reset is typically used to undo a commit that still requires some minor adjustments. When the file is corrected, it can be added and committed again. It can also be used to remove a new file that was not yet ready from the staging area. If there is no chance of the changes ever being needed again, a hard reset should be used.

      The following example demonstrates how a mixed reset differs from the other two approaches.

      1. At first, the contents of the file reflect the contents of the three commits.

        cat testfile1.txt
        
        File: testfile1.txt
        1
        2
        3
        4
        
        First line of text.
        Second line of text for check-in 2.
        Third attempt at line 3.
            
      2. Run the git log command to see the commit history.

        git log --oneline testfile1.txt
        
        cbe82f1a6 (HEAD -> git-test) Third revision of file. Take 3
        6f819a796 Second revision of file
        705dfa037 Initial draft of file
      3. Undo the changes using the git reset --mixed command. Identify the version to roll back to. In this case, it is HEAD~1.

        git reset --mixed HEAD~1
        
        Unstaged changes after reset:
        M	docs/guides/development/tips-and-tricks/testfile1.txt
      4. The output from git log confirms the most recent commit has been undone.

        git log --oneline testfile1.txt
        
        6f819a796 (HEAD -> git-test) Second revision of file
        705dfa037 Initial draft of file
      5. The commit is no longer staged.

        git status testfile1.txt
        
        On branch git-test
        Changes not staged for commit:
          (use "git add <file>..." to update what will be committed)
          (use "git restore <file>..." to discard changes in working directory)
            modified:  testfile1.txt
      6. However, all changes remain in the working directory. The contents of testfile1.txt are unchanged.

        cat testfile1.txt
        
        File: testfile1.txt
        1
        2
        3
        4
        
        First line of text.
        Second line of text for check-in 2.
        Third attempt at line 3.
            

      Note

      git reset can be used on a specific file to move a particular commit to the staging area. The syntax for this command is git reset HEAD <filename>. Although it can be used with any version from the repository, it is typically used with the HEAD version. In this case, it has the effect of aligning the local repository and the staging area. This is an efficient method of undoing uncommitted changes to the staging area. Subsequent changes must be staged again using git add before they can be committed.

      Undoing Git Changes Using Git Revert

      git revert is used to completely revert a commit without deleting it. Many experienced Git users prefer this approach over a reset. The main difference is a revert undoes the changes using a new commit. It compares the commit with the version that precedes it to determine the necessary changes. It also adds a new entry in the commit log to document the reversion.

      A revert does not throw away or overwrite any earlier commits. While git reset removes all records of the undesirable commit, git revert generates an entirely new commit to accomplish the same undo operation. The HEAD of the file is set to the new version that inverts the changes. This version of the file becomes the current version. In all cases, specify the commit to undo as an argument. To roll back the most recent commit, use git revert HEAD. This command rolls back the entire commit at once, so several files can be affected at the same time.

      The main advantage of git revert is it maintains the history of all commits. This is handy for debugging and quality control purposes. It is also the best approach if the commit has already been pushed to the remote repository. It allows the revert operation to be pushed to the shared repository and undoes the change there too. This approach is the easiest and cleanest way to fix a broken build and is always safe to use. Many organizations only allow changes to be backed out using this method.

      To use Git to revert a commit, follow these steps.

      1. Verify the file history and contents to determine the change to revert.

        git log --oneline testfile1.txt
        
        34722a3fd (HEAD -> git-test) Third revision of file. Take 4
        6f819a796 Second revision of file
        705dfa037 Initial draft of file
        cat testfile1.txt
        
        File: testfile1.txt
        1
        2
        3
        4
        
        First line of text.
        Second line of text for check-in 2.
        Third attempt at line 3.
            
      2. Apply git revert to the last commit. HEAD is an alias for the more recent commit.

        git revert HEAD
        
        [git-test 606638205] Revert "Third revision of file. Take 4"
         1 file changed, 1 deletion(-)
      3. The log reflects a new commit which inverts the third commit. This restores the contents of the file to the second revision. Commits 606638205 and 6f819a796 are exactly the same.

        git log --oneline testfile1.txt
        
        606638205 (HEAD -> git-test) Revert "Third revision of file. Take 4"
        34722a3fd Third revision of file. Take 4
        6f819a796 Second revision of file
        705dfa037 Initial draft of file
      4. All changes are removed from the staging directory.

        git status testfile1.txt
        
        On branch git-test
        nothing to commit, working tree clean
      5. The contents of the working copy also change. They reflect the current version of the file in the local repository.

        cat testfile1.txt
        
        File: testfile1.txt
        1
        2
        3
        
        First line of text.
        Second line of text for check-in 2.
            

      Using Git Checkout

      The git checkout command is typically used to switch to another branch. However, it can also be used to view earlier commits to a file. Later on, the user can restore the current version of the file using another git checkout.

      When used with a specific commit identifier, git checkout <commit_id> allows developers to checkout and view a specific snapshot of the file. The checked out version is technically independent of any branch and exists in a branchless state. HEAD now points to this version, but another newer commit is still the current version for the branch. This creates what is known as a detached head condition, which is something to be concerned about. If any further commits or changes are made to this file, they are detached from the current state of the branch. Any subsequent checkout results in these changes becoming orphaned and unusable. So this approach is of limited use for rolling back a recent commit.

      However, it is possible to directly create a new branch based on the earlier commit. While this older commit is still checked out, create the new branch using git checkout -b <new-branch-name>. The older version of the file automatically serves as the base for the new stream. This allows new development to use an older version of the repository as a starting point.

      The checkout command overwrites any local changes. To save local changes, ensure the file is backed up or stashed before proceeding with the checkout.

      Note

      When used on a branch, git checkout checks out the current contents of a branch on the local system. All subsequent commits are made against this branch. This is the main method of switching between branches in a repository. There is no concern about orphaned commits or a detached HEAD in this case, because HEAD still represents the current version.

      To use git checkout, follow these steps.

      1. Review the file history using git log. Locate the version to review.

        git log --oneline testfile1.txt
        
        e3d35e244 (HEAD -> git-test) Third revision of file. Take 5
        606638205 Revert "Third revision of file. Take 4"
        34722a3fd Third revision of file. Take 4
        6f819a796 Second revision of file
        705dfa037 Initial draft of file
      2. Use git checkout to view the contents of commit 606638205. Git confirms the checkout and warns the user they are in a detached HEAD state. It also displays a warning about the checkout and explains how to undo the git checkout operation.

        git checkout 606638205
        
        Note: switching to '606638205'.
        
        You are in 'detached HEAD' state. You can look around, make experimental
        changes and commit them, and you can discard any commits you make in this
        state without impacting any branches by switching back to a branch.
        
        If you want to create a new branch to retain commits you create, you may
        do so (now or later) by using -c with the switch command. Example:
        
          git switch -c <new-branch-name>
        
        Or undo this operation with:
        
          git switch -
        
        HEAD is now at 606638205 Revert "Third revision of file. Take 4"
      3. Verify the status of the file and ensure it displays the detached head state. It does not belong to any branch.

        git status testfile1.txt
        
        HEAD detached at 606638205
        nothing to commit, working tree clean
      4. The contents of the file reflect the checked out version.

        cat testfile1.txt
        
        File: testfile1.txt
        1
        2
        3
        
        First line of text.
        Second line of text for check-in 2.
            
      5. The log has changed and now tags the earlier version as the head.

        git log --oneline testfile1.txt
        
        606638205 (HEAD) Revert "Third revision of file. Take 4"
        34722a3fd Third revision of file. Take 4
        6f819a796 Second revision of file
        705dfa037 Initial draft of file
      6. At this point, it is possible to create a new branch based around the checked out version. However, the actual current version can be quickly restored using the git switch command.

        git switch -
        
        Previous HEAD position was 606638205 Revert "Third revision of file. Take 4"
        Switched to branch 'git-test'
      7. Confirm the file is no longer in a detached head state.

        git status testfile1.txt
        
        On branch git-test
        nothing to commit, working tree clean
      8. The current contents of the file are restored to the working directory.

        cat testfile1.txt
        
        First line of text.
        Second line of text for check-in 2.
        Final attempt at new line.

      Amending a Git Commit Message

      If the files and changes in a git commit operation were correct, but the comment was wrong, it can easily be amended. Use the command Git commit --amend -m <updated-message> to update the message associated with the commit. This option can only be used to modify the most recent commit.

      Note

      This command must never be used to modify the message of a commit that has already been pushed to a remote server. This leaves the two repositories out of sync and is almost guaranteed to cause trouble in the future.

      There are a couple of other similar Git commands that are useful in certain situations.

      • The git clean command removes untracked files or directories that have not yet been added to the staging area or committed. It can be used to clean up a workspace and delete unwanted or forgotten files.
      • The git rm command is sometimes confused with revert or reset, but it has a different purpose. git rm is used to remove a file that is no longer required from the repository. However, the file history is preserved. This means the command can be undone using the reset directive and earlier versions can still be retrieved for viewing. rm is the inverse of the git add operation. The file is not removed from the local repository until the change is committed.

      Conclusion

      This guide explains how to undo a commit in Git. There are several Git commands that can undo a local commit. Choosing the most appropriate command depends on an understanding of how Git operates and the circumstances of the commit.

      The git reset command restores an earlier version of the file to the repository and eliminates all records of the more recent commits. It is available as a hard reset, which overwrites local changes, and a soft reset, which preserves them. The git revert command also undoes a Git command. It generates a new commit to invert the original changes. This leaves both the initial change and the undo operation in the file history and repository. Other commands, including git checkout, git clean, and git rm can also be used to revert changes in certain circumstances.

      More Information

      You may wish to consult the following resources for additional information
      on this topic. While these are provided in the hope that they will be
      useful, please note that we cannot vouch for the accuracy or timeliness of
      externally hosted materials.



      Source link

      Git vs SVN: Pros and Cons of Each Version Control System


      Version Control Systems (VCS), like Git and SVN, track and manage code changes and provide an efficient way to collaborate on software development projects. A VCS is especially useful as a software development project grows in size and complexity, but even the simplest projects can benefit from tracking code changes with a VCS.

      Git and SVN are two of the most popular open source VCS solutions. Git has recently skyrocketed in popularity due to its use by developers collaborating on open-source projects. SVN, on the other hand, has been more commonly used in enterprise software development projects.

      This guide discusses the features and pros and cons of Git and SVN to help you choose the best VCS for your software development project.

      What is the Git Version Control System?

      Git
      is a distributed version control system. In this type of VCS, a project contributor creates a local repository that is a full clone of a central repository. With a local clone of the central repository, each contributor is able to work on the project completely offline on their own computer. When changes are ready, contributors can push and merge them with the central repository.

      Git has immense support from the open-source community. It has quickly become one of the most used version control systems for software development projects.

      What is SVN?

      Apache Subversion
      (SVN), is a centralized version control system. When working with this type of VCS, all project files exist on a central repository server. The central repository has a “trunk,” which contains the current, stable version of the project. When working on new features, contributors can make “branches” from the trunk. Each branch is stored in a sub-folder on the central repository. When changes are ready, a branch can be merged into the trunk.

      SVN has a long and successful history and stands as a titan in the version control world. It has widespread usage for enterprise projects, with features like granular access control that make it excel in that context.

      Git vs SVN: Pros and Cons

      To help you understand how these two version control solutions match up, this section walks you through the pros and cons of each.

      Git Pros and Cons

      Git’s pros are the following:

      • Operates locally. Contributors work on clones of the main repository, which they can continue to work on offline, without a network connection to the main repository. Contributors only need to connect when changes are ready to be pushed. This also helps limit network traffic to the main repository.

      • Avoids having a single point of failure. The repository is distributed in local copies, so there is less to worry about if a failure occurs on the main repository. The main repository can be restored from one of the local copies.

      • Handles merging from multiple contributors effectively. Contributors all work independently on their copies of the main repository. Git then provides a robust system for reconciling and merging each contributor’s changes. Staging is part of this, allowing contributors to focus on particular features without affecting others.

      Git’s cons are the following:

      • Has a higher learning curve. Using Git to collaborate on a project requires that you make your changes locally, stage those changes, and merge the changes back into the main branch. This process can get complicated, especially for non-technical users.

      • Lacks granular access control. Git supports applying limits on a contributor’s ability to create branches and merge changes on the main repository. However, you cannot restrict access to specific parts of the repository. Anyone with access to the repository has access to everything in the repository, with local repositories being clones of the entire codebase.

      • Does not effectively handle storing large binary files. Git cannot compress these files effectively, meaning that the repository size can grow exponentially with each change to a large binary file.

      SVN Pros and Cons

      SVN’s pros are the following:

      • Takes an easier approach. The path between
        creating a new feature branch
        and merging it into the trunk is relatively short and intuitive to grasp. This makes SVN a tool that requires less training when getting started and can be effectively taken up by non-technical contributors.

      • Facilitates a top-down approach. Since everything is centralized in an SVN repository, there is a single instance of the entire repository. This allows for granular repository access control. Each contributor’s access can be limited to particular directories and files. SVN is a good choice when you need to manage security hierarchies within a repository.

      • Efficiently stores large binary files. Teams that need to store binary files, especially when those binary files change frequently, can do so without worrying about exponential storage increases with each change. While this is not a concern for every team, this feature can be a significant boon for some workflows and version control use cases.

      SVN’s cons are the following:

      • Provides limited offline capabilities. Everything operates on a centralized repository using a client-server approach. When contributors are offline and unable to access the server, they essentially lose the ability to contribute. This also entails a higher level of traffic to the main repository’s server, since contributors have to access it constantly.

      • The centralized repository server can be a single point of failure. Since contributors do not make local copies of the entire repository, unless a backup copy is made, there is only one instance of the entire repository. If an issue occurs with the instance, such as data corruption, it can have dire repercussions on a software development project.

      Advantages of Git Over SVN

      The ability to work locally and offline is one major advantage to Git. SVN requires contributors to be connected to the main repository server, which essentially eliminates working offline.

      Git also outperforms SVN when it comes to merging and conflict resolution. Git has been designed for an open-source setting where numerous contributors may be working on the same parts of a codebase. To allow for this type of collaboration, Git has built up a robust system for resolving merge conflicts that makes the process smoother, and more manageable.

      Git’s distributed model of version control helps mitigate the potential for loss of the main repository. Since contributors clone the main repository, the risk of completely losing your main repository is greatly reduced. On the other hand, SVN’s centralized model of version control creates the potential for a single point of failure should anything happen to the main repository.

      Advantages of SVN Over Git

      SVN’s centralized repository model makes it easier to manage contributions and contributors. Git does not support codebase access restrictions — a contributor who has access to the repository has access to the entire repository. SVN, by contrast, provides granular control, allowing for limits on particular contributors down to the directory, and file levels.

      SVN also makes contributing easier. Git has robust conflict handling, but its system can often be daunting for newcomers. SVN’s system is more approachable, because the path between creating a new feature and merging it into the trunk is shorter and simpler.

      SVN wins out on some performance considerations. It handles network traffic exceptionally well. So, while contributors may have to be connected to the server to complete work, the network load for this is managed efficiently. Also, SVN compresses and stores large binaries quite efficiently. If your project includes large binary files, you might consider using SVN.

      Which Should You Use?

      Each of the version control systems covered here — SVN and Git — has its particular strengths and weaknesses. Each one fits different use cases better than the other, and neither one wins out over the other one outright.

      • Use SVN when you need a VCS that favors top-down management, easy contributions, and does not require you to work entirely offline. SVN often comes out on top for enterprise usage specifically for its granular access control, and it is the clear choice if you need to set up security hierarchies.

        To get started with SVN, be sure to read through our guide
        How to Install and Use the Subversion CLI Client
        .

      • Use Git when you need numerous contributors to work in parallel, where you expect lots of potential merge conflicts, and when you need contributors to be able to work locally offline. Because it handles merge conflicts, Git makes sense for most open-source projects, where contributors often work without external coordination. Git shines in a wide range of environments with complex codebases and distributed teams.

        To learn more and start working with Git, check out our guide
        Getting Started with Git
        .

      Conclusion

      SVN and Git are both powerful version control systems that each use a different approach to managing and merging code changes. Git uses a distributed model, whereas SVN uses a centralized model. Which VCS that you choose largely depends on your software development project’s requirements. After reading this guide, you should be able to select the best version control system for your needs.



      Source link