You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/document/Skill/Git/docs/2.Commit.md
+2-3Lines changed: 2 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -57,12 +57,11 @@ Three special symbols for traversing back in git:
57
57
58
58
> [!NOTE]
59
59
> When saying `HEAD` we're referring to the head of worktree which might walk across different branches as you checkout.
60
-
> When a branch name is explicitly specified or elided(representing the current branch), the **reflog** can differ from `HEAD` since it only contains things about the branch.
61
-
> That is, such commit expression with `@` can point to different commit as you specify/elide the identifier or not.
60
+
> When a branch name is explicitly specified or elided(representing the current branch), the **reflog** can differ from `HEAD`'s since it's branch specific
62
61
63
62
### Identifier Expansion
64
63
65
-
You can expand the any identifier to full commit hash using `git rev-parse <identifier>`
64
+
You can expand any commit identifier to full commit hash using `git rev-parse <identifier>`
Copy file name to clipboardExpand all lines: docs/document/Skill/Git/docs/3.Branching.md
+9-5Lines changed: 9 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ So a branch besides the main branch is essentially a sequence of commits startin
11
11
12
12
1.**branch name**: generally refers to local branch
13
13
2.`<remote>/<branch>`: refers to remote branch **copy fetched** in local
14
-
3.`@{upstream}` or `@{u}`: see [Synchronization](./5.Synchronization.md#remote-branch-identifier)
14
+
3.`@{upstream}` or `@{u}`: see [Remote Branch Identifier](5.Synchronization.md#remote-branch-identifier)
15
15
16
16
> [!NOTE]
17
17
> Given the context that *upstream* is of a branch, `git rev-parse @{u}` should return the fetched latest commit hash of remote **in local**.
@@ -34,10 +34,13 @@ The fact is, commits are chained with their parent and child, so git can track b
34
34
> See `git help branch` and `tldr git-branch`.
35
35
> Or `git help switch` and `tldr git-switch`.
36
36
37
-
-`git branch`
38
-
-`-d|--delete`: delete branch
39
-
-`-m|--move`: rename branch
40
-
-`-c|--copy`: copy branch
37
+
-`-d|--delete`: delete branch
38
+
-`-m|--move`: rename branch
39
+
-`-c|--copy`: copy branch
40
+
-`...`
41
+
42
+
> [!IMPORTANT]
43
+
> Manipulating branches doesn't mean the commits of branches would be manipulated or deleted, they're mostly attached/detached or we can say, they live in the wild waiting to be tracked by a branch.
41
44
42
45
## Merging & Rebasing
43
46
@@ -57,6 +60,7 @@ The fact is, commits are chained with their parent and child, so git can track b
57
60
### Merge
58
61
59
62
A merging involves two branches, the subject of the operation is the branch to merge to.
63
+
A merge operation creates a *merge commit* on the subject branch.
* c0c964d8ae68 powershell-editor-services: init at 4.1.0
31
32
```
33
+
34
+
## Reflog
35
+
36
+
## Bisect
37
+
38
+
`git bisect` is a subcommand to search a target commit by testing *good* or *bad*, which delineated a range of the possible target commit, and you keep half-cut the range by testing *good* or *bad* until you met both *good* which means your found the target.
39
+
40
+
Assuming you have a error one testing introduced at some point but you can't figure out which commit introduced it, but you are dare to stride back to a commit that does not error which can be a start point of *good*.
41
+
Correspondingly, the current commit you're on can be the start point of *bad*, that is, the error was introduced between *good* and *bad*.
42
+
43
+
```mermaid
44
+
gitGraph
45
+
commit
46
+
commit
47
+
commit
48
+
commit id: 'good' tag: 'test passed'
49
+
commit
50
+
commit
51
+
commit
52
+
commit tag: 'might be target'
53
+
commit
54
+
commit
55
+
commit
56
+
commit id: 'bad' tag: 'test failed'
57
+
```
58
+
59
+
1.`git bisect start`: enter *bisect* stage
60
+
2. select a initial range
61
+
-`git bisect bad`: select one commit that you consider *bad*, defaults to `HEAD`
62
+
-`git bisect good <commit>`: select a *good* starting point, it's the commit you dare to stride back.
63
+
3. git will locate you at the *middle* commit of the range, run test again
64
+
- if test failed, `git bisect bad`
65
+
- if succeeded, `git bisect good`
66
+
- git shrinks the search range each time you mark current commit as *bad* or *good*
67
+
4. keep shrinking the range until git told you the final commit clamped
68
+
- the final commit returned is the commit introduced the *bad*
69
+
5.`git bisect reset`: exit bisect stage
70
+
71
+
> [!TIP]
72
+
> *good* and *bad* are not only terms can be used in `git bisect`, *old* and *new* is available when you just need to find **the first commit introduced a change**** instead of an error.
73
+
> See: *Alternate terms* section in `git help bisect`
74
+
75
+
### Auto Bisect
76
+
77
+
Repeating clamping each time is a bad experience, so you'd better use `git bisect run <cmd>` to run.
78
+
79
+
>Note that the script (my_script in the above example) **should exit with code 0 if the current source code is good/old,
80
+
>and exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad/new.**
81
+
>
82
+
>Any other exit code will abort the bisect process. It should be noted that a program that terminates via `exit(-1)` leaves
83
+
>`$? = 255`, (see the `exit(3)` manual page), as the value is chopped with `& 0377`.
84
+
85
+
> [!IMPORTANT]
86
+
> You should make sure the command for `git bisect run <cmd>` exits itself otherwise the operation wouldn't be automatic.
87
+
> See: *Bisect run* section in `git help bisect`
88
+
89
+
90
+
## Revert
91
+
92
+
Once you find a change causing an error by `git bisect` or any method you use, you might be like to *revert***that commit of changes**.
93
+
`git revert <commit>` is for trying to cancel the change of that commit, and simultaneously generate a *revert commit*.
94
+
95
+
When any conflict exists, you just handle it like *merge* or *rebase*, and `git revert --continue`
96
+
97
+
## Reset
98
+
99
+
-`--mixed`: the default action on reset, leaves all tracked changes since the *commit* reset to as *upstaged* state
100
+
-`--soft`: leaves all tracked changes along in a *staged* state.
101
+
-`--hard`: discard all tracked changes since the *commit* reset to, they're gone in the wild unless you get it back with *reflog*
102
+
- see: `git help reset` for complete list of reset modes.
103
+
104
+
> [!NOTE]
105
+
> The equivalence of `git reset --hard <commit>` is like
106
+
>```console
107
+
>$ git branch
108
+
> main
109
+
>* dev
110
+
>
111
+
>$ git checkout <commit> # detach from a branch
112
+
>
113
+
>$ git branch -D dev # stop tracking original branch(aka deleting a branch)
114
+
>$ git branch -b dev # attach current commit checked out as new top of the branch(aka creating a branch)
The following convention is widely adapted by most git hosts such as github and gitlab, git host would add such remotes by convention when you fork one repository from another.
31
+
The following convention is widely adopted by most git hosts such as github and gitlab, git host would add such remotes by convention when you fork one repository from another.
31
32
32
33
-`origin`: the remote represents the direct copy in a git host is usually named as *origin*
33
34
- one repository can have one or more mirrors hosted on different git hosts, the most official one should be *origin*
@@ -45,6 +46,10 @@ The following convention is widely adapted by most git hosts such as github and
45
46
-`<branch_name>@{upstream}` or `<branch_name>@{u}`: attached remote branch of `<branch_name>`**on local**.
46
47
-`@{upstream}` or `@{u}`: attached remote branch of **current branch**(if you're on a branch)
47
48
49
+
## Fetch
50
+
51
+
## Merge
52
+
48
53
## Pull
49
54
50
55
`git pull <remote_name> <branch_name>`
@@ -53,3 +58,38 @@ The following convention is widely adapted by most git hosts such as github and
53
58
git branch -u <remote_name>/<branch_name> [<local_branch>] # make sure you have one upstream attached to the branch
54
59
git pull # pull remote commit from the attached upstream to current branch
55
60
```
61
+
62
+
### Rebase on Pull
63
+
64
+
Rebasing on pull `git pull --rebase` follows such steps behind the scene:
65
+
1.`git fetch <current_branch>`: fetch remote commits of current branch
66
+
2. Git checkout to the remote branch and remove the new local commits, and **replay** the new local commits to on the base of remote.
67
+
- oops, conflict might happen at this point.
68
+
- git enters a pending stage to let you resolve the conflicts.
69
+
-`git rebase --continue` to apply the resolved changes when you're ready.
70
+
- or `git rebase --abort` when you like to give up the rebasing, git reattach new local commits to local branch.
71
+
- this is effectively the same as moving **new local** commits to the **top** of the coming remote commits.
72
+
3. Git attaches the **tail** of coming remote commits to the top of **old local** commits, rebasing finished.
73
+
74
+
> [!NOTE]
75
+
> *replay* refers to performing all actions to generate the same new local commits on the new base.
76
+
> Each stage of rebasing would be added to reflog.
77
+
78
+
> [!NOTE]
79
+
> It's worth noting that rebasing shows a reversed side of conflicts that, `HEAD` is coming from remote while the another side is coming from local.
80
+
> That's simply because the point when conflict happens, the recipient branch is the remote and the coming commits(we can't say it's a branch since it has no base at that point) are from local.
81
+
>```diff
82
+
><<<<<<< HEAD
83
+
>Code from the remote (what you're rebasing *onto*)
84
+
>=======
85
+
>...Your local patch being replayed
86
+
>>>>>>>> (your commit being applied)
87
+
>```
88
+
89
+
Git generates a merge commit directly with coming commits as the default behavior, while it's recommended to use `git pull --rebase` to move your local divergence point that compared to the remote branch to the head of the coming commits.
90
+
Rebasing on pull keeps the history in a intuitive order since changes from local are not pushed yet which should naturally behind the remote.
0 commit comments