如何使用 Git 撤消推送合并？

Question

I am very new to git and have recently tried to do a merge using the following sequence of commands:

git checkout master

# merge Issue#2 branch into master
git merge Issue#2

git push origin master

It looks like a fast-forward merge has been performed by default as shown in the output listing for git reflog included at the end of the question??? The history shows each individual commit of the merged branch.

I would like to undo the Issue2# branch merge. I would then like to perform a squash merge.

I have read that revert is better for undoing a pushed merge, so I tried the following:

# revert the commits for MERGE ISSUE#2: FAST_FORWARD??
git revert -m 1 d52c603

However, it only reverts the latest commit from the branch that I would like to merge.

How can I undo the Issue2# branch merge (rollback to commit ee59444)? How can I then perform the merge (commits 43d090e to d52c603) with just one commit for all my check-ins?

I am new to this! I think what I should have done is:

git checkout master
git merge --squash Issue#2
git commit -m "Merge message"
git push origin master

I could do??

git checkout master
git reset --hard ee59444
git push --force

git merge --squash Issue#2
git commit -m "Merge message"
git push origin master

or is it safer to use revert instead of reset ?

Git Reflog

e2c6058 HEAD@{0}: pull: Fast-forward
ee59444 HEAD@{1}: reset: moving to ee59444
e2c6058 HEAD@{2}: commit: Doc: Add details of Kafka Configuration default provided by test utils
6481400 HEAD@{3}: checkout: moving from master to master
6481400 HEAD@{4}: checkout: moving from Issue#2 to master
d52c603 HEAD@{5}: checkout: moving from master to Issue#2
6481400 HEAD@{6}: checkout: moving from master to master
6481400 HEAD@{7}: reset: moving to 64814001c5d6162665fe0494d95275660b6ec2e0
6481400 HEAD@{8}: checkout: moving from Issue#2 to master
d52c603 HEAD@{9}: checkout: moving from master to Issue#2
6481400 HEAD@{10}: revert: Revert "Doc(Issue#2): Add doc header explaining default config"
d52c603 HEAD@{11}: checkout: moving from master to master
d52c603 HEAD@{12}: checkout: moving from master to master


d52c603 HEAD@{13}: MERGE ISSUE#2: FAST_FORWARD


