Combining Multiple Commits Into One Prior To Push












112















This question pertains not only to how to accomplish this task, but to whether doing so is good or bad practice with Git.



Consider that locally I do most work on the master branch, but I have created a topical branch I will call "topical_xFeature". In the process of working on "topical_xFeature" and switching back and forth to do other work on the master branch, it turns out that I have made more than one commit on the "topical_xFeature" branch, but between each commit, I have done no push.



First, would you consider this bad practice? Would it not be wiser to stick with one commit per branch per push? In what cases would it be good to have multiple commits on a branch before a push is made?



Second, how shall I best accomplish bringing the multiple commits on the topical_xFeature branch into the master branch for a push? Is it a nuisance to not worry about it and just do the push where multiple commits get pushed, or is it less annoying to somehow merge the commits into one and then push? Again, how to do this?










share|improve this question



























    112















    This question pertains not only to how to accomplish this task, but to whether doing so is good or bad practice with Git.



    Consider that locally I do most work on the master branch, but I have created a topical branch I will call "topical_xFeature". In the process of working on "topical_xFeature" and switching back and forth to do other work on the master branch, it turns out that I have made more than one commit on the "topical_xFeature" branch, but between each commit, I have done no push.



    First, would you consider this bad practice? Would it not be wiser to stick with one commit per branch per push? In what cases would it be good to have multiple commits on a branch before a push is made?



    Second, how shall I best accomplish bringing the multiple commits on the topical_xFeature branch into the master branch for a push? Is it a nuisance to not worry about it and just do the push where multiple commits get pushed, or is it less annoying to somehow merge the commits into one and then push? Again, how to do this?










    share|improve this question

























      112












      112








      112


      42






      This question pertains not only to how to accomplish this task, but to whether doing so is good or bad practice with Git.



      Consider that locally I do most work on the master branch, but I have created a topical branch I will call "topical_xFeature". In the process of working on "topical_xFeature" and switching back and forth to do other work on the master branch, it turns out that I have made more than one commit on the "topical_xFeature" branch, but between each commit, I have done no push.



      First, would you consider this bad practice? Would it not be wiser to stick with one commit per branch per push? In what cases would it be good to have multiple commits on a branch before a push is made?



      Second, how shall I best accomplish bringing the multiple commits on the topical_xFeature branch into the master branch for a push? Is it a nuisance to not worry about it and just do the push where multiple commits get pushed, or is it less annoying to somehow merge the commits into one and then push? Again, how to do this?










      share|improve this question














      This question pertains not only to how to accomplish this task, but to whether doing so is good or bad practice with Git.



      Consider that locally I do most work on the master branch, but I have created a topical branch I will call "topical_xFeature". In the process of working on "topical_xFeature" and switching back and forth to do other work on the master branch, it turns out that I have made more than one commit on the "topical_xFeature" branch, but between each commit, I have done no push.



      First, would you consider this bad practice? Would it not be wiser to stick with one commit per branch per push? In what cases would it be good to have multiple commits on a branch before a push is made?



      Second, how shall I best accomplish bringing the multiple commits on the topical_xFeature branch into the master branch for a push? Is it a nuisance to not worry about it and just do the push where multiple commits get pushed, or is it less annoying to somehow merge the commits into one and then push? Again, how to do this?







      git workflow






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Apr 19 '11 at 19:26









      Todd HopkinsonTodd Hopkinson

      5,29952834




      5,29952834
























          5 Answers
          5






          active

          oldest

          votes


















          125














          For your first question, no, there's nothing wrong with pushing multiple commits at once. Many times, you may want to break your work down into a few small, logical commits, but only push them up once you feel like the whole series is ready. Or you might be making several commits locally while disconnected, and you push them all once you're connected again. There's no reason to limit yourself to one commit per push.



          I generally find that it's a good idea to keep each commit a single, logical, coherent change, that includes everything it needs to work (so, it does not leave your code in a broken state). If you have a two commits, but they would cause the code to be broken if you only applied the first one, it might be a good idea to squash the second commit into the first. But if you have two commits where each one makes a reasonable change, pushing them as separate commits is fine.



          If you do want to squash several commits together, you can use git rebase -i. If you're on branch topical_xFeature, you would run git rebase -i master. This will open an editor window, with a bunch of commits listed prefixed by pick. You can change all but the first to squash, which will tell Git to keep all of those changes, but squash them into the first commit. After you've done that, check out master and merge in your feature branch:



          git checkout topical_xFeature
          git rebase -i master
          git checkout master
          git merge topical_xFeature


          Alternatively, if you just want to squash everything in topical_xFeature into master, you could just do the following:



          git checkout master
          git merge --squash topical_xFeature
          git commit


          Which one you choose is up to you. Generally, I wouldn't worry about having multiple smaller commits, but sometimes you don't want to bother with extra minor commits, so you just squash them into one.






          share|improve this answer



















          • 23





            git merge --squash! right. +1

            – VonC
            Apr 19 '11 at 20:13






          • 1





            After I merge with --squash, I am not able to delete the topic branch with git branch -d topic. Why is git not able to identify that all the changes are merged?

            – balki
            Oct 22 '12 at 11:20






          • 7





            @balki Because Git detects whether patches are merged based on whether they appear in the history of the given branch. Squashing commits changes them; they become a new commit, and while that new commit happens to do the same thing as the other ones, Git can't tell that, it can only tell if commits are the same if they have the same commit ID (SHA-1). So once you squash it, you need to tell git to delete the old branch with git branch -D topic to forcibly delete it.

            – Brian Campbell
            Oct 22 '12 at 13:44



















          61














          This is the way I generally follow to combine multiple Commits into a single commit before I push the code.



          To achieve this, I suggest you use 'squash' concept provided by GIT.



          Follow the below steps.



          1) git rebase -i master (instead of master you can also use a specific commit)



          open the rebase interactive editor, where it will show all your commits. Basically where you need to identify the commits which you want to merge into a single commit.



          Imagine these are your commits and shown something like this in the editor.



          pick f7f3f6d changed my name a bit    
          pick 310154e updated README formatting and added blame
          pick a5f4a0d added cat-file


          It's important to note that these commits are listed in the opposite order than you normally see them using the log command. Means, the older commit will be shown first.



          2) Change 'pick' to 'squash' for last committed changes. something like shown below. Doing that so, your last 2 commits will be merged with the first one.



          pick f7f3f6d changed my name a bit         
          squash 310154e updated README formatting and added blame
          squash a5f4a0d added cat-file


          You can also use short form if you have lot of commits to combine:



          p f7f3f6d changed my name a bit         
          s 310154e updated README formatting and added blame
          s a5f4a0d added cat-file


          for editing use 'i', it will enable the editor for insertion. Keep in mind top most(oldest) commit cannot be squashed as there is no previous commit to combine with. So it has to be picked or 'p'. Use 'Esc' to exit insert mode.



          3) Now, save the editor with the following command.
          :wq



          When you save that, you have a single commit that introduces the changes of all three previous commits.



          Hope this will help you.






          share|improve this answer





















          • 4





            Perhaps this is obvious to others but, when you say "git rebase -i", you also need to specify which commit you start at. This is something I didn't realize when I tried following this example. So, in this example, it'd be "git rebase -i xxxxx" where xxxxx is the commit right before f7f3f6d chronologically. Once I figured that out, everything worked out exactly as described above.

            – nukeguy
            Apr 22 '16 at 19:26











          • That's interesting @nukeguy, I didn't have any issue not specifying a specific commit. It just defaulted to what was there.

            – JCrooks
            Jan 25 '17 at 20:23



















          11














          First: nothing tells you to only have one commit per branch per push: a push is a publication mechanism allowing you to publish a local history (i.e. a collection of commits) on a remote repo.



          Second: a git merge --no-ff topical_xFeature would record on master as a single commit your topic work, before pushing master.

          (That way, you keep topical_xFeature around for further evolutions, that you can record on master as a single new commit on the next merge --no-ff.

          If getting rid of topical_xFeature is the goal, then git merge --squash is the right option, as detailed in Brian Campbell's answer.)






          share|improve this answer


























          • I think that --squash, not --no-ff is what you want. --no-ff would create a merge commit, but also leave all of the commits from topical_xFeature.

            – Brian Campbell
            Apr 19 '11 at 19:59











          • @Brian: I agree and upvoted your answer, but I first thought of the --no-ff option because I wanted to keep topical_feature branch around, and just record a single commit on master branch.

            – VonC
            Apr 19 '11 at 20:15



















          8














          Switch to the master branch and make sure you are up to date.



          git checkout master


          git fetch this may be necessary (depending on your git config) to receive updates on origin/master



          git pull


          Merge the feature branch into the master branch.



          git merge feature_branch


          Reset the master branch to origin's state.



          git reset origin/master


          Git now considers all changes as unstaged changes.
          We can add these changes as one commit.
          Adding . will also add untracked files.



          git add --all

          git commit


          Ref: https://makandracards.com/makandra/527-squash-several-git-commits-into-a-single-commit






          share|improve this answer



















          • 2





            this answer is easy to follow and really easy to visualize.

            – jokab
            Dec 14 '17 at 3:53





















          1














          1) First choose which commit you want everything to come after.



          git reflog
          5976f2b HEAD@{0}: commit: Fix conflicts
          80e85a1 HEAD@{1}: commit: Add feature
          b860ddb HEAD@{2}: commit: Add something


          2) Reset to your selected head (I have chosen HEAD@{2})



          git reset b860ddb --soft


          3) git status (just to be sure)



          4) Add your new commit



          git commit -m "Add new commit"


          Note: HEAD@{0} & HEAD@{1} Are now merged into 1 commit, this can be done for multiple commits also.



          git reflog again should display:



          git reflog
          5976f2b HEAD@{0}: commit: Add new commit
          b860ddb HEAD@{1}: commit: Add something





          share|improve this answer
























            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f5721566%2fcombining-multiple-commits-into-one-prior-to-push%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            5 Answers
            5






            active

            oldest

            votes








            5 Answers
            5






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            125














            For your first question, no, there's nothing wrong with pushing multiple commits at once. Many times, you may want to break your work down into a few small, logical commits, but only push them up once you feel like the whole series is ready. Or you might be making several commits locally while disconnected, and you push them all once you're connected again. There's no reason to limit yourself to one commit per push.



            I generally find that it's a good idea to keep each commit a single, logical, coherent change, that includes everything it needs to work (so, it does not leave your code in a broken state). If you have a two commits, but they would cause the code to be broken if you only applied the first one, it might be a good idea to squash the second commit into the first. But if you have two commits where each one makes a reasonable change, pushing them as separate commits is fine.



            If you do want to squash several commits together, you can use git rebase -i. If you're on branch topical_xFeature, you would run git rebase -i master. This will open an editor window, with a bunch of commits listed prefixed by pick. You can change all but the first to squash, which will tell Git to keep all of those changes, but squash them into the first commit. After you've done that, check out master and merge in your feature branch:



            git checkout topical_xFeature
            git rebase -i master
            git checkout master
            git merge topical_xFeature


            Alternatively, if you just want to squash everything in topical_xFeature into master, you could just do the following:



            git checkout master
            git merge --squash topical_xFeature
            git commit


            Which one you choose is up to you. Generally, I wouldn't worry about having multiple smaller commits, but sometimes you don't want to bother with extra minor commits, so you just squash them into one.






            share|improve this answer



















            • 23





              git merge --squash! right. +1

              – VonC
              Apr 19 '11 at 20:13






            • 1





              After I merge with --squash, I am not able to delete the topic branch with git branch -d topic. Why is git not able to identify that all the changes are merged?

              – balki
              Oct 22 '12 at 11:20






            • 7





              @balki Because Git detects whether patches are merged based on whether they appear in the history of the given branch. Squashing commits changes them; they become a new commit, and while that new commit happens to do the same thing as the other ones, Git can't tell that, it can only tell if commits are the same if they have the same commit ID (SHA-1). So once you squash it, you need to tell git to delete the old branch with git branch -D topic to forcibly delete it.

              – Brian Campbell
              Oct 22 '12 at 13:44
















            125














            For your first question, no, there's nothing wrong with pushing multiple commits at once. Many times, you may want to break your work down into a few small, logical commits, but only push them up once you feel like the whole series is ready. Or you might be making several commits locally while disconnected, and you push them all once you're connected again. There's no reason to limit yourself to one commit per push.



            I generally find that it's a good idea to keep each commit a single, logical, coherent change, that includes everything it needs to work (so, it does not leave your code in a broken state). If you have a two commits, but they would cause the code to be broken if you only applied the first one, it might be a good idea to squash the second commit into the first. But if you have two commits where each one makes a reasonable change, pushing them as separate commits is fine.



            If you do want to squash several commits together, you can use git rebase -i. If you're on branch topical_xFeature, you would run git rebase -i master. This will open an editor window, with a bunch of commits listed prefixed by pick. You can change all but the first to squash, which will tell Git to keep all of those changes, but squash them into the first commit. After you've done that, check out master and merge in your feature branch:



            git checkout topical_xFeature
            git rebase -i master
            git checkout master
            git merge topical_xFeature


            Alternatively, if you just want to squash everything in topical_xFeature into master, you could just do the following:



            git checkout master
            git merge --squash topical_xFeature
            git commit


            Which one you choose is up to you. Generally, I wouldn't worry about having multiple smaller commits, but sometimes you don't want to bother with extra minor commits, so you just squash them into one.






            share|improve this answer



















            • 23





              git merge --squash! right. +1

              – VonC
              Apr 19 '11 at 20:13






            • 1





              After I merge with --squash, I am not able to delete the topic branch with git branch -d topic. Why is git not able to identify that all the changes are merged?

              – balki
              Oct 22 '12 at 11:20






            • 7





              @balki Because Git detects whether patches are merged based on whether they appear in the history of the given branch. Squashing commits changes them; they become a new commit, and while that new commit happens to do the same thing as the other ones, Git can't tell that, it can only tell if commits are the same if they have the same commit ID (SHA-1). So once you squash it, you need to tell git to delete the old branch with git branch -D topic to forcibly delete it.

              – Brian Campbell
              Oct 22 '12 at 13:44














            125












            125








            125







            For your first question, no, there's nothing wrong with pushing multiple commits at once. Many times, you may want to break your work down into a few small, logical commits, but only push them up once you feel like the whole series is ready. Or you might be making several commits locally while disconnected, and you push them all once you're connected again. There's no reason to limit yourself to one commit per push.



            I generally find that it's a good idea to keep each commit a single, logical, coherent change, that includes everything it needs to work (so, it does not leave your code in a broken state). If you have a two commits, but they would cause the code to be broken if you only applied the first one, it might be a good idea to squash the second commit into the first. But if you have two commits where each one makes a reasonable change, pushing them as separate commits is fine.



            If you do want to squash several commits together, you can use git rebase -i. If you're on branch topical_xFeature, you would run git rebase -i master. This will open an editor window, with a bunch of commits listed prefixed by pick. You can change all but the first to squash, which will tell Git to keep all of those changes, but squash them into the first commit. After you've done that, check out master and merge in your feature branch:



            git checkout topical_xFeature
            git rebase -i master
            git checkout master
            git merge topical_xFeature


            Alternatively, if you just want to squash everything in topical_xFeature into master, you could just do the following:



            git checkout master
            git merge --squash topical_xFeature
            git commit


            Which one you choose is up to you. Generally, I wouldn't worry about having multiple smaller commits, but sometimes you don't want to bother with extra minor commits, so you just squash them into one.






            share|improve this answer













            For your first question, no, there's nothing wrong with pushing multiple commits at once. Many times, you may want to break your work down into a few small, logical commits, but only push them up once you feel like the whole series is ready. Or you might be making several commits locally while disconnected, and you push them all once you're connected again. There's no reason to limit yourself to one commit per push.



            I generally find that it's a good idea to keep each commit a single, logical, coherent change, that includes everything it needs to work (so, it does not leave your code in a broken state). If you have a two commits, but they would cause the code to be broken if you only applied the first one, it might be a good idea to squash the second commit into the first. But if you have two commits where each one makes a reasonable change, pushing them as separate commits is fine.



            If you do want to squash several commits together, you can use git rebase -i. If you're on branch topical_xFeature, you would run git rebase -i master. This will open an editor window, with a bunch of commits listed prefixed by pick. You can change all but the first to squash, which will tell Git to keep all of those changes, but squash them into the first commit. After you've done that, check out master and merge in your feature branch:



            git checkout topical_xFeature
            git rebase -i master
            git checkout master
            git merge topical_xFeature


            Alternatively, if you just want to squash everything in topical_xFeature into master, you could just do the following:



            git checkout master
            git merge --squash topical_xFeature
            git commit


            Which one you choose is up to you. Generally, I wouldn't worry about having multiple smaller commits, but sometimes you don't want to bother with extra minor commits, so you just squash them into one.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Apr 19 '11 at 19:52









            Brian CampbellBrian Campbell

            237k50320320




            237k50320320








            • 23





              git merge --squash! right. +1

              – VonC
              Apr 19 '11 at 20:13






            • 1





              After I merge with --squash, I am not able to delete the topic branch with git branch -d topic. Why is git not able to identify that all the changes are merged?

              – balki
              Oct 22 '12 at 11:20






            • 7





              @balki Because Git detects whether patches are merged based on whether they appear in the history of the given branch. Squashing commits changes them; they become a new commit, and while that new commit happens to do the same thing as the other ones, Git can't tell that, it can only tell if commits are the same if they have the same commit ID (SHA-1). So once you squash it, you need to tell git to delete the old branch with git branch -D topic to forcibly delete it.

              – Brian Campbell
              Oct 22 '12 at 13:44














            • 23





              git merge --squash! right. +1

              – VonC
              Apr 19 '11 at 20:13






            • 1





              After I merge with --squash, I am not able to delete the topic branch with git branch -d topic. Why is git not able to identify that all the changes are merged?

              – balki
              Oct 22 '12 at 11:20






            • 7





              @balki Because Git detects whether patches are merged based on whether they appear in the history of the given branch. Squashing commits changes them; they become a new commit, and while that new commit happens to do the same thing as the other ones, Git can't tell that, it can only tell if commits are the same if they have the same commit ID (SHA-1). So once you squash it, you need to tell git to delete the old branch with git branch -D topic to forcibly delete it.

              – Brian Campbell
              Oct 22 '12 at 13:44








            23




            23





            git merge --squash! right. +1

            – VonC
            Apr 19 '11 at 20:13





            git merge --squash! right. +1

            – VonC
            Apr 19 '11 at 20:13




            1




            1





            After I merge with --squash, I am not able to delete the topic branch with git branch -d topic. Why is git not able to identify that all the changes are merged?

            – balki
            Oct 22 '12 at 11:20





            After I merge with --squash, I am not able to delete the topic branch with git branch -d topic. Why is git not able to identify that all the changes are merged?

            – balki
            Oct 22 '12 at 11:20




            7




            7





            @balki Because Git detects whether patches are merged based on whether they appear in the history of the given branch. Squashing commits changes them; they become a new commit, and while that new commit happens to do the same thing as the other ones, Git can't tell that, it can only tell if commits are the same if they have the same commit ID (SHA-1). So once you squash it, you need to tell git to delete the old branch with git branch -D topic to forcibly delete it.

            – Brian Campbell
            Oct 22 '12 at 13:44





            @balki Because Git detects whether patches are merged based on whether they appear in the history of the given branch. Squashing commits changes them; they become a new commit, and while that new commit happens to do the same thing as the other ones, Git can't tell that, it can only tell if commits are the same if they have the same commit ID (SHA-1). So once you squash it, you need to tell git to delete the old branch with git branch -D topic to forcibly delete it.

            – Brian Campbell
            Oct 22 '12 at 13:44













            61














            This is the way I generally follow to combine multiple Commits into a single commit before I push the code.



            To achieve this, I suggest you use 'squash' concept provided by GIT.



            Follow the below steps.



            1) git rebase -i master (instead of master you can also use a specific commit)



            open the rebase interactive editor, where it will show all your commits. Basically where you need to identify the commits which you want to merge into a single commit.



            Imagine these are your commits and shown something like this in the editor.



            pick f7f3f6d changed my name a bit    
            pick 310154e updated README formatting and added blame
            pick a5f4a0d added cat-file


            It's important to note that these commits are listed in the opposite order than you normally see them using the log command. Means, the older commit will be shown first.



            2) Change 'pick' to 'squash' for last committed changes. something like shown below. Doing that so, your last 2 commits will be merged with the first one.



            pick f7f3f6d changed my name a bit         
            squash 310154e updated README formatting and added blame
            squash a5f4a0d added cat-file


            You can also use short form if you have lot of commits to combine:



            p f7f3f6d changed my name a bit         
            s 310154e updated README formatting and added blame
            s a5f4a0d added cat-file


            for editing use 'i', it will enable the editor for insertion. Keep in mind top most(oldest) commit cannot be squashed as there is no previous commit to combine with. So it has to be picked or 'p'. Use 'Esc' to exit insert mode.



            3) Now, save the editor with the following command.
            :wq



            When you save that, you have a single commit that introduces the changes of all three previous commits.



            Hope this will help you.






            share|improve this answer





















            • 4





              Perhaps this is obvious to others but, when you say "git rebase -i", you also need to specify which commit you start at. This is something I didn't realize when I tried following this example. So, in this example, it'd be "git rebase -i xxxxx" where xxxxx is the commit right before f7f3f6d chronologically. Once I figured that out, everything worked out exactly as described above.

              – nukeguy
              Apr 22 '16 at 19:26











            • That's interesting @nukeguy, I didn't have any issue not specifying a specific commit. It just defaulted to what was there.

              – JCrooks
              Jan 25 '17 at 20:23
















            61














            This is the way I generally follow to combine multiple Commits into a single commit before I push the code.



            To achieve this, I suggest you use 'squash' concept provided by GIT.



            Follow the below steps.



            1) git rebase -i master (instead of master you can also use a specific commit)



            open the rebase interactive editor, where it will show all your commits. Basically where you need to identify the commits which you want to merge into a single commit.



            Imagine these are your commits and shown something like this in the editor.



            pick f7f3f6d changed my name a bit    
            pick 310154e updated README formatting and added blame
            pick a5f4a0d added cat-file


            It's important to note that these commits are listed in the opposite order than you normally see them using the log command. Means, the older commit will be shown first.



            2) Change 'pick' to 'squash' for last committed changes. something like shown below. Doing that so, your last 2 commits will be merged with the first one.



            pick f7f3f6d changed my name a bit         
            squash 310154e updated README formatting and added blame
            squash a5f4a0d added cat-file


            You can also use short form if you have lot of commits to combine:



            p f7f3f6d changed my name a bit         
            s 310154e updated README formatting and added blame
            s a5f4a0d added cat-file


            for editing use 'i', it will enable the editor for insertion. Keep in mind top most(oldest) commit cannot be squashed as there is no previous commit to combine with. So it has to be picked or 'p'. Use 'Esc' to exit insert mode.



            3) Now, save the editor with the following command.
            :wq



            When you save that, you have a single commit that introduces the changes of all three previous commits.



            Hope this will help you.






            share|improve this answer





















            • 4





              Perhaps this is obvious to others but, when you say "git rebase -i", you also need to specify which commit you start at. This is something I didn't realize when I tried following this example. So, in this example, it'd be "git rebase -i xxxxx" where xxxxx is the commit right before f7f3f6d chronologically. Once I figured that out, everything worked out exactly as described above.

              – nukeguy
              Apr 22 '16 at 19:26











            • That's interesting @nukeguy, I didn't have any issue not specifying a specific commit. It just defaulted to what was there.

              – JCrooks
              Jan 25 '17 at 20:23














            61












            61








            61







            This is the way I generally follow to combine multiple Commits into a single commit before I push the code.



            To achieve this, I suggest you use 'squash' concept provided by GIT.



            Follow the below steps.



            1) git rebase -i master (instead of master you can also use a specific commit)



            open the rebase interactive editor, where it will show all your commits. Basically where you need to identify the commits which you want to merge into a single commit.



            Imagine these are your commits and shown something like this in the editor.



            pick f7f3f6d changed my name a bit    
            pick 310154e updated README formatting and added blame
            pick a5f4a0d added cat-file


            It's important to note that these commits are listed in the opposite order than you normally see them using the log command. Means, the older commit will be shown first.



            2) Change 'pick' to 'squash' for last committed changes. something like shown below. Doing that so, your last 2 commits will be merged with the first one.



            pick f7f3f6d changed my name a bit         
            squash 310154e updated README formatting and added blame
            squash a5f4a0d added cat-file


            You can also use short form if you have lot of commits to combine:



            p f7f3f6d changed my name a bit         
            s 310154e updated README formatting and added blame
            s a5f4a0d added cat-file


            for editing use 'i', it will enable the editor for insertion. Keep in mind top most(oldest) commit cannot be squashed as there is no previous commit to combine with. So it has to be picked or 'p'. Use 'Esc' to exit insert mode.



            3) Now, save the editor with the following command.
            :wq



            When you save that, you have a single commit that introduces the changes of all three previous commits.



            Hope this will help you.






            share|improve this answer















            This is the way I generally follow to combine multiple Commits into a single commit before I push the code.



            To achieve this, I suggest you use 'squash' concept provided by GIT.



            Follow the below steps.



            1) git rebase -i master (instead of master you can also use a specific commit)



            open the rebase interactive editor, where it will show all your commits. Basically where you need to identify the commits which you want to merge into a single commit.



            Imagine these are your commits and shown something like this in the editor.



            pick f7f3f6d changed my name a bit    
            pick 310154e updated README formatting and added blame
            pick a5f4a0d added cat-file


            It's important to note that these commits are listed in the opposite order than you normally see them using the log command. Means, the older commit will be shown first.



            2) Change 'pick' to 'squash' for last committed changes. something like shown below. Doing that so, your last 2 commits will be merged with the first one.



            pick f7f3f6d changed my name a bit         
            squash 310154e updated README formatting and added blame
            squash a5f4a0d added cat-file


            You can also use short form if you have lot of commits to combine:



            p f7f3f6d changed my name a bit         
            s 310154e updated README formatting and added blame
            s a5f4a0d added cat-file


            for editing use 'i', it will enable the editor for insertion. Keep in mind top most(oldest) commit cannot be squashed as there is no previous commit to combine with. So it has to be picked or 'p'. Use 'Esc' to exit insert mode.



            3) Now, save the editor with the following command.
            :wq



            When you save that, you have a single commit that introduces the changes of all three previous commits.



            Hope this will help you.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Feb 16 at 9:45









            harshainfo

            606




            606










            answered Nov 28 '12 at 11:58









            Kondal KolipakaKondal Kolipaka

            2,3321319




            2,3321319








            • 4





              Perhaps this is obvious to others but, when you say "git rebase -i", you also need to specify which commit you start at. This is something I didn't realize when I tried following this example. So, in this example, it'd be "git rebase -i xxxxx" where xxxxx is the commit right before f7f3f6d chronologically. Once I figured that out, everything worked out exactly as described above.

              – nukeguy
              Apr 22 '16 at 19:26











            • That's interesting @nukeguy, I didn't have any issue not specifying a specific commit. It just defaulted to what was there.

              – JCrooks
              Jan 25 '17 at 20:23














            • 4





              Perhaps this is obvious to others but, when you say "git rebase -i", you also need to specify which commit you start at. This is something I didn't realize when I tried following this example. So, in this example, it'd be "git rebase -i xxxxx" where xxxxx is the commit right before f7f3f6d chronologically. Once I figured that out, everything worked out exactly as described above.

              – nukeguy
              Apr 22 '16 at 19:26











            • That's interesting @nukeguy, I didn't have any issue not specifying a specific commit. It just defaulted to what was there.

              – JCrooks
              Jan 25 '17 at 20:23








            4




            4





            Perhaps this is obvious to others but, when you say "git rebase -i", you also need to specify which commit you start at. This is something I didn't realize when I tried following this example. So, in this example, it'd be "git rebase -i xxxxx" where xxxxx is the commit right before f7f3f6d chronologically. Once I figured that out, everything worked out exactly as described above.

            – nukeguy
            Apr 22 '16 at 19:26





            Perhaps this is obvious to others but, when you say "git rebase -i", you also need to specify which commit you start at. This is something I didn't realize when I tried following this example. So, in this example, it'd be "git rebase -i xxxxx" where xxxxx is the commit right before f7f3f6d chronologically. Once I figured that out, everything worked out exactly as described above.

            – nukeguy
            Apr 22 '16 at 19:26













            That's interesting @nukeguy, I didn't have any issue not specifying a specific commit. It just defaulted to what was there.

            – JCrooks
            Jan 25 '17 at 20:23





            That's interesting @nukeguy, I didn't have any issue not specifying a specific commit. It just defaulted to what was there.

            – JCrooks
            Jan 25 '17 at 20:23











            11














            First: nothing tells you to only have one commit per branch per push: a push is a publication mechanism allowing you to publish a local history (i.e. a collection of commits) on a remote repo.



            Second: a git merge --no-ff topical_xFeature would record on master as a single commit your topic work, before pushing master.

            (That way, you keep topical_xFeature around for further evolutions, that you can record on master as a single new commit on the next merge --no-ff.

            If getting rid of topical_xFeature is the goal, then git merge --squash is the right option, as detailed in Brian Campbell's answer.)






            share|improve this answer


























            • I think that --squash, not --no-ff is what you want. --no-ff would create a merge commit, but also leave all of the commits from topical_xFeature.

              – Brian Campbell
              Apr 19 '11 at 19:59











            • @Brian: I agree and upvoted your answer, but I first thought of the --no-ff option because I wanted to keep topical_feature branch around, and just record a single commit on master branch.

              – VonC
              Apr 19 '11 at 20:15
















            11














            First: nothing tells you to only have one commit per branch per push: a push is a publication mechanism allowing you to publish a local history (i.e. a collection of commits) on a remote repo.



            Second: a git merge --no-ff topical_xFeature would record on master as a single commit your topic work, before pushing master.

            (That way, you keep topical_xFeature around for further evolutions, that you can record on master as a single new commit on the next merge --no-ff.

            If getting rid of topical_xFeature is the goal, then git merge --squash is the right option, as detailed in Brian Campbell's answer.)






            share|improve this answer


























            • I think that --squash, not --no-ff is what you want. --no-ff would create a merge commit, but also leave all of the commits from topical_xFeature.

              – Brian Campbell
              Apr 19 '11 at 19:59











            • @Brian: I agree and upvoted your answer, but I first thought of the --no-ff option because I wanted to keep topical_feature branch around, and just record a single commit on master branch.

              – VonC
              Apr 19 '11 at 20:15














            11












            11








            11







            First: nothing tells you to only have one commit per branch per push: a push is a publication mechanism allowing you to publish a local history (i.e. a collection of commits) on a remote repo.



            Second: a git merge --no-ff topical_xFeature would record on master as a single commit your topic work, before pushing master.

            (That way, you keep topical_xFeature around for further evolutions, that you can record on master as a single new commit on the next merge --no-ff.

            If getting rid of topical_xFeature is the goal, then git merge --squash is the right option, as detailed in Brian Campbell's answer.)






            share|improve this answer















            First: nothing tells you to only have one commit per branch per push: a push is a publication mechanism allowing you to publish a local history (i.e. a collection of commits) on a remote repo.



            Second: a git merge --no-ff topical_xFeature would record on master as a single commit your topic work, before pushing master.

            (That way, you keep topical_xFeature around for further evolutions, that you can record on master as a single new commit on the next merge --no-ff.

            If getting rid of topical_xFeature is the goal, then git merge --squash is the right option, as detailed in Brian Campbell's answer.)







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited May 23 '17 at 10:31









            Community

            11




            11










            answered Apr 19 '11 at 19:51









            VonCVonC

            851k30127133273




            851k30127133273













            • I think that --squash, not --no-ff is what you want. --no-ff would create a merge commit, but also leave all of the commits from topical_xFeature.

              – Brian Campbell
              Apr 19 '11 at 19:59











            • @Brian: I agree and upvoted your answer, but I first thought of the --no-ff option because I wanted to keep topical_feature branch around, and just record a single commit on master branch.

              – VonC
              Apr 19 '11 at 20:15



















            • I think that --squash, not --no-ff is what you want. --no-ff would create a merge commit, but also leave all of the commits from topical_xFeature.

              – Brian Campbell
              Apr 19 '11 at 19:59











            • @Brian: I agree and upvoted your answer, but I first thought of the --no-ff option because I wanted to keep topical_feature branch around, and just record a single commit on master branch.

              – VonC
              Apr 19 '11 at 20:15

















            I think that --squash, not --no-ff is what you want. --no-ff would create a merge commit, but also leave all of the commits from topical_xFeature.

            – Brian Campbell
            Apr 19 '11 at 19:59





            I think that --squash, not --no-ff is what you want. --no-ff would create a merge commit, but also leave all of the commits from topical_xFeature.

            – Brian Campbell
            Apr 19 '11 at 19:59













            @Brian: I agree and upvoted your answer, but I first thought of the --no-ff option because I wanted to keep topical_feature branch around, and just record a single commit on master branch.

            – VonC
            Apr 19 '11 at 20:15





            @Brian: I agree and upvoted your answer, but I first thought of the --no-ff option because I wanted to keep topical_feature branch around, and just record a single commit on master branch.

            – VonC
            Apr 19 '11 at 20:15











            8














            Switch to the master branch and make sure you are up to date.



            git checkout master


            git fetch this may be necessary (depending on your git config) to receive updates on origin/master



            git pull


            Merge the feature branch into the master branch.



            git merge feature_branch


            Reset the master branch to origin's state.



            git reset origin/master


            Git now considers all changes as unstaged changes.
            We can add these changes as one commit.
            Adding . will also add untracked files.



            git add --all

            git commit


            Ref: https://makandracards.com/makandra/527-squash-several-git-commits-into-a-single-commit






            share|improve this answer



















            • 2





              this answer is easy to follow and really easy to visualize.

              – jokab
              Dec 14 '17 at 3:53


















            8














            Switch to the master branch and make sure you are up to date.



            git checkout master


            git fetch this may be necessary (depending on your git config) to receive updates on origin/master



            git pull


            Merge the feature branch into the master branch.



            git merge feature_branch


            Reset the master branch to origin's state.



            git reset origin/master


            Git now considers all changes as unstaged changes.
            We can add these changes as one commit.
            Adding . will also add untracked files.



            git add --all

            git commit


            Ref: https://makandracards.com/makandra/527-squash-several-git-commits-into-a-single-commit






            share|improve this answer



















            • 2





              this answer is easy to follow and really easy to visualize.

              – jokab
              Dec 14 '17 at 3:53
















            8












            8








            8







            Switch to the master branch and make sure you are up to date.



            git checkout master


            git fetch this may be necessary (depending on your git config) to receive updates on origin/master



            git pull


            Merge the feature branch into the master branch.



            git merge feature_branch


            Reset the master branch to origin's state.



            git reset origin/master


            Git now considers all changes as unstaged changes.
            We can add these changes as one commit.
            Adding . will also add untracked files.



            git add --all

            git commit


            Ref: https://makandracards.com/makandra/527-squash-several-git-commits-into-a-single-commit






            share|improve this answer













            Switch to the master branch and make sure you are up to date.



            git checkout master


            git fetch this may be necessary (depending on your git config) to receive updates on origin/master



            git pull


            Merge the feature branch into the master branch.



            git merge feature_branch


            Reset the master branch to origin's state.



            git reset origin/master


            Git now considers all changes as unstaged changes.
            We can add these changes as one commit.
            Adding . will also add untracked files.



            git add --all

            git commit


            Ref: https://makandracards.com/makandra/527-squash-several-git-commits-into-a-single-commit







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jul 25 '16 at 19:36









            shiva kumarshiva kumar

            3,16821519




            3,16821519








            • 2





              this answer is easy to follow and really easy to visualize.

              – jokab
              Dec 14 '17 at 3:53
















            • 2





              this answer is easy to follow and really easy to visualize.

              – jokab
              Dec 14 '17 at 3:53










            2




            2





            this answer is easy to follow and really easy to visualize.

            – jokab
            Dec 14 '17 at 3:53







            this answer is easy to follow and really easy to visualize.

            – jokab
            Dec 14 '17 at 3:53













            1














            1) First choose which commit you want everything to come after.



            git reflog
            5976f2b HEAD@{0}: commit: Fix conflicts
            80e85a1 HEAD@{1}: commit: Add feature
            b860ddb HEAD@{2}: commit: Add something


            2) Reset to your selected head (I have chosen HEAD@{2})



            git reset b860ddb --soft


            3) git status (just to be sure)



            4) Add your new commit



            git commit -m "Add new commit"


            Note: HEAD@{0} & HEAD@{1} Are now merged into 1 commit, this can be done for multiple commits also.



            git reflog again should display:



            git reflog
            5976f2b HEAD@{0}: commit: Add new commit
            b860ddb HEAD@{1}: commit: Add something





            share|improve this answer




























              1














              1) First choose which commit you want everything to come after.



              git reflog
              5976f2b HEAD@{0}: commit: Fix conflicts
              80e85a1 HEAD@{1}: commit: Add feature
              b860ddb HEAD@{2}: commit: Add something


              2) Reset to your selected head (I have chosen HEAD@{2})



              git reset b860ddb --soft


              3) git status (just to be sure)



              4) Add your new commit



              git commit -m "Add new commit"


              Note: HEAD@{0} & HEAD@{1} Are now merged into 1 commit, this can be done for multiple commits also.



              git reflog again should display:



              git reflog
              5976f2b HEAD@{0}: commit: Add new commit
              b860ddb HEAD@{1}: commit: Add something





              share|improve this answer


























                1












                1








                1







                1) First choose which commit you want everything to come after.



                git reflog
                5976f2b HEAD@{0}: commit: Fix conflicts
                80e85a1 HEAD@{1}: commit: Add feature
                b860ddb HEAD@{2}: commit: Add something


                2) Reset to your selected head (I have chosen HEAD@{2})



                git reset b860ddb --soft


                3) git status (just to be sure)



                4) Add your new commit



                git commit -m "Add new commit"


                Note: HEAD@{0} & HEAD@{1} Are now merged into 1 commit, this can be done for multiple commits also.



                git reflog again should display:



                git reflog
                5976f2b HEAD@{0}: commit: Add new commit
                b860ddb HEAD@{1}: commit: Add something





                share|improve this answer













                1) First choose which commit you want everything to come after.



                git reflog
                5976f2b HEAD@{0}: commit: Fix conflicts
                80e85a1 HEAD@{1}: commit: Add feature
                b860ddb HEAD@{2}: commit: Add something


                2) Reset to your selected head (I have chosen HEAD@{2})



                git reset b860ddb --soft


                3) git status (just to be sure)



                4) Add your new commit



                git commit -m "Add new commit"


                Note: HEAD@{0} & HEAD@{1} Are now merged into 1 commit, this can be done for multiple commits also.



                git reflog again should display:



                git reflog
                5976f2b HEAD@{0}: commit: Add new commit
                b860ddb HEAD@{1}: commit: Add something






                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 16 '18 at 10:48









                Eddy EkofoEddy Ekofo

                966




                966






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f5721566%2fcombining-multiple-commits-into-one-prior-to-push%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Xamarin.iOS Cant Deploy on Iphone

                    Glorious Revolution

                    Dulmage-Mendelsohn matrix decomposition in Python