How to re-commit a past commit if someone overwrote my commit

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
39
down vote

favorite
6












Just faced an issue where someone overwritten my whole commit and there are lot of other commits on top of this, now I have to re-commit that particular commit. Any help would be appreciated.



Someone got merge conflict and while merging he lost my all changes. I don't know what he did, but my changes are not there. IN history my commit is there but If I am seeing above his merge my changes are reverted.



Now I cannot revert his merge commit because it contains lots of files as compare to me also I don't want to change each file one by one manually. Is there any way to get back my changes without effecting other's.










share|improve this question



























    up vote
    39
    down vote

    favorite
    6












    Just faced an issue where someone overwritten my whole commit and there are lot of other commits on top of this, now I have to re-commit that particular commit. Any help would be appreciated.



    Someone got merge conflict and while merging he lost my all changes. I don't know what he did, but my changes are not there. IN history my commit is there but If I am seeing above his merge my changes are reverted.



    Now I cannot revert his merge commit because it contains lots of files as compare to me also I don't want to change each file one by one manually. Is there any way to get back my changes without effecting other's.










    share|improve this question

























      up vote
      39
      down vote

      favorite
      6









      up vote
      39
      down vote

      favorite
      6






      6





      Just faced an issue where someone overwritten my whole commit and there are lot of other commits on top of this, now I have to re-commit that particular commit. Any help would be appreciated.



      Someone got merge conflict and while merging he lost my all changes. I don't know what he did, but my changes are not there. IN history my commit is there but If I am seeing above his merge my changes are reverted.



      Now I cannot revert his merge commit because it contains lots of files as compare to me also I don't want to change each file one by one manually. Is there any way to get back my changes without effecting other's.










      share|improve this question















      Just faced an issue where someone overwritten my whole commit and there are lot of other commits on top of this, now I have to re-commit that particular commit. Any help would be appreciated.



      Someone got merge conflict and while merging he lost my all changes. I don't know what he did, but my changes are not there. IN history my commit is there but If I am seeing above his merge my changes are reverted.



      Now I cannot revert his merge commit because it contains lots of files as compare to me also I don't want to change each file one by one manually. Is there any way to get back my changes without effecting other's.







      git






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Sep 5 at 13:52









      Pipe

      135315




      135315










      asked Sep 5 at 3:58









      CuriousGeek

      8381716




      8381716






















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          50
          down vote



          accepted










          You can do that typing the following commands:



          $ git reflog


          then select the ID of the commit that you want to retrieve.



          Then type the following command:



          $ git cherry-pick <'ID'>


          Instead of <'ID'> enter the ID from the above reflog.



          Then you will have the changes of that commit.



          Now check if anything is still remaining by:



          $ git status


          If anything is in unstaged commit, then add it by the following commands and commit:



          $ git add -A //Any other option or the name of the file with the path that you want to commit
          $ git commit -m "Your message here for that commit"
          $ git push


          I hope this answer is what you are expecting for.






          share|improve this answer





























            up vote
            31
            down vote













            The easiest way to fix this is usually, as Code_Ninja suggested, to use git cherry-pick to re-commit your changes. Usually, the method recommended by Venkataraman R won't work because Git will tell you that there is nothing to merge. (If it does work, it's OK too.) The exact details depend on the situation. For posterity, though, let's look at the most common way that this happens.




            Someone got merge conflict and while merging he lost my all changes.




            This is very easy for the "someone" to do. Let's give "someone" a name; let's call him Carl the Careless. Carl runs:



            git merge carls-feature


            or perhaps even:



            git pull


            (though I recommend that any beginner, like Carl here, avoid git pull—it's better that he run git merge directly, so that he can get an idea about what he's doing).



            In any case, Carl now sees this:



            Auto-merging somefile.ext
            CONFLICT (content): Merge conflict in somefile.ext


            Poor Carl panics, searches the web (perhaps even StackOverflow) for advice, and rather than looking at, say, How to resolve merge conflicts in Git,1 Carl just runs:



            git checkout --ours somefile.ext
            git add somefile.ext
            git commit


            Carl has just wiped out your work!



            Remember, the goal of a merge is to combine work. Git will try to do this on its own, but sometimes Git is not able to complete the process by itself. In these cases, Git stops and gets help from its human operator.



            This human operator—you, if you're the one with the merge conflict!—is in full, complete, 100% control of the merge result. Git will believe you, even if you tell it that the correct result is to ignore the other guy's work entirely and just take your version.



            (Note that even if Git thinks it has correctly merged two people's different changes, Git does not always get it right. It's still your responsibility to check that Git got it right. It's a good idea to have some sort of thorough test system you can use. Git is just following simple text-combining rules, that happen to work really well for many cases.)




            1The accepted answer here recommends using git mergetool with vimdiff as the tool. I happen to dislike git mergetool, and I recommend reading through the other answers too, and experimenting to see what works best for you. But if git mergetool works well for you, that's fine. Note that git mergetool can use other merge tools than vimdiff; if you have a merge tool you prefer, git mergetool is likely to be able to run it. The Pro Git book has additional advice, including a chapter on advanced merging.






            share|improve this answer
















            • 1




              Thanks for so much information, by creating branch worked for me, but I am agree with you that I should follow cherry picking method in this type of case. Hence changing my accepted answer.
              – CuriousGeek
              Sep 5 at 5:53










            • To elaborate on why merging in a branch of the commit shouldn't work, it's because typically the commit is already in the history (in whatever shared branch you're using). You can't merge in a commit that is already there. The cherry-picking approach would work instead because it creates an entirely new commit (which is simply duplicating the changes). Git has to be used to not merging in commits that are already there because branches are really just a pointer to some commit (which in turn points to its parents, going allll the way back). So branches are supposed to share many commits!
              – Kat
              Sep 10 at 18:44

















            up vote
            8
            down vote













            You can create a branch out of your old commit and then follow the git process to merge changes from master to your branch and handle merge conflict.



            Below steps for create a branch out of your old commit and checkout the same.



            git branch branchname <sha1 of your old commit>
            git checkout branchname


            or



            git checkout -b branchname <sha1 of your old commit>





            share|improve this answer




















            • thanks @Venkataraman, But we don't have permissions for creating branch. Are you talking about local branch?
              – CuriousGeek
              Sep 5 at 4:36










            • @CuriousGeek, Yes. I am talking about local branch. You can later set-upstream for this local branch.
              – Venkataraman R
              Sep 5 at 4:41






            • 1




              this worked for me thanks :)
              – CuriousGeek
              Sep 5 at 5:29






            • 2




              As an aside, git branch (and similar like git checkout -b <new branch name>) is always a local branch. Almost every kind of change you'd typically make in git is local until you push it to a remote repo. You can always choose to keep things locally only or to only push certain branches.
              – Kat
              Sep 10 at 18:41










            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',
            convertImagesToLinks: true,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            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%2f52176834%2fhow-to-re-commit-a-past-commit-if-someone-overwrote-my-commit%23new-answer', 'question_page');

            );

            Post as a guest






























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            50
            down vote



            accepted










            You can do that typing the following commands:



            $ git reflog


            then select the ID of the commit that you want to retrieve.



            Then type the following command:



            $ git cherry-pick <'ID'>


            Instead of <'ID'> enter the ID from the above reflog.



            Then you will have the changes of that commit.



            Now check if anything is still remaining by:



            $ git status


            If anything is in unstaged commit, then add it by the following commands and commit:



            $ git add -A //Any other option or the name of the file with the path that you want to commit
            $ git commit -m "Your message here for that commit"
            $ git push


            I hope this answer is what you are expecting for.






            share|improve this answer


























              up vote
              50
              down vote



              accepted










              You can do that typing the following commands:



              $ git reflog


              then select the ID of the commit that you want to retrieve.



              Then type the following command:



              $ git cherry-pick <'ID'>


              Instead of <'ID'> enter the ID from the above reflog.



              Then you will have the changes of that commit.



              Now check if anything is still remaining by:



              $ git status


              If anything is in unstaged commit, then add it by the following commands and commit:



              $ git add -A //Any other option or the name of the file with the path that you want to commit
              $ git commit -m "Your message here for that commit"
              $ git push


              I hope this answer is what you are expecting for.






              share|improve this answer
























                up vote
                50
                down vote



                accepted







                up vote
                50
                down vote



                accepted






                You can do that typing the following commands:



                $ git reflog


                then select the ID of the commit that you want to retrieve.



                Then type the following command:



                $ git cherry-pick <'ID'>


                Instead of <'ID'> enter the ID from the above reflog.



                Then you will have the changes of that commit.



                Now check if anything is still remaining by:



                $ git status


                If anything is in unstaged commit, then add it by the following commands and commit:



                $ git add -A //Any other option or the name of the file with the path that you want to commit
                $ git commit -m "Your message here for that commit"
                $ git push


                I hope this answer is what you are expecting for.






                share|improve this answer














                You can do that typing the following commands:



                $ git reflog


                then select the ID of the commit that you want to retrieve.



                Then type the following command:



                $ git cherry-pick <'ID'>


                Instead of <'ID'> enter the ID from the above reflog.



                Then you will have the changes of that commit.



                Now check if anything is still remaining by:



                $ git status


                If anything is in unstaged commit, then add it by the following commands and commit:



                $ git add -A //Any other option or the name of the file with the path that you want to commit
                $ git commit -m "Your message here for that commit"
                $ git push


                I hope this answer is what you are expecting for.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Sep 5 at 15:44









                hjpotter92

                56.6k1988126




                56.6k1988126










                answered Sep 5 at 4:56









                Code_Ninja

                975522




                975522






















                    up vote
                    31
                    down vote













                    The easiest way to fix this is usually, as Code_Ninja suggested, to use git cherry-pick to re-commit your changes. Usually, the method recommended by Venkataraman R won't work because Git will tell you that there is nothing to merge. (If it does work, it's OK too.) The exact details depend on the situation. For posterity, though, let's look at the most common way that this happens.




                    Someone got merge conflict and while merging he lost my all changes.




                    This is very easy for the "someone" to do. Let's give "someone" a name; let's call him Carl the Careless. Carl runs:



                    git merge carls-feature


                    or perhaps even:



                    git pull


                    (though I recommend that any beginner, like Carl here, avoid git pull—it's better that he run git merge directly, so that he can get an idea about what he's doing).



                    In any case, Carl now sees this:



                    Auto-merging somefile.ext
                    CONFLICT (content): Merge conflict in somefile.ext


                    Poor Carl panics, searches the web (perhaps even StackOverflow) for advice, and rather than looking at, say, How to resolve merge conflicts in Git,1 Carl just runs:



                    git checkout --ours somefile.ext
                    git add somefile.ext
                    git commit


                    Carl has just wiped out your work!



                    Remember, the goal of a merge is to combine work. Git will try to do this on its own, but sometimes Git is not able to complete the process by itself. In these cases, Git stops and gets help from its human operator.



                    This human operator—you, if you're the one with the merge conflict!—is in full, complete, 100% control of the merge result. Git will believe you, even if you tell it that the correct result is to ignore the other guy's work entirely and just take your version.



                    (Note that even if Git thinks it has correctly merged two people's different changes, Git does not always get it right. It's still your responsibility to check that Git got it right. It's a good idea to have some sort of thorough test system you can use. Git is just following simple text-combining rules, that happen to work really well for many cases.)




                    1The accepted answer here recommends using git mergetool with vimdiff as the tool. I happen to dislike git mergetool, and I recommend reading through the other answers too, and experimenting to see what works best for you. But if git mergetool works well for you, that's fine. Note that git mergetool can use other merge tools than vimdiff; if you have a merge tool you prefer, git mergetool is likely to be able to run it. The Pro Git book has additional advice, including a chapter on advanced merging.






                    share|improve this answer
















                    • 1




                      Thanks for so much information, by creating branch worked for me, but I am agree with you that I should follow cherry picking method in this type of case. Hence changing my accepted answer.
                      – CuriousGeek
                      Sep 5 at 5:53










                    • To elaborate on why merging in a branch of the commit shouldn't work, it's because typically the commit is already in the history (in whatever shared branch you're using). You can't merge in a commit that is already there. The cherry-picking approach would work instead because it creates an entirely new commit (which is simply duplicating the changes). Git has to be used to not merging in commits that are already there because branches are really just a pointer to some commit (which in turn points to its parents, going allll the way back). So branches are supposed to share many commits!
                      – Kat
                      Sep 10 at 18:44














                    up vote
                    31
                    down vote













                    The easiest way to fix this is usually, as Code_Ninja suggested, to use git cherry-pick to re-commit your changes. Usually, the method recommended by Venkataraman R won't work because Git will tell you that there is nothing to merge. (If it does work, it's OK too.) The exact details depend on the situation. For posterity, though, let's look at the most common way that this happens.




                    Someone got merge conflict and while merging he lost my all changes.




                    This is very easy for the "someone" to do. Let's give "someone" a name; let's call him Carl the Careless. Carl runs:



                    git merge carls-feature


                    or perhaps even:



                    git pull


                    (though I recommend that any beginner, like Carl here, avoid git pull—it's better that he run git merge directly, so that he can get an idea about what he's doing).



                    In any case, Carl now sees this:



                    Auto-merging somefile.ext
                    CONFLICT (content): Merge conflict in somefile.ext


                    Poor Carl panics, searches the web (perhaps even StackOverflow) for advice, and rather than looking at, say, How to resolve merge conflicts in Git,1 Carl just runs:



                    git checkout --ours somefile.ext
                    git add somefile.ext
                    git commit


                    Carl has just wiped out your work!



                    Remember, the goal of a merge is to combine work. Git will try to do this on its own, but sometimes Git is not able to complete the process by itself. In these cases, Git stops and gets help from its human operator.



                    This human operator—you, if you're the one with the merge conflict!—is in full, complete, 100% control of the merge result. Git will believe you, even if you tell it that the correct result is to ignore the other guy's work entirely and just take your version.



                    (Note that even if Git thinks it has correctly merged two people's different changes, Git does not always get it right. It's still your responsibility to check that Git got it right. It's a good idea to have some sort of thorough test system you can use. Git is just following simple text-combining rules, that happen to work really well for many cases.)




                    1The accepted answer here recommends using git mergetool with vimdiff as the tool. I happen to dislike git mergetool, and I recommend reading through the other answers too, and experimenting to see what works best for you. But if git mergetool works well for you, that's fine. Note that git mergetool can use other merge tools than vimdiff; if you have a merge tool you prefer, git mergetool is likely to be able to run it. The Pro Git book has additional advice, including a chapter on advanced merging.






                    share|improve this answer
















                    • 1




                      Thanks for so much information, by creating branch worked for me, but I am agree with you that I should follow cherry picking method in this type of case. Hence changing my accepted answer.
                      – CuriousGeek
                      Sep 5 at 5:53










                    • To elaborate on why merging in a branch of the commit shouldn't work, it's because typically the commit is already in the history (in whatever shared branch you're using). You can't merge in a commit that is already there. The cherry-picking approach would work instead because it creates an entirely new commit (which is simply duplicating the changes). Git has to be used to not merging in commits that are already there because branches are really just a pointer to some commit (which in turn points to its parents, going allll the way back). So branches are supposed to share many commits!
                      – Kat
                      Sep 10 at 18:44












                    up vote
                    31
                    down vote










                    up vote
                    31
                    down vote









                    The easiest way to fix this is usually, as Code_Ninja suggested, to use git cherry-pick to re-commit your changes. Usually, the method recommended by Venkataraman R won't work because Git will tell you that there is nothing to merge. (If it does work, it's OK too.) The exact details depend on the situation. For posterity, though, let's look at the most common way that this happens.




                    Someone got merge conflict and while merging he lost my all changes.




                    This is very easy for the "someone" to do. Let's give "someone" a name; let's call him Carl the Careless. Carl runs:



                    git merge carls-feature


                    or perhaps even:



                    git pull


                    (though I recommend that any beginner, like Carl here, avoid git pull—it's better that he run git merge directly, so that he can get an idea about what he's doing).



                    In any case, Carl now sees this:



                    Auto-merging somefile.ext
                    CONFLICT (content): Merge conflict in somefile.ext


                    Poor Carl panics, searches the web (perhaps even StackOverflow) for advice, and rather than looking at, say, How to resolve merge conflicts in Git,1 Carl just runs:



                    git checkout --ours somefile.ext
                    git add somefile.ext
                    git commit


                    Carl has just wiped out your work!



                    Remember, the goal of a merge is to combine work. Git will try to do this on its own, but sometimes Git is not able to complete the process by itself. In these cases, Git stops and gets help from its human operator.



                    This human operator—you, if you're the one with the merge conflict!—is in full, complete, 100% control of the merge result. Git will believe you, even if you tell it that the correct result is to ignore the other guy's work entirely and just take your version.



                    (Note that even if Git thinks it has correctly merged two people's different changes, Git does not always get it right. It's still your responsibility to check that Git got it right. It's a good idea to have some sort of thorough test system you can use. Git is just following simple text-combining rules, that happen to work really well for many cases.)




                    1The accepted answer here recommends using git mergetool with vimdiff as the tool. I happen to dislike git mergetool, and I recommend reading through the other answers too, and experimenting to see what works best for you. But if git mergetool works well for you, that's fine. Note that git mergetool can use other merge tools than vimdiff; if you have a merge tool you prefer, git mergetool is likely to be able to run it. The Pro Git book has additional advice, including a chapter on advanced merging.






                    share|improve this answer












                    The easiest way to fix this is usually, as Code_Ninja suggested, to use git cherry-pick to re-commit your changes. Usually, the method recommended by Venkataraman R won't work because Git will tell you that there is nothing to merge. (If it does work, it's OK too.) The exact details depend on the situation. For posterity, though, let's look at the most common way that this happens.




                    Someone got merge conflict and while merging he lost my all changes.




                    This is very easy for the "someone" to do. Let's give "someone" a name; let's call him Carl the Careless. Carl runs:



                    git merge carls-feature


                    or perhaps even:



                    git pull


                    (though I recommend that any beginner, like Carl here, avoid git pull—it's better that he run git merge directly, so that he can get an idea about what he's doing).



                    In any case, Carl now sees this:



                    Auto-merging somefile.ext
                    CONFLICT (content): Merge conflict in somefile.ext


                    Poor Carl panics, searches the web (perhaps even StackOverflow) for advice, and rather than looking at, say, How to resolve merge conflicts in Git,1 Carl just runs:



                    git checkout --ours somefile.ext
                    git add somefile.ext
                    git commit


                    Carl has just wiped out your work!



                    Remember, the goal of a merge is to combine work. Git will try to do this on its own, but sometimes Git is not able to complete the process by itself. In these cases, Git stops and gets help from its human operator.



                    This human operator—you, if you're the one with the merge conflict!—is in full, complete, 100% control of the merge result. Git will believe you, even if you tell it that the correct result is to ignore the other guy's work entirely and just take your version.



                    (Note that even if Git thinks it has correctly merged two people's different changes, Git does not always get it right. It's still your responsibility to check that Git got it right. It's a good idea to have some sort of thorough test system you can use. Git is just following simple text-combining rules, that happen to work really well for many cases.)




                    1The accepted answer here recommends using git mergetool with vimdiff as the tool. I happen to dislike git mergetool, and I recommend reading through the other answers too, and experimenting to see what works best for you. But if git mergetool works well for you, that's fine. Note that git mergetool can use other merge tools than vimdiff; if you have a merge tool you prefer, git mergetool is likely to be able to run it. The Pro Git book has additional advice, including a chapter on advanced merging.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Sep 5 at 5:40









                    torek

                    168k16207276




                    168k16207276







                    • 1




                      Thanks for so much information, by creating branch worked for me, but I am agree with you that I should follow cherry picking method in this type of case. Hence changing my accepted answer.
                      – CuriousGeek
                      Sep 5 at 5:53










                    • To elaborate on why merging in a branch of the commit shouldn't work, it's because typically the commit is already in the history (in whatever shared branch you're using). You can't merge in a commit that is already there. The cherry-picking approach would work instead because it creates an entirely new commit (which is simply duplicating the changes). Git has to be used to not merging in commits that are already there because branches are really just a pointer to some commit (which in turn points to its parents, going allll the way back). So branches are supposed to share many commits!
                      – Kat
                      Sep 10 at 18:44












                    • 1




                      Thanks for so much information, by creating branch worked for me, but I am agree with you that I should follow cherry picking method in this type of case. Hence changing my accepted answer.
                      – CuriousGeek
                      Sep 5 at 5:53










                    • To elaborate on why merging in a branch of the commit shouldn't work, it's because typically the commit is already in the history (in whatever shared branch you're using). You can't merge in a commit that is already there. The cherry-picking approach would work instead because it creates an entirely new commit (which is simply duplicating the changes). Git has to be used to not merging in commits that are already there because branches are really just a pointer to some commit (which in turn points to its parents, going allll the way back). So branches are supposed to share many commits!
                      – Kat
                      Sep 10 at 18:44







                    1




                    1




                    Thanks for so much information, by creating branch worked for me, but I am agree with you that I should follow cherry picking method in this type of case. Hence changing my accepted answer.
                    – CuriousGeek
                    Sep 5 at 5:53




                    Thanks for so much information, by creating branch worked for me, but I am agree with you that I should follow cherry picking method in this type of case. Hence changing my accepted answer.
                    – CuriousGeek
                    Sep 5 at 5:53












                    To elaborate on why merging in a branch of the commit shouldn't work, it's because typically the commit is already in the history (in whatever shared branch you're using). You can't merge in a commit that is already there. The cherry-picking approach would work instead because it creates an entirely new commit (which is simply duplicating the changes). Git has to be used to not merging in commits that are already there because branches are really just a pointer to some commit (which in turn points to its parents, going allll the way back). So branches are supposed to share many commits!
                    – Kat
                    Sep 10 at 18:44




                    To elaborate on why merging in a branch of the commit shouldn't work, it's because typically the commit is already in the history (in whatever shared branch you're using). You can't merge in a commit that is already there. The cherry-picking approach would work instead because it creates an entirely new commit (which is simply duplicating the changes). Git has to be used to not merging in commits that are already there because branches are really just a pointer to some commit (which in turn points to its parents, going allll the way back). So branches are supposed to share many commits!
                    – Kat
                    Sep 10 at 18:44










                    up vote
                    8
                    down vote













                    You can create a branch out of your old commit and then follow the git process to merge changes from master to your branch and handle merge conflict.



                    Below steps for create a branch out of your old commit and checkout the same.



                    git branch branchname <sha1 of your old commit>
                    git checkout branchname


                    or



                    git checkout -b branchname <sha1 of your old commit>





                    share|improve this answer




















                    • thanks @Venkataraman, But we don't have permissions for creating branch. Are you talking about local branch?
                      – CuriousGeek
                      Sep 5 at 4:36










                    • @CuriousGeek, Yes. I am talking about local branch. You can later set-upstream for this local branch.
                      – Venkataraman R
                      Sep 5 at 4:41






                    • 1




                      this worked for me thanks :)
                      – CuriousGeek
                      Sep 5 at 5:29






                    • 2




                      As an aside, git branch (and similar like git checkout -b <new branch name>) is always a local branch. Almost every kind of change you'd typically make in git is local until you push it to a remote repo. You can always choose to keep things locally only or to only push certain branches.
                      – Kat
                      Sep 10 at 18:41














                    up vote
                    8
                    down vote













                    You can create a branch out of your old commit and then follow the git process to merge changes from master to your branch and handle merge conflict.



                    Below steps for create a branch out of your old commit and checkout the same.



                    git branch branchname <sha1 of your old commit>
                    git checkout branchname


                    or



                    git checkout -b branchname <sha1 of your old commit>





                    share|improve this answer




















                    • thanks @Venkataraman, But we don't have permissions for creating branch. Are you talking about local branch?
                      – CuriousGeek
                      Sep 5 at 4:36










                    • @CuriousGeek, Yes. I am talking about local branch. You can later set-upstream for this local branch.
                      – Venkataraman R
                      Sep 5 at 4:41






                    • 1




                      this worked for me thanks :)
                      – CuriousGeek
                      Sep 5 at 5:29






                    • 2




                      As an aside, git branch (and similar like git checkout -b <new branch name>) is always a local branch. Almost every kind of change you'd typically make in git is local until you push it to a remote repo. You can always choose to keep things locally only or to only push certain branches.
                      – Kat
                      Sep 10 at 18:41












                    up vote
                    8
                    down vote










                    up vote
                    8
                    down vote









                    You can create a branch out of your old commit and then follow the git process to merge changes from master to your branch and handle merge conflict.



                    Below steps for create a branch out of your old commit and checkout the same.



                    git branch branchname <sha1 of your old commit>
                    git checkout branchname


                    or



                    git checkout -b branchname <sha1 of your old commit>





                    share|improve this answer












                    You can create a branch out of your old commit and then follow the git process to merge changes from master to your branch and handle merge conflict.



                    Below steps for create a branch out of your old commit and checkout the same.



                    git branch branchname <sha1 of your old commit>
                    git checkout branchname


                    or



                    git checkout -b branchname <sha1 of your old commit>






                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Sep 5 at 4:29









                    Venkataraman R

                    1,122717




                    1,122717











                    • thanks @Venkataraman, But we don't have permissions for creating branch. Are you talking about local branch?
                      – CuriousGeek
                      Sep 5 at 4:36










                    • @CuriousGeek, Yes. I am talking about local branch. You can later set-upstream for this local branch.
                      – Venkataraman R
                      Sep 5 at 4:41






                    • 1




                      this worked for me thanks :)
                      – CuriousGeek
                      Sep 5 at 5:29






                    • 2




                      As an aside, git branch (and similar like git checkout -b <new branch name>) is always a local branch. Almost every kind of change you'd typically make in git is local until you push it to a remote repo. You can always choose to keep things locally only or to only push certain branches.
                      – Kat
                      Sep 10 at 18:41
















                    • thanks @Venkataraman, But we don't have permissions for creating branch. Are you talking about local branch?
                      – CuriousGeek
                      Sep 5 at 4:36










                    • @CuriousGeek, Yes. I am talking about local branch. You can later set-upstream for this local branch.
                      – Venkataraman R
                      Sep 5 at 4:41






                    • 1




                      this worked for me thanks :)
                      – CuriousGeek
                      Sep 5 at 5:29






                    • 2




                      As an aside, git branch (and similar like git checkout -b <new branch name>) is always a local branch. Almost every kind of change you'd typically make in git is local until you push it to a remote repo. You can always choose to keep things locally only or to only push certain branches.
                      – Kat
                      Sep 10 at 18:41















                    thanks @Venkataraman, But we don't have permissions for creating branch. Are you talking about local branch?
                    – CuriousGeek
                    Sep 5 at 4:36




                    thanks @Venkataraman, But we don't have permissions for creating branch. Are you talking about local branch?
                    – CuriousGeek
                    Sep 5 at 4:36












                    @CuriousGeek, Yes. I am talking about local branch. You can later set-upstream for this local branch.
                    – Venkataraman R
                    Sep 5 at 4:41




                    @CuriousGeek, Yes. I am talking about local branch. You can later set-upstream for this local branch.
                    – Venkataraman R
                    Sep 5 at 4:41




                    1




                    1




                    this worked for me thanks :)
                    – CuriousGeek
                    Sep 5 at 5:29




                    this worked for me thanks :)
                    – CuriousGeek
                    Sep 5 at 5:29




                    2




                    2




                    As an aside, git branch (and similar like git checkout -b <new branch name>) is always a local branch. Almost every kind of change you'd typically make in git is local until you push it to a remote repo. You can always choose to keep things locally only or to only push certain branches.
                    – Kat
                    Sep 10 at 18:41




                    As an aside, git branch (and similar like git checkout -b <new branch name>) is always a local branch. Almost every kind of change you'd typically make in git is local until you push it to a remote repo. You can always choose to keep things locally only or to only push certain branches.
                    – Kat
                    Sep 10 at 18:41

















                     

                    draft saved


                    draft discarded















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52176834%2fhow-to-re-commit-a-past-commit-if-someone-overwrote-my-commit%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    這個網誌中的熱門文章

                    How to combine Bézier curves to a surface?

                    Mutual Information Always Non-negative

                    Why am i infinitely getting the same tweet with the Twitter Search API?