ee59444 HEAD@{14}: checkout: moving from master to master
ee59444 HEAD@{15}: checkout: moving from master to master
ee59444 HEAD@{16}: reset: moving to origin/master
c5dfc28 HEAD@{17}: checkout: moving from Issue#2 to master
d52c603 HEAD@{18}: commit: Doc(Issue#2): Add doc header explaining default config
b41e109 HEAD@{19}: commit: Testing(Issue#2): Add tests for Kafka Consumer service
2c180b7 HEAD@{20}: commit: Testing(Issue#2): Add tests for MqttKafkaBridge
129f689 HEAD@{21}: commit: Testing(Issue#2): Add skeleton unit tests for WebApp.BackgroundServices
499f566 HEAD@{22}: commit: Testing(Issue#2): Add ProducerService tests
4b6e3f1 HEAD@{23}: commit: Tests(Issue#2): Add skeleton tests for ProducerService
ea811f0 HEAD@{24}: commit: Testing(Issue#2): Add Kafka tests
2255b09 HEAD@{25}: commit: Refactor: Remove unused import
0e27f22 HEAD@{26}: commit: Docker: Update port for rest-proxy
59519d7 HEAD@{27}: commit: Test(Issue#2): Add tests for S3 service
5783a02 HEAD@{28}: commit: Test(Issue#2): Add tests for Mqtt service factory
fbac0f7 HEAD@{29}: commit: Test(Issue#2): Add unit tests for Mqtt service
a367b03 HEAD@{30}: commit: Refactor(Issue#2): Remove unused imports
a717895 HEAD@{31}: commit: Test(Issue#2): Add Mqtt factory test
6c62f38 HEAD@{32}: commit: Test(issue#2): Add Mqtt factory tests
c5dfc28 HEAD@{33}: checkout: moving from master to Issue#2
c5dfc28 HEAD@{34}: pull origin Issue#2: Fast-forward
ee59444 HEAD@{35}: pull --tags origin master: Fast-forward
142ff05 HEAD@{36}: pull --tags origin master: Fast-forward
f3a82e2 HEAD@{37}: pull --tags origin master: Fast-forward
4730534 HEAD@{38}: commit: Fix: Fix blocking signalR disposal when tab closed
8fef99c HEAD@{39}: commit: Feature: Add automated Kafka Topic Creation
085da18 HEAD@{40}: pull --tags origin master: Fast-forward
8973ef4 HEAD@{41}: commit: Add signalR logging and dispose for hub
a6c3ed3 HEAD@{42}: pull --tags origin master: Fast-forward
8079575 HEAD@{43}: pull --tags origin master: Fast-forward
babec37 HEAD@{44}: pull --tags origin master: Fast-forward
601292d HEAD@{45}: commit: Chore(Structure): Add Autofac module tests into integration tests
588433b HEAD@{46}: commit: Test: Refactor to use core test utils
c9300f1 HEAD@{47}: commit: Test: Refactor to use core test utils
48c3d1a HEAD@{48}: commit: Chore(Dependencies): Update package dependencies
112d8ab HEAD@{49}: pull --tags origin master: Fast-forward
ccc2d97 HEAD@{50}: pull --tags origin master: Fast-forward
d786256 HEAD@{51}: commit: doc(README): Add explanation of BASE_URL
3c45bb0 HEAD@{52}: pull --tags origin master: Fast-forward
bbdfa12 HEAD@{53}: commit: Refactor: Remove temp upload test proj
e653daa HEAD@{54}: commit: Fix: Add mising project reference to WebApp.S3.AutofacModule
8282f59 HEAD@{55}: commit: Refactor: Rename mqttkafka bridge project
cc437cf HEAD@{56}: commit: Refactor: Restructure mqtt and kafka config
a4cad1c HEAD@{57}: pull --tags origin master: Fast-forward

Git Log

Output of git log...

git checkout Issue#2
git log --oneline

d52c603 Doc(Issue#2): Add doc header explaining default config
b41e109 Testing(Issue#2): Add tests for Kafka Consumer service
2c180b7 Testing(Issue#2): Add tests for MqttKafkaBridge
129f689 Testing(Issue#2): Add skeleton unit tests for WebApp.BackgroundServices
499f566 Testing(Issue#2): Add ProducerService tests
4b6e3f1 Tests(Issue#2): Add skeleton tests for ProducerService
ea811f0 Testing(Issue#2): Add Kafka tests
2255b09 Refactor: Remove unused import
0e27f22 Docker: Update port for rest-proxy
59519d7 Test(Issue#2): Add tests for S3 service
5783a02 Test(Issue#2): Add tests for Mqtt service factory
fbac0f7 Test(Issue#2): Add unit tests for Mqtt service
a367b03 Refactor(Issue#2): Remove unused imports
a717895 Test(Issue#2): Add Mqtt factory test
6c62f38 Test(issue#2): Add Mqtt factory tests
c5dfc28 Rfeactor(Issue#2): Add Implementation MQTT factory
43d090e Refactor(Issue#2): Add factory and builder contracts for Mqtt

# WOULD LIKE TO ROLLBACK TO THIS COMMIT!
ee59444 Chore(Structure): Add missing test projects to solution


64d968a Test(SignalR): Add signalR unit tests
972164f Merge branch 'lenses_io' into 'master'
0a86c8b Docker(Kafka): Update kafka services to lenses.io for dev
142ff05 Test: Add Kafka config unit tests
64ccf8a Test: Add Kafka Serdes Json Deserializer tests
2b75f7f Test: Add Kafka Producer Provider unit tests
28a2281 Test(TestUtils): Add test helpers for creating Kafka config
4e1bef6 Chore(Dependency): Add Moq dependency for Kafka Unit Tests
1d84adf Test: Add Config validation tests for mqtt and S3
f3a82e2 Test(Watcher): Add test watcher tool to Kafka Unit Test Project
aed2989 Test:(Watch): Add test watcher tool to Kafka Unit Test
0f6b343 style: align item group element
53d449e Style(log): Update  signalHub logs for clarity
726ad63 doc(README): Update Kafka Config and browser compatability
aedee3d Style: Remove usage of GetAwaiter().GetResult() in docstrings
4730534 Fix: Fix blocking signalR disposal when tab closed
8fef99c Feature: Add automated Kafka Topic Creation
085da18 Style: Update log message for when connecting to secondary signalR hub
2f67e22 Refactor: Add default Kafka consumer options
609f41f Style: Update logs to explicitly state that for Kafka Consumer
c232149 Fix: Dispose secondary signalR connection when page closed
8973ef4 Add signalR logging and dispose for hub
a6c3ed3 Style: Remove unused imports
8079575 Docker(Minio): Update to v1.0.2
4285cb4 Chore(Config): Update second MqttCameraTopic
7c4dbc9 doc(README): add future features section
ce22444 Chore(Config): Update appsettings dev for default local mqtt host
53fb8a2 doc(README): Add non TLS example for MQTT settings
babec37 Tests: Add Autofac Module tests
601292d Chore(Structure): Add Autofac module tests into integration tests
588433b Test: Refactor to use core test utils
c9300f1 Test: Refactor to use core test utils
48c3d1a Chore(Dependencies): Update package dependencies
112d8ab Test: Fix Kafka ModuleTest
2ddd170 Tests: Add tests for Kafka Autofac Module
abafae5 Tests(Fix): Fix WebApp.Data.Serializers.AutofacModule.UnitTests
8eecc0d chore(sln): Add all projects to solution
38e1afc doc(README): update wih demonstration and environment details
ad49959 docker(compose): update minio to use my public dcs3spp/minio image
50c9c39 fix(link): update about link to point to moved gitlab project
b043e62 doc(README): Add HTTPS config
e044c2f Fix: Fix serializaion error
fbd135e Fix(index): Update headings for motion detection snapshot
c950b2b fix(Index): update About link to README for this page
f21307a chore(config): update Kafka config with genric camera monitor
8f4ddd7 test(data): update for stream time
81d1b6c doc: update README with architecture and links to related cam project
ccc2d97 Refactor: Add received time for motion detection
5421967 Refactor: Remove commented factory code
93ea54c Refactor: Remove redundant pages
529a3e3 Refactor: Update link for about to this repository
a29e180 Refactor: Add logger and remove Api Client
9ef3872 Reafactor: Remove Api client
d786256 doc(README): Add explanation of BASE_URL
3c45bb0 docs(README): Update README with configuration and architectural overview
5f527f0 Refactor(Data): Update Time property in MotionDetection and MotionInfo models to be long
89529da Mqtt(TLS): Update MqttService with TLS
a4299b7 Refactor(log): Add logging of topics consumed
bbdfa12 Refactor: Remove temp upload test proj
e653daa Fix: Add mising project reference to WebApp.S3.AutofacModule
8282f59 Refactor: Rename mqttkafka bridge project
cc437cf Refactor: Restructure mqtt and kafka config
a4cad1c Feature: Refactor MqttKafkaBridge background service to depend on Mqtt, KafkaProducer and S3 service
c61cb23 Refactor(MqttBridge): Update MqttBridge background service to accept producer, mqtt and s3 service
787706a Feature(Kafka): Add kafka config
7b34f14 Chore(dependency): Update Autofac dependency to v6
e580fc4 Feature(MQttService): Add Mqtt Service
63224fd MqttClient: Add project to factor out MQTTCllient
5aa7a9d Refactor: Add code behind for index page
ef61297 Fix: Motion detection image now loaded via url to controller
afc9ba4 add consumer with deserialization restored
8a6d7cc SignalR: Add deserialization back to kafka queue....leads toward schema validation
d716ab0 Style: Remove trailing space
2bb847f Feature(Serializer): Add Serializer for MotionDetection
fc331a0 Feature(Serializer): add serializer for MotionDetection
5fb53ae Feature(ApiClient): add typed api client for api
53a9e59 SignalR: Add logging to server and client
668a007 Fix: Remove Client inject from Index page
f5e6cc2 Feature(Images): Add S3 storage for images
fa4663d Refactor: Update Hub interface to accept string for now.
03c84f3 Refactor: Add signalR into consi,er service and refactor into separate classlib
3ae8ed8 Refactor: Prepend kafka header to payload
dce28ac Chore(Backup): Commit, power going off
24e3848 Refactor: Update autofac dependencies for kafka
fdde284 Refactor: Update MotionDetectionSerializer to be generic type
0ecc15a Chore: Backup for electric going off
d230508 Feat: Add background service
54b9d61 Refactor: Add MqttListenerWorker project
6b00f4c Chore(DI): Add WebApp.Repository autofact dependencies
35a0a97 Chore(DI): Add Autofac module for WebApp.Data.Serializers
800c6f8 Refactor: Add Autofac Module for Serialization
b8772f2 Test(JsonParser): Add overflow value for testing TryGetDouble as false
1af7c47 Test(JsonVisitor): Add test for missing StartArray tag in json
b757bee Chore(VSCode): Add tasks
6e38430 Refactor: Remove Default motion detector serializer
3bf3a5c Chore(Test): Ignore CoverageReports folder
14c9367 Tests: Add test for deserializing from null stream
83502f6 Test: Add integration tests for JsonVisitor
babba07 Refactor: Add new WebApp.Testing.Mocks classlib
a6781c2 Test(JsonSerializerWrapper): Add JsonSerializerWrapper integration tests
391a433 Refactor: Add JsonSerializerWrapper and interface into separate file
458186a Test(JsonParser): Add tests for JsonParser
de53251 Refactor(MockJsonParser): Update to track exceptions thorwn for properties
5cf3938 Refactor: Update JsonVisitor to accept injectable JsonParser
73ba2ad chore(tools): add tool manifest for reportgenerator
1cf67aa Test: Add integration tests
d582904 Refactor(structure): update repository contracts project
0363795 Refactor: Add contacts for serialization
028382c chore(structure): refactor test structure
734e975 Style(Comments): remove redundant comments
ba13c54 Test(ToString): add tests for ToString for models
d574ab5 Test(ParsedMotionLocation): Add tests
8eb6b83 Test(ParsedMotionInfo): Refactor test names to reflect MotionInfo
f2b7863 test(ParsedMotionInfo): complete MotionInfo tests
2d9144a Test: Update visitor mock with reason person
df878d9 test(ParsedMotionDetection): completed tests for ParsedMotionDetection
6b4a635 Test(ParsedMotionDetection): Update ParsedMotionDetection_Accept_Calls_IVisitor_DeserializeMotionDetection with assertion of r call count of deserialize motion detection
be835d9 Tests(ParsedMotionInfo): Add unit tests
e5c4a23 Tes(ParsedMotionDetection): Add tests for ParsedMotionDetection
bf2cdb5 Refactor: Add constructor DI for JsonSerializerWrapper
6640a6e refactor: remove unused using statements
4dd2ed9 Test: Add unit tests for custom converters
5cf565d Refactor(DI): Add IParsed to converters to facilitate testing
94cb5d9 Refactor: remove unused using statement
83a233c Refactor(DI): Update for DI
2d1c16a Test(MotionDetectionRepository): Add tests for ArgumentNullException
ea6b298 Test(MotionLocationTest): Add GetHashCode tests
7460d7e Test(MotionLocation): Add != tests
778a4ee Test(MotionLocation): Add == tests
dc39c35 Test(MotionLocation): Update test names
eb41b2c Test(MotionLocation): Add tests for IEquatable Equals
0103cd8 Test(MotionLocation): Add Object Equals tests
89061d9 Test(MotionLocation): Add tests for copy constructor
d3ecf51 Test(MotionLocation): Add property constructor tests
f20395e Test(WebApp.Data.UnitTests): Update namespace
ffdb5ee Test(MotionInfo): Add GetHashCode tests
4e5996d Test(MotionDetectionTest): Update test names to reflect test correctly
a88412f Test(MotionInfo): Add == and != operator tests
9d194d1 Test(MotionInfo): Remove redundant IEquatable test
3a97cd4 Tests(MotionInfo): Add MotionIo IEquatable Equals tests
d548d93 Test(MotionInfo): Add object.Equal unit tests
4d0db06 Test(MotionInfo): Add constructor tests
e10b8cd Test(MotionDetection): Add test for null in copy constructor
8ec505e TesT(Projects): Add watch tool
5d35443 Test(MotionDetection): Add MotionDetection unit tests
9bc4b43 Fix: Update equals to return false if at least one attribute not equal
aa3caff Test(MotionDetection): Add tests for IEquatable Equals
d903eb6 Refactor structure
ef60e30 Initial Commit

Answer 1

TL;DR

Your proposed sequence:

git checkout master
git merge --squash Issue#2
git commit -m "Merge message"
git push origin master

was right. Your proposed repair would work. It's a good idea to know why , though.

Long

I have read that revert is better for undoing a pushed merge ...

"Better" is in the eye (or screen?) of the beholder. But you're being bitten by a simple fact here: what Git calls a fast-forward merge is not actually a merge at all. A simple, single-commit revert won't undo it.

How can I undo the Issue# branch merge (rollback to commit ee59444)? How can I then perform the merge (commits 43d090e to d52c603) with just one commit for all my check-ins?

First, be sure you really want to do this (and to bother with it). Some people hate messy commit history and argue that it's always worth cleaning everything up. Other people argue that once you make a commit, you should never go back and fix anything that was wrong with it: you should just add new commits to repair the problem, so that the history is 100% accurate and includes every mistake ever. I don't buy either extreme: I say that some mistakes are worth cleaning up so that nobody has to see them, and some aren't. Of course, it's then a value judgment about which ones to clean up.

Let's assume here that you do want to clean this all up (otherwise, you are done now, you just move on). The trick now becomes how you clean up. The important part here, though, is not just doing the cleanup itself, but also understanding how this works and therefore what could go wrong.

(This is going to be a bit long, but I will try to be brief and go fast.)

Git is all about commits , so, what precisely is a commit?

Those new to Git often think it's about files or branches. It's not. It's about commits . It's true that a commit contains files, and Git finds a commit using a branch name , but ultimately, everything is all about the commits. So it's crucial to understand what a commit is and does for you.

The first thing to know is that commits are numbered. They're not simple counting numbers: instead, they are those hash IDs you see, like d52c603 and ee59444 . (These are actually abbreviated—the actual numbers are much bigger. They're expressed in hexadecimal, hence the letters a through f as well as digits.) These numbers look random, but are not; in fact, the values are arranged so that every Git everywhere will agree that commit ee59444 is numbered ee59444 , and no other commit can have this number (ever—that's why they're so big). The number is computed by looking at the complete contents of the commit. This means that no part of any commit can ever be changed, either: if you changed it, it would have a different number.

In fact, you can take a commit out, work with it, and write back a new commit that's almost, but not completely, the same. That gives you a new commit with a new (different) number. The existing commit remains in your repository. So all Git ever really does is add new commits. Existing commits remain—at least for some time. But if you can't find the number of a commit, you'll never see it again, and eventually Git will notice that nobody can find it, and drop it from the database.

As this suggests, all commits—in fact, all of Git's internal objects—are stored in a big database. It's indexed by the object numbers. You just give Git the number, and Git pulls the object out of the database and makes it usable. Inside the database, it's in a form that only Git itself can use (and is read-only). So now we can look at what's inside a commit—what Git can see and extract for us. There are two parts:

• First, a commit contains a full snapshot of every file (that Git knew about at the time you, or whoever, made the commit, that is). The files inside commits are stored using this same big database, and they're kept in a compressed, read-only, Git-only format with content de-duplication. So the fact that many commits in a row keep re-using most of the existing files means that those commits don't actually need any extra space: they literally re-use the existing files. It's safe to do this because nothing put into the database can ever change.

• Besides the data—the snapshot—each commit contains metadata , or information about the commit itself: who made it, when, and so on. Crucial to the operation of Git, each commit's metadata contains the hash ID of an earlier commit . More precisely, each commit contains zero or more hash IDs, which Git calls the parent hash IDs . Most commits have just one parent. At least one commit—the very first one someone made for the repository—has no parent, because there was no previous commit. Some commits have two or more parents, which makes them merge commits , but we won't look at this here.

What this means is that when you have a bunch of commits, all in a row—which is what you have—they form a simple linear chain, with each commit pointing backwards to its immediate predecessor:

... <-F <-G <-H

Here H stands in for the actual hash ID of the last commit in the chain. If you write down this hash ID, you can use it to have Git find commit H . Inside commit H we have the data—the snapshot of all of your files—and the metadata showing when you made it and so on. In the metadata, Git can find the hash ID of earlier commit G , which lets Git find commit G .

If we compare the snapshot in G to the snapshot in H , we'll see what you changed , going from G to H . That's what git log -p or git show shows.

Of course, we can have Git use G to find the hash ID of earlier commit F , too. So now Git can show what changed between F and G . And, Git can go on to the parent of F (presumably E ), and so on, all the way back to the beginning of time.

Branch names hold one hash ID

To do all of the above, we had to jot down the hash ID of commit H —the last commit in the chain. Why should we bother to do that, when we have a computer? Why not have Git save that hash ID somewhere?

This is exactly what a branch name does. A branch name like master just holds one hash ID: the hash ID of the commit that we should call "last in the chain". In this case, let's have master hold hash ID H , like this:

...--F--G--H   <-- master

I've stopped drawing the arrows between commits as arrows, partly from laziness and partly because they literally can't change: the "arrow" from H to G is part of commit H and no commit can ever change. That's not true for branch names: we can stuff a new hash ID into them any time.

Let's create a new name, now, so that we have two branch names, both of which select commit H :

...--F--G--H   <-- master, issue

Note that whichever name we use, we get commit H . But we'd like to know which name we're using anyway. So let's have Git attach the special name HEAD to one of the two branch names:

...--F--G--H   <-- master (HEAD), issue

This means we're using the name master to find commit H . If we now run:

git checkout issue

we get:

...--F--G--H   <-- master, issue (HEAD)

We're still using commit H , but now we're using the name issue to find it.

Making new commits

Now, let's make a whole bunch of new commits. The first new commit we make, we'll change a file or two, run git add , and run git commit , and Git will write out a whole new snapshot—reusing most files from H —with the appropriate metadata. The parent of the new commit will be existing commit H ; we'll call the hash Id of the new commit I . Having created commit I , Git will do its little trick: it writes the hash ID I into the current branch name , so that we get:

...--F--G--H   <-- master
            \
             I   <-- issue (HEAD)

As we make more new commits, each one points backwards to the current commit, so that the chain grows:

...--F--G--H   <-- master
            \
             I--J--K   <-- issue (HEAD)

The name HEAD remains attached to the name issue , but the commit selected by the name issue changes.

We now have two branches: master ends at commit H , and therefore includes all commits up to and including H , and issue ends at commit K , and therefore includes all commits up to and including K . That means issue includes commit H too: commits H and all earlier commits are on both branches. ¹

---

¹ This fact, that commits are on more than one branch, is unusual: other version control systems declare that one a commit is made, that commit is on that branch, forever. Git doesn't work this way. Git is weird.

---

Fast-forward

Let's look at what you did next. You ran:

git checkout master

which got you this:

...--F--G--H   <-- master (HEAD)
            \
             I--J--K   <-- issue

Git took all the files out of H and made them available to you, and made master the current name . You are now on branch master .

Next, you ran:

git merge issue

This looked at the name issue , found that it identified commit K , and figured out that commit K was a direct descendant of commit H . This allowed Git to cheat. Instead of doing a real merge—which involves a lot of work—Git could simply check out the last commit on issue and drag the name master forward , like this:

...--F--G--H
            \
             I--J--K   <-- master (HEAD), issue

There's no reason to draw the kink in the graph any more, but I left it in to make it obvious how only the branch name moved.

What you'd like to have

We already noted that you cannot change any existing commits. So commits IJK are stuck the way they are. But what if you could copy all the files from commit K , and use them to make a new commit that comes right after commit H ? Let's call the new commit S and draw it in:

             S   <-- ???
            /
...--F--G--H   <-- ???
            \
             I--J--K   <-- master (HEAD), issue

I've put in two ??? names too, because we're going to need to have some sort of name by which to find commit H , so that we can do the work. Then, having made S , we'll need some name to select commit S so that we can find it.

What name should we use? Well, we could just create a new branch name right now:

git branch redo <hash>

where we put in the hash ID of commit H . We can find this hash ID using git log , or whatever other command we like that finds it; the git branch command will then make the new branch name:

...--F--G--H   <-- redo
            \
             I--J--K   <-- master (HEAD), issue

From here, we can figure out how to make commit S . But we'd have to check out the name redo first, too. Anyway, redo is not really the name we want here. What if we force the name master to point to H ?

Moving a branch name: git reset

Moving a branch name is always possible. It's just a little tricky sometimes.

If we weren't using the name master right now, we could do this with git branch --force . But because we are using master —we have our HEAD attached to it—we can't do this right now. We could move HEAD over to some other name, such as issue , and do it with git branch --force . Or, we can use git reset .

Git's reset is, unfortunately, a horribly complicated command. ² It has many modes. We'll only look at one of them right now, git reset --hard , so that we don't have to get into all the details of Git's index . This leaves out the easiest quick-recipe solution, which is using git reset --soft , but we'll come back to that.

Remember that git reset --hard wipes out all uncommitted work. Be careful with git reset --hard ! Assuming you have no uncommitted work, though, let's see what running git reset --hard hash-of-H would do. It would result in what we can draw like this:

...--F--G--H   <-- master (HEAD)
            \
             I--J--K   <-- issue

This is, in effect, completely undoing your git merge that did a fast-forward. ³

Note that we didn't change anything inside the commits (we can't!). We didn't change anything except the hash ID stored in the name master —or rather, nothing inside the repository itself. We had Git wipe out our current checkout and replace it with the stuff from commit H , too, though: that's the --hard part of git reset --hard .

---

² I find git reset as bad as git checkout . In Git 2.23, the existing git checkout got split into two separate commands, git switch and git restore , each of which did about half the work. (But git checkout remains, and still does all the work.) I think much the same should happen for git reset . But that's another topic.

³ That is, it undoes the git merge in your repository . If you've sent updates to other Git repositories, using git push , it does not change those other repositories. This is where the whole "revert is better" concept comes from in the first place: if you are going to undo things, you need to make sure nobody else can redo them behind your back. Revert doesn't really undo anything at all. Instead, it adds a new commit , so that the existing commits all remain for everyone to see. But, again, that's another topic.

---

Now that we're back at square one, let's make S

The git merge --squash command is the one that makes commit S . We run:

git merge --squash issue

now, while we have:

...--F--G--H   <-- master (HEAD)
            \
             I--J--K   <-- issue

As before, this git merge locates commit K . Commit K would allow a fast-forward, not-a-merge operation, but --squash tells git merge not to do that. So git merge goes through all the work it would normally do, to make a real, normal merge.

If we hadn't used --squash , and had forced Git to make a normal merge, we would get this graph:

...--F--G--H---------M   <-- master (HEAD)
            \       /
             I--J--K   <-- issue

Commit M would be one of those special merge commits , with two parents. Its first parent would be the commit we had out a moment ago: commit H . Its second parent would be commit K , as found by the name issue .

The snapshot for merge M would be built by comparing commit H to commit H , which finds no changes at all, and comparing commit H to commit K , to see what changed on that branch. The result would of course just be the changes required to make commit H 's snapshot match commit K 's snapshot. Git would then add these changes to the snapshot in H . That gives a new snapshot that exactly matches commit K 's snapshot. That snapshot becomes the contents of new merge commit M .

The end result would be a new commit M that contains the same files as commit K . This new merge commit would have two parents, and would be a real merge.

The --squash option, however, stops Git from commit M . Git still goes through all the merge work , to come up with the snapshot. Of course, that snapshot is the one in commit K : the work is kind of silly, but Git does it anyway. Then, git merge --squash stops , as if you had used the --no-commit .

To finish the squashing, you run:

git commit

and Git makes a new non-merge commit S :

...--F--G--H---------S   <-- master (HEAD)
            \
             I--J--K   <-- issue

Commit S contains the same snapshot that commit M would have contained, if we'd had git merge do a real merge.

Making things easier: git reset --soft

Here, let me first observe that, like any version control system, Git has to copy files out of commits, so that you have ordinary read/write files that you can use. The committed files are in a form that nothing else can really use, and are read-only, so they're no good for getting any actual work done. Git therefore extracts each commit's files as you check out that commit.

Now, instead of git reset --hard , git merge --squash , and git commit , we can use git reset --soft and git commit . But how and why does this work? What you need to know here is that Git makes new commits, not from what is in your work-tree, but rather from Git's index . The index is a complicated little thing that, alas, Git eventually forces you to know all about. It's also rather oddly named.

Git's index is also called the staging area , which refers to how one uses it. What the index contains—most of the time, anyway—is your proposed next commit . This consists initially of all the files taken from the current commit , stored in Git's internal, compressed and de-duplicated format.

Note that these files, like all parts of a commit, are in fact read-only. Being de-duplicated, they take no actual space , but it's easiest to think of them as "copies". What's special about the index copy of the files from a commit is that you can replace any one of these files. That's what git add generally does. You run git add file and Git reads the work-tree copy of the given file, compresses it into the internal Git format, and replaces the current (shared) index copy with a new (or shared, if appropriate) file, ready to go into the next commit.

When we ran git reset --hard , we used the --hard flag to tell Git: Replace all the work-tree and index file copies . That is, we had Git change both our work-tree copies of each file, and its index copy, to match the commit we moved to.

With --mixed , we can tell Git: Replace the index copies, but leave the work-tree copies alone. That doesn't really help us here, though there are cases where it makes sense. But with --soft , we can tell Git: Do not replace either of the copies. Keep your index copies untouched, and leave my work-tree copies alone.

If we start with:

...--F--G--H
            \
             I--J--K   <-- master (HEAD), issue

so that Git's index and our work-tree are full of the files from commit K , and run:

git reset --soft <hash-of-H>

we end up with the name master identifying commit H , but Git's index and our work-tree having the files from commit K . If we now run:

git commit

and make a new commit, we get:

...--F--G--H--L   <-- master (HEAD)
            \
             I--J--K   <-- issue

where commit L has the same files in it as commit K .

So, in this case, git reset --soft hash && git commit is the shortest path to where we want to arrive.

Distributed Git and git push

When you have some some set of commits, you often want to pass those commits on to some other Git running some other Git repository. To do that, you can use git push .

The way git push works is that your Git calls up the other Git and starts offering it commits. Your Git offers those commits by hash ID. Their Git either says I have that ID already —which tells your Git that they have that commit , because the IDs are unique, but also that they have every previous commit , because Gits always add commits to the end—or it says please send it . If your Git has to send the commit, your Git offers that commit's parents, too, so that their Git will get all the commits that lead up to that as the last commit.

For that to be the last commit, then, your Git has to ask their Git to set one of their repository's branch names, so that it stores that hash ID. So when you run:

git push origin master

you're telling your Git: Look up the name origin to find a URL. Call up a Git at that URL. Hand over the commit hash ID that is the tip of my master , and see what commits they need. Then, ask them to set their master to that hash ID.

The other Git will generally take any new commits that just add on, so if you have:

...--F--G--H--S   <-- master (HEAD)
            \
             I--J--K   <-- issue

and run git push origin master , and they have:

...--F--G--H   <-- master

in their repository, ^{4 they will take the new commit and update their master . But if they have:}

...--F--G--H--I--J--K   <-- master

in their repository, and you told them to make their repository have:

...--F--G--H--S   <-- master
            \
             I--J--K   <-- ???

in their repository, they would balk at this. Their Git would tell your Git that this operation is not a fast-forward , which in this case means it removes commits IJK from access via master . If their master points to S and S 's parent is H , there's no way to go back from S to K , so they "lose" commit K . (This is true even if they have some other name by which to find K .)

Hence, when you're asking the other Git to remove some commits, you have to use a more forceful kind of git push . You can use --force , where you just send them a command: Set your master ! Or, you can use --force-with-lease , which has your Git send them a conditional command: I think your master points to ______. If so, make it point to ______ instead. Let me know what happened. Your Git fills in the blanks, using a mechanism we haven't described properly here, involving your own Git repository's remote-tracking names . This makes --force-with-lease safer if someone else might be adding commits to the other Git repository.

Either way, though, at least one kind of force operation will be required to get their Git to drop commits from their repository.

---

4When looking at someone else's Git repository, we generally don't need to care so much about where their HEAD might be. There are exceptions to this rule, but that's why I left HEAD off here.

---

Git is a tool-set, not a solution

One of the big takeaways from all of this is that Git does not try to solve just one particular problem. Instead, Git provides a bunch of programmable tools. Each tool does something. Some of these things are useful on their own, but some are useful in combination with something else. Some are only useful in combination, and some do a small job that could stand alone, or could be used to do a bigger job.

The other is that, in the end, Git is all about the commits . The commits hold files, and form chains. The branch names let you and Git find the commits. Git mostly works backwards: the names find a "last" commit and from there, Git works backwards, along the chains. The hash IDs are big and ugly and hard for people to use, but are how Git finds the commits.

Answer 2

git checkout master
git reset --hard <commit>
git push --force

Squash commit using rebase interactive:

git checkout Issue#2
git rebase -i master

Interactive mode will offer you command to apply on the branch commit like squash, fixup, reword...