If I revert, will there always be no difference when I request a pull requests?What is the difference in the case if there are cases where it comes out?

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.

• On the A)master branch, revert the merged feature branch
• B) Revert your work on the feature branch

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,

• If I revert, will there always be no difference in pull requests, or will there be a difference in pull requests?
• Even if there is a difference during a pull request, you may have encountered a phenomenon that somehow does not reflect the difference after merging.

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,

• If I revert, will there always be no difference in pull requests, or will there be a difference in pull requests?

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.

• Even if there is a difference during a pull request, you may have encountered a phenomenon that somehow does not reflect the difference after merging.

As explained above, the difference detected by what (at what point) you see is naturally different.

Problem linked in question statement

• When you want to continue working on the reverted branch after reverting a merged pullik in GitHub-Qiita

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

• Secure operation: New commitments
• Dangerous operation: erasing or modifying past history (existing commit)

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.