blob: 34c2d9687bb07713b8dc2e7e4bea0b16ad53e0af (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
---
stage: none
group: unassigned
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
comments: false
---
# Rollback Commits
## Undo Commits
- Undo last commit putting everything back into the staging area:
```shell
git reset --soft HEAD^
```
- Add files and change message with:
```shell
git commit --amend -m "New Message"
```
- Undo last and remove changes:
```shell
git reset --hard HEAD^
```
- Same as last one but for two commits back:
```shell
git reset --hard HEAD^^
```
**Don't reset after pushing**
## Reset Workflow
1. Edit file again 'edit_this_file.rb'
1. Check status
1. Add and commit with wrong message
1. Check log
1. Amend commit
1. Check log
1. Soft reset
1. Check log
1. Pull for updates
1. Push changes
## Commands
```shell
# Change file edit_this_file.rb
git status
git commit -am "kjkfjkg"
git log
git commit --amend -m "New comment added"
git log
git reset --soft HEAD^
git log
git pull origin master
git push origin master
```
## Note
- `git revert` vs `git reset`
- Reset removes the commit while revert removes the changes but leaves the commit
- Revert is safer considering we can revert a revert
```shell
# Changed file
git commit -am "bug introduced"
git revert HEAD
# New commit created reverting changes
# Now we want to re apply the reverted commit
git log # take hash from the revert commit
git revert <rev commit hash>
# reverted commit is back (new commit created again)
```
|
