git-stack-cli 0.7.3 → 0.7.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +7 -7
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
|
|
12
12
|
## Demo
|
|
13
13
|
|
|
14
|
-
> <img src="https://github.com/magus/git-multi-diff-playground/assets/290084/
|
|
14
|
+
> <img src="https://github.com/magus/git-multi-diff-playground/assets/290084/069c304b-80cb-49a9-9dc6-4ed3b061a5bc">
|
|
15
15
|
|
|
16
16
|
## Install
|
|
17
17
|
|
|
@@ -24,17 +24,17 @@ git stack
|
|
|
24
24
|
|
|
25
25
|
## Why?
|
|
26
26
|
|
|
27
|
-
|
|
28
|
-
Often pushing all your commits to a single pull request is the simplest and fastest approach to development.
|
|
29
|
-
However, there is a cost to this, your teammates have to review larger, less related pieces of code and you will lose some of your atomic commit history if you squahs and merge.
|
|
27
|
+
The goal of `git stack` is to combine the **simplicity of developing in a single branch** in order to **preserve your commit history** while also **grouping commits into pull requests for code review**.
|
|
30
28
|
|
|
29
|
+
Often pushing all your commits to a single pull request is the simplest and fastest approach to development.
|
|
30
|
+
This comes at a price, your teammates have to review larger, less related pieces of code and you will lose some of your atomic commit history if you "Squash and merge".
|
|
31
31
|
|
|
32
|
-
|
|
33
|
-
|
|
32
|
+
When you decide to break changes up into multiple diffs that depend on one another this process is commonly referred to as **[stacked diffs](https://graphite.dev/guides/stacked-diffs)** (pull requests that depend on other pull requests).
|
|
33
|
+
This appraoch is popular at many major comparnies such as Twitter, Facebook, etc.
|
|
34
|
+
Managing stacked diffs manually involves managing multiple local branches, jumping between them, rebasing, etc.
|
|
34
35
|
This process gets even more complicated when you start getting feedback in code review and have to update individual branches.
|
|
35
36
|
Managing even a few stacked diffs requires a relatively strong knowledge of `git`, even with tricks like [`--update-refs`](https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---update-refs).
|
|
36
37
|
|
|
37
|
-
The goal of `git stack` is to combine the **simplicity of developing in a single branch** in order to **preserve your commit history** while also **grouping commits into pull requests for code review**.
|
|
38
38
|
|
|
39
39
|
## How is this different than **`x`**
|
|
40
40
|
|