问题
I am trying to validate that my changes aren't breaking existing code. To do that, after committing my changes I run the code and I need to validate the output with one previous commit(which does not have my changes). So, after the validation is done my changes must still be on the latest commit.
回答1:
The easiest way to go here is probably to just checkout the previous commit in the detached HEAD state:
git checkout HEAD~1
You should see a message something like this:
You are in 'detached HEAD' state...
From this point, you may build your project, and test it. And when you want to go back to the HEAD of the branch, it is easy to do that:
git checkout master # or replace 'master' by the branch name
回答2:
Tim's answer works, but I would suggest that you're actually following a workflow that is less than ideal. Mind you, I could be misunderstanding your question.
If you want to make changes without breaking existing code, you're better off checking out a new branch and making changes in that new branch (called, say, test1). You can then freely test your altered code in test1 while preserving the unaltered code in your existing branch, which was probably master or (better) develop.
Once you've tested your new branch and are happy with your changes, you can merge or rebase test1 into master/develop.
This avoids entering detached head states, allows for comparing multiple different code versions (via multiple new branches) and generally just harnesses the wonderful branching capabilities that really make Git shine.
回答3:
Just want to make sure, are you using team city or some other auto build tool? In that case you will have option to specify GIT path and version of previous commit. If you are just trying to build locally, you will need to have previous code locally and execute.
Thanks Rakesh Yadav
回答4:
Checkout the previous commit into another folder so that the current folder can be unaffected.
Solution 1:
Make a new clone and check out the very commit.
git clone <url> -- another_folder
cd another_folder
git checkout <commit>
#run the code
However it would cost much time and space if the repository is very big or the network is not well. You already have the commit in the local repository, so you could use the local one as the remote repository:
git clone <url_to_the_existing_local_repository> -- another_folder
Also, you could use the local repository as a reference:
git clone <url> --reference=<url_to_the_existing_local_repository> -- another_folder
The difference is that the former's remote is the existing local repository and the latter's is the remote repository. You could delete the new folder when it's not needed any more.
Solution 2:
Use git-worktree if you are using Git of a new version (after 2.10.0 or newer).
cd <path_to_the_repository>
git worktree add <path_to_another_folder> <the_previous_commit>
cd <path_to_another_folder>
#run the code
#after everything is done, you could just delete the new folder
rm -rf <path_to_another_folder>
cd <path_to_the_repository>
git worktree prune
git worktree add creates a new folder and checks out the commit into the new folder. You could run git commands in that folder. The folder is another work tree that shares the same .git with the default work tree. Git allows to create multiple work trees.
回答5:
Git provides the bisect command for this very purpose: "Use binary search to find the commit that introduced a bug".
Start with:
git bisect start
git bisect bad # mark the current commit as bad
git bisect good 5678..cded # mark a previous commit as good
git bisect will then checks out the median commit and give you an estimation of how many steps remain until the commit that introduces the regression is found:
Bisecting: 20 revisions left to test after this (roughly 4 steps)
Test the checked out version, mark it as good, or bad, rinse and repeat until you found the "culprit".
See the full documentation of the bisect command on the [reference documentation]((https://git-scm.com/docs/git-bisect).
来源：https://stackoverflow.com/questions/48700293/execute-code-on-the-previous-commit-without-hard-resetting-the-latest-commit