{"id":5190,"date":"2024-05-27T10:27:41","date_gmt":"2024-05-27T10:27:41","guid":{"rendered":"https:\/\/favtutor.com\/articles\/?p=5190"},"modified":"2024-05-27T10:27:42","modified_gmt":"2024-05-27T10:27:42","slug":"git-commands-for-teams","status":"publish","type":"post","link":"https:\/\/favtutor.com\/articles\/git-commands-for-teams\/","title":{"rendered":"I Learned These Git Commands Before Working With A Team"},"content":{"rendered":"\n

Today, I will go through some important git commands that are necessary for collaboration with teams. These Git Commands are important for beginners to learn before they become a part of a coding team in a company. But if you don’t know anything about GitHub, here is a guide<\/a> for you to start with.<\/p>\n\n\n\n

Must-Learn Git Commands You Should Know<\/strong><\/h2>\n\n\n\n

I will cover different merging strategies and how to fetch and revert changes safely, and finally, I will teach you how to selectively add commits from one branch to the main branch without merging the branch entirely! You’ll be well-equipped to work in a team environment after you know and master these tricks.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

It\u2019s a fun topic, so let\u2019s get into that.<\/p>\n\n\n\n

1) Merge<\/strong><\/h3>\n\n\n\n

Merging in Git is the process of combining changes from different branches into one branch. It’s a fundamental feature that allows multiple developers to work on separate parts of a project simultaneously and then merge their changes together.<\/p>\n\n\n\n

Let\u2019s suppose we have a branch called \u201cnew-feature\u201d and the main branch is called \u201cmain\u201d. We branched from the second commit of the main as follows:<\/p>\n\n\n

\n
\"merging\"<\/figure>\n<\/div>\n\n\n

After continuing working on the \u201cnew-feature\u201d branch, we decided to merge it into the main. We can achieve that by the following commands:<\/p>\n\n\n\n

    \n
  1. git checkout main<\/code><\/li>\n\n\n\n
  2. git merge new-feature -m \u201cmerging commit\u201d<\/code><\/li>\n<\/ol>\n\n\n
    \n
    \"merge<\/figure>\n<\/div>\n\n\n

    2) Rebase<\/strong><\/h3>\n\n\n\n

    Sometimes, adding a merge commit after every merge is a tedious work and can make the git history a little bit confusing. For such a case, we can rebase. Rebase is a powerful feature in Git that allows you to move or combine a sequence of commits to a new base commit. <\/p>\n\n\n\n

    The purpose is to create a linear history of commits instead of having unnecessary merge commits.<\/p>\n\n\n\n

    Rebasing basically takes the commits on one branch and applying them after the last commit of another branch. Usually, it\u2019s done by rebasing a feature branch onto the main branch.<\/p>\n\n\n\n

    Let\u2019s suppose we have a feature branch called \u201cnew-feature\u201d and the main branch called \u201cmain\u201d. We can rebase onto the main branch by first pulling the latest changes from the remote onto the main branch:<\/p>\n\n\n\n

      \n
    1. git checkout main<\/code><\/li>\n\n\n\n
    2. git pull<\/code><\/li>\n<\/ol>\n\n\n\n

      Then we can apply the actual rebasing:<\/p>\n\n\n\n

        \n
      1. git checkout new-feature<\/code><\/li>\n\n\n\n
      2. git rebase main<\/code><\/li>\n<\/ol>\n\n\n\n

        And the result is as shown in the diagram below:<\/p>\n\n\n

        \n
        \"Rebasing\"<\/figure>\n<\/div>\n\n\n

        What happens if there were any conflicts? Git will automatically pause and wait for you to resolve the conflicts and add the resolved files to the staging area and committing them again and continue the rebase process.<\/p>\n\n\n\n

        So, after it pauses and you resolve your conflicts, you can do the following:<\/p>\n\n\n\n

          \n
        1. git add resolved_file.txt<\/code><\/li>\n\n\n\n
        2. git rebase --continue<\/code><\/li>\n<\/ol>\n\n\n\n

          If at any point in the conflict-resolving process, you decide that it is too complicated to rebase and want to abort the process, you can do:<\/p>\n\n\n\n

          git rebase --abort<\/code><\/p>\n\n\n\n

          If the rebase is done successfully, you can merge the commits made inside the new-feature branch into the main branch:<\/p>\n\n\n\n

            \n
          1. git checkout main<\/code><\/li>\n\n\n\n
          2. git rebase new-feature<\/code><\/li>\n<\/ol>\n\n\n
            \n
            \"\"<\/figure>\n<\/div>\n\n\n

            Finally you can push the changes but you have to force push since you re-wrote the git history:<\/p>\n\n\n\n

            git push origin new-feature --force<\/code><\/p>\n\n\n\n

            If you look at the diagrams between the basic merge and the rebase, you can see that basic merge creates a merge commit, while rebasing keeps a linear commit history without the need of unnecessary merge commits.<\/p>\n\n\n\n

            3) Squash<\/strong><\/h3>\n\n\n\n

            Squashing allows you to condense multiple commits into one. This is useful for cleaning up your commit history before merging changes into the main branch.<\/p>\n\n\n\n

            Again, let\u2019s suppose we have a main branch from which we branch into a new branch called \u201cnew feature\u201d as shown below:<\/p>\n\n\n

            \n
            \"\"<\/figure>\n<\/div>\n\n\n

            Now we want to merge the \u201cnew feature\u201d branch into the main branch. But instead of doing so as in the basic merge, let\u2019s squash the two commits we made before we merge:<\/p>\n\n\n\n

              \n
            1. git merge \u2013squash new-feature<\/code><\/li>\n\n\n\n
            2. git commit -m \"Squashed commit message\"<\/code><\/li>\n<\/ol>\n\n\n\n

              This will squash the commits into a single merge commit as shown in the diagram below:<\/p>\n\n\n

              \n
              \"Squash\"<\/figure>\n<\/div>\n\n\n

              4) Revert Unstaged Changes<\/strong><\/h3>\n\n\n\n

              You can discard unstaged changes (i.e., revert the file to its state in the last commit) by using this command:<\/p>\n\n\n\n

              git restore filename<\/code><\/p>\n\n\n\n

              Or you can restore all the files to the latest commit:<\/p>\n\n\n\n

              git restore <\/code><\/p>\n\n\n\n

              5) Revert Staged Changes<\/strong><\/h3>\n\n\n\n

              You can use git reset<\/code> to unstaged changes, which will move the changes from the staging area back to your working directory.
              To revert a specific file:<\/p>\n\n\n\n

              git reset HEAD filename<\/code><\/p>\n\n\n\n

              To revert everything:<\/p>\n\n\n\n

              git reset HEAD <\/code><\/p>\n\n\n\n

              6) Fetch vs. Pull<\/strong><\/h3>\n\n\n\n

              Fetch and pull commands are very similar, yet different. Sometimes you want to see what changes people have made to the remote branch but not necessarily to incorporate them into your local branch. That is the \u201cfetch\u201d command. But if you want to fetch and merge the changes on your local branch, that\u2019s \u201cpull\u201d.<\/p>\n\n\n\n

              In other words, pull = fetch + merge.<\/strong><\/p>\n\n\n\n

              Fetching downloads commits from a remote repo to your local clone, but doesn\u2019t merge them. It updates your remote-tracking branches (e.g., origin\/main) but doesn’t merge these changes into the working branch. <\/p>\n\n\n\n

              This is a safe way to see what others have been working on without changing your current files. Many experienced developer prefer to use git fetch instead of git pull because it\u2019s safer and gives more control.
              \u201cgit pull\u201d on the other hand, first fetches the latest changes from the remote repository and then automatically merges those changes into your current working branch. <\/p>\n\n\n\n

              It updates your working files and local branch with the latest changes from the remote repository, which can potentially lead to merge conflicts if both you and someone else have made changes to the same parts of the code.<\/p>\n\n\n\n

              7) Cherry pick!<\/strong><\/h3>\n\n\n\n

              Believe it or not, \u201ccherry pick\u201d is a git command and it is useful when you want to copy specific commits from one branch to another without merging the entire branch.<\/p>\n\n\n\n

              git cherry-pick <commit-hash><\/code><\/p>\n\n\n\n

              To know the hash of the commit, use: git log \u2013oneline<\/code><\/p>\n\n\n\n

              And if you are looking for the latest commit, you can use: git show<\/p>\n\n\n\n

              What if you want to \u201ccherry-pick\u201d multiple commits at once? You can simply pass different commit hashes, and they will be applied to your current branch.<\/p>\n\n\n\n

              git cherry-pick <commit-hash-1> <commit-hash-2> <commit-hash-3><\/code><\/p>\n\n\n\n

              Conclusion<\/strong><\/h2>\n\n\n\n

              These were some useful, yet uncommon commands in the coding bootcamps. They might not be useful as a solo developer, but for collaboration with teams, they are crucial.<\/p>\n","protected":false},"excerpt":{"rendered":"

              These are some important git commands to learn for beginners when they want to collaborate with teams in a company.<\/p>\n","protected":false},"author":24,"featured_media":5200,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jnews-multi-image_gallery":[],"jnews_single_post":null,"jnews_primary_category":{"id":"","hide":""},"footnotes":""},"categories":[57],"tags":[82,260,202],"class_list":["post-5190","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","tag-coding","tag-git","tag-programming"],"_links":{"self":[{"href":"https:\/\/favtutor.com\/articles\/wp-json\/wp\/v2\/posts\/5190","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/favtutor.com\/articles\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/favtutor.com\/articles\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/favtutor.com\/articles\/wp-json\/wp\/v2\/users\/24"}],"replies":[{"embeddable":true,"href":"https:\/\/favtutor.com\/articles\/wp-json\/wp\/v2\/comments?post=5190"}],"version-history":[{"count":3,"href":"https:\/\/favtutor.com\/articles\/wp-json\/wp\/v2\/posts\/5190\/revisions"}],"predecessor-version":[{"id":5202,"href":"https:\/\/favtutor.com\/articles\/wp-json\/wp\/v2\/posts\/5190\/revisions\/5202"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/favtutor.com\/articles\/wp-json\/wp\/v2\/media\/5200"}],"wp:attachment":[{"href":"https:\/\/favtutor.com\/articles\/wp-json\/wp\/v2\/media?parent=5190"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/favtutor.com\/articles\/wp-json\/wp\/v2\/categories?post=5190"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/favtutor.com\/articles\/wp-json\/wp\/v2\/tags?post=5190"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}