At the end of this question, here is an example of a problem encountered in revert
from the net.
I have tried to avoid using revert
as much as possible (maybe I haven't used it for more than 5 years), but I don't really understand when the problem occurs (no difference, changed but not changed, etc.), so I can't explain the danger of revert
at work.I would like to say that there were times when there were problems, but I don't know how to reproduce it, so I can't tell you when it's dangerous.)
"In the example below, ""there will be no difference"", but I feel that there are times when it comes out, so it's hard to be persuasive."
Question
revert
make sure that the difference does not appear when requesting a pull, or does the difference appear sometimes?It is recommended to do revert
of revert
when a problem occurs, but as development progresses, conflicts have occurred during revert
of revert
(although it's only a few days after revert
).
(I'm not in trouble right now because I wrote it in my past memory, and I don't know how to reproduce the problem in the first place, so it might be difficult to answer.Sorry)
For example, if you don't know much about git yet (searching for git reset, git revert, etc., but you can't tell the difference), you can make a pull request by making a commitment of $git revert
After the pull requests are merged, I feel that there are times when there is no difference when I create a new branch, add new functions, and create a pull request.(In this case, git revert
is not familiar with commitment, so you often want to return your commit error, git revert
is not appropriate, git commit --amend
or git reset --mixed
mentioned below is more appropriate.)
If I revert during development with my feature branch, I sometimes summarize (or organize) my commitments by doing git reset --mixed before the pull request is taken in.In this case, it is not useful to keep revert as a commitment history because I will revert to my own implementation errors during feature branch development or specification changes during development.
Once a pull request has passed, if there is a defect, press the revert button on GitHub to find out that there has been a defect in the past and that it has been canceled, so I think it is useful to leave a revert commit.You can't rewrite history because everyone is already watching it (everyone is starting from it).(However, I'm scared because I don't know the pattern where the difference doesn't come out, and the pattern where the change doesn't come out even though I changed it.I don't think there will be any problems in this case, but I'd like to explain the reason.)
I've written it up to here, but
In summary,
If you use git revert
to correct a simple commit error, such as a person who is not familiar with git simply made a wrong commit message or forgot to git add
the necessary file, you will experience problems such as git revert
( git commit --amend
is just a way to say it's prettier.)And if you already git push
, you will teach git push-f
to people who are still unfamiliar with it...)
(Snakefoot: It's not that he doesn't listen, but that he's under pressure to pay for it.)
A branch メイン merge into main branch, create pullik again!
Oh, there should be a difference, but the sweat doesn't come out
After merging pulliks on GitHub, do you ever realize that you are not ready to merge and revert?
After that, the problem is that I have reverted, but I would like to continue working on the reverted branch and issue a pullik again.That's the situation.
At this time, if you continue to work normally without thinking about it and issue a pullik, you will lose the changed amount that was returned.
It can lead to quite a big accident, so I'd like to write down how to deal with it.
Rather than having a problem with the operation called revert itself, I think there is a problem with understanding what revert is doing.Personally, I do not think revert itself is a problem (of course, I do not deny the decision to avoid revert after having agreed upon as a team).
First of all, git revert is a command to stack new commits that negate already loaded commits.This command does not involve historical tampering to delete an already loaded commit.
Therefore, if the commit you want to revert to is followed by a commit that further modifies the part that you changed in that commit, of course there will be a conflict at the time of revert.
Also, if you try to merge branch A again after converting branch A after merging branch A, nothing will change because the branch points of branch A are all commits that have already been merged before the reverting point.To recover the changes that have disappeared in revert, for example, you can make a new commit by reverting revert.
The following is a small example of operation:
$git init
Initialized empty Git repository in /home/nek/tmp/rev/.git/
$ # Create a new example.txt and commit.
$ echo foo>example.txt
$ git add example.txt
$ git commit-m "add example.txt"
[master(root-commit)d0de588] add example.txt
1 file changed, 1 insertion (+)
create mode 100644 example.txt
$ # Revert the example.txt that I just committed.
$ git revert HEAD
hint: Waiting for your editor to close the file...
[master e93d91b] Revert "add example.txt"
1 file changed, 1 deletion (-)
delete mode 100644 example.txt
$ git log
commit93d91b3617f4d70f04ae8ed100f17d492350c32 (HEAD->master)
Author: nekketsuuu<[email protected]>
Date: Wed Aug 5 19:20:21 2020+0900
Revert "add example.txt"
This reverts commit d0de58827a3c518f12c2885a8db97ed2aec5ab94.
commit d0de58827a3c518f12c2885a8db97ed2aec5ab94
Author: nekketsuuu<[email protected]>
Date: Wed Aug 5 19:19:42 2020 +0900
add example.txt
$ # File Deleted
$ ls
$ # I'll try again.
$ echo foo>example.txt
$ git add example.txt
$ git commit -m "add example.txt, again"
[master9124376] add example.txt, again
1 file changed, 1 insertion (+)
create mode 100644 example.txt
$ # Now, let's try to make a change like conflict.
$ echo bar>example.txt
$ git add example.txt
$ git commit-m "improve example.txt"
[master a9eb03c]improve example.txt
1 file changed, 1 insertion(+), 1 deletion(-)
$ # If you try to revert the commit that created example.txt, it conflicts.
$ git revert HEAD~1
error: could not revert 9124376 ... add example.txt, again
hint —after resolving the conflicts, mark the corrected paths
hint: with 'git add<paths>' or 'git rm<paths>'
hint:and commit the result with 'git commit'
nek@G-GEAR-NEK:~/tmp/rev$git status
On branch master
You are currently reversing commit 9124376.
(fix conflicts and run "git revert -- continue")
(use "git revert -- abort " to cancel the revert operation)
Unmerged paths:
(use "git reset HEAD<file>..." to unstage)
(use "git add/rm<file>..." as appropriate to mark resolution)
deleted by them —example.txt
no changes added to commit (use "git add" and /or "git commit-a")
$ ls
example.txt
$ # Now let's choose the one you want to delete.
$ gitrm example.txt
example.txt —Needs merge
rm 'example.txt'
$ git revert -- continue
[master a48ed94] Revert "add example.txt, again"
1 file changed, 1 deletion (-)
delete mode 100644 example.txt
$ git log
commit a48ed94fd72ba3bd2c6886f173de46f8de3974e (HEAD->master)
Author: nekketsuuu<[email protected]>
Date: Wed Aug 5 19:22:48 2020 +0900
Revert "add example.txt, again"
This reverts commit 912437675711610a16f9690244223c047d4276dc.
commit a9eb03c37c08f884eca636d62f5d7e209d83b51d
Author: nekketsuuu<[email protected]>
Date: Wed Aug 5 19:21:48 2020 +0900
improve example.txt
commit 912437675711610a16f9690244223c047d4276dc
Author: nekketsuuu<[email protected]>
Date: Wed Aug 5 19:21:24 2020 +0900
add example.txt, again
(Omitted)
$ # It was successfully deleted.
$ ls
$ # Finally, I will try to revert the revert commit.
$ git revert HEAD
[master037b437] Revert "Revert "add example.txt, again"
1 file changed, 1 insertion (+)
create mode 100644 example.txt
$ git log
commit037b4371b6 afd63b3197ecbfc8f0f48bbe6c9490 (HEAD->master)
Author: nekketsuuu<[email protected]>
Date: Wed Aug 5 19:23:10 2020+0900
Revert "Revert "add example.txt, again"
This reverts commit a48ed94fd72ba3bd2c6886f173dee46f8de3974e.
commit a48ed94fd72ba3bd2c6886f173dee46f8de3974e
Author: nekketsuuu<[email protected]>
Date: Wed Aug 5 19:22:48 2020 +0900
Revert "add example.txt, again"
This reverts commit 912437675711610a16f9690244223c047d4276dc.
commit a9eb03c37c08f884eca636d62f5d7e209d83b51d
Author: nekketsuuu<[email protected]>
Date: Wed Aug 5 19:21:48 2020 +0900
improve example.txt
commit 912437675711610a16f9690244223c047d4276dc
Author: nekketsuuu<[email protected]>
Date: Wed Aug 5 19:21:24 2020 +0900
add example.txt, again
(Omitted)
$ The bar will be returned instead of #foo.
$ cat example.txt
bar
$
I compare git's question to ramen set meal, but
First, I will push the following order to the ramen shop's father.
Ramen + Rice + Dumpling
I changed my mind and wanted to eat fried rice
So I will make a change (commit) of the order and push it to the father of the ramen shop
Ramen + Fried Rice + Dumpling
However, if you quit, what you do when you cancel the order change (revert) is
You will create a commit that negates the commit.
"Change fried rice to rice".
The current flow is as follows
Ramen + Rice + Dumpling Order 1
↓
Ramen + Fried Rice + Dumpling Order 2
↓
Ramen + Rice + Dumpling Order 3
The important thing here is that the first order 1 and 3 are different.
The source is the same, the history is different, and the commitment of parents is different.
Then, what happens if I make the following commitments and push them here?
Ramen + Rice + Dumpling Order 1
↓
Ramen + Fried Rice + Dumpling Order 2
It's easy, my father at the ramen shop says, "I've already accepted that order." = "There's no difference."
Of course.The commitment to make 1 2 already exists in the repository, so what we need to do is update order 3 to make order 4.
What is the difference?If there are different commits in the middle, or if they are different commits in the first place, they will not come out.
Ramen + Rice + Dumpling Order 1
↓
Ramen + Fried Rice + Dumpling Order 2
↓
Ramen + Rice + Dumpling Order 3
Ramen + Rice + Dumpling Order 1
↓
Tsukemen + Fried Rice + Dumpling Order 4
when created
said my father."Hey, I ordered 2 for order 1, but what do you think of the 4 orders?"
Well, it's a conflict.
I think the situation will change a little between the two.
The two links at the end of the question sentence are the former, but I felt that the situation in the body of the question was mixed with the latter story.
First of all,
I'll think aboutI think this is what happens in the opening situation A).
You can reproduce the event with the following script:
#!/bin/bash
mkdir myrepo
cd myrepo
git init
git commit --allow-empty-minit
# 1. Start working with branch feature (create hello.txt)
git checkout-b feature
git tag start-working
echo 'Hello!' > hello.txt
git add hello.txt
git commit -m 'hello.txt added'
# 2. I merged feature into branch master...
git checkout master
git merge --no-ff --no-edit feature
# 3. I realized that I was in the middle of working on it.
git revert --no-edit-m1@
# 4. Work with feature again (create world.txt)
git checkout feature
echo 'World!' > world.txt
git add world.txt
git commit -m 'world.txt added'
git tag end-working
# 5. Merge into master as feature work is complete
git checkout master
git merge --no-ff --no-edit feature
# I want hello.txt and world.txt to be ready...
# But only world.txt exists.
ls-l
Now compare the master (master^
) and feature (end-working
tag) just before merging 5. (Double dot):
$git diff --name-status master^..end-working
A hello.txt
A world.txt
The difference is definitely what we worked on in the feature branch.
On the other hand, 5. will actually merge with the difference from the common parent of master^
and end-working
(triple dot):
$git diff --name-status master^...end-working
A world.txt
The addition of hello.txt
has already been merged with the commit of 2. and will not be included in the merge of 5..
Back to the question,
The difference is independent of revert.Whether it has already been merged.
Also, the final result does not include what should have been changed because you reverted the change.
As explained above, the difference detected by what (at what point) you see is naturally different.
Problem linked in question statement
After merging pulliks on GitHub, do you ever realize that you are not ready to merge and revert?
After that, the problem is that I have reverted, but I would like to continue working on the reverted branch and issue a pullik again.That's the situation.
If you continue to work normally and issue a pullik without thinking about it, you will lose the number of changes that have been reverted.
As a countermeasure, "Continuing to work on the reverted branch after reverting the merged pullik in GitHub" is itself the cause of the accident and should be stopped.
Also, it would be strange to revert (restore to the problematic state) to merge something that has been reverted because of the problem, even if the result is correct.
If you have reviewed and merged the pullik, you should close the feature branch and re-create the pullik from master
.
In this case, cherry-pick
should be available:
#5.feature has completed and merged into master
# 5-1. Create a new feature branch from master instead of ...
git checkout master
git checkout-b feature-reborn
# 5-2. Take over all work in feature with cherry-pick
git cherry-pick start-working..end-working
# 6. Merge the new feature-reborn into master
git checkout master
git merge --no-ff --no-edit feature-reborn
# Hello.txt, world.txt both exist
ls-l
Personally, however, I think it's okay to assume that there was no merge in reset --hard
under the authority of the administrator (not revert
).
This is the situation A) mentioned at the beginning.
Next, regarding situation B), unlike situation A), there is no merge commit (branching, integration does not occur), so the situation described above does not occur.
When classifying safe and dangerous things through Git operation, generally
I think it will be like that.
In this classification, revert
is a safe operation, commit--amend
is a dangerous but limited operation, and rebase
is a dangerous operation.
I don't think it's particularly problematic for people who are unfamiliar with Git to use safe operations instead of dangerous ones.
915 When building Fast API+Uvicorn environment with PyInstaller, console=False results in an error
612 GDB gets version error when attempting to debug with the Presense SDK (IDE)
578 Understanding How to Configure Google API Key
618 Uncaught (inpromise) Error on Electron: An object could not be cloned
© 2024 OneMinuteCode. All rights reserved.