git-stack-cli 0.7.2 → 0.7.3

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.
Files changed (2) hide show
  1. package/README.md +43 -3
  2. package/package.json +1 -1
package/README.md CHANGED
@@ -1,8 +1,19 @@
1
1
  # git-stack-cli
2
2
 
3
- > create stacked diffs (PRs) on Github from a single branch by grouping commits
3
+ - 🚀 **Simple one-branch workflow**
4
+ - 🎯 **Interactively select commits for each pull request**
5
+ - 📚 **Preserve your detailed commit history**
6
+ - ♻️ **Automatically synchronize each pull request in the stack**
7
+ - 💬 **Group commits for focused code review**
8
+ - 🚫 **Avoid mutiple branch juggling and complex rebasing**
9
+ - 💪 **Work seamlessly with GitHub's interface**
10
+ - 🌐 **Leverage the [official GitHub CLI](https://cli.github.com/)**
4
11
 
5
- ## install
12
+ ## Demo
13
+
14
+ > <img src="https://github.com/magus/git-multi-diff-playground/assets/290084/cc583c01-4c3b-4416-b6a5-9702e5401c1b" width="720">
15
+
16
+ ## Install
6
17
 
7
18
  ```bash
8
19
  npm i -g git-stack-cli
@@ -10,7 +21,34 @@ npm i -g git-stack-cli
10
21
  git stack
11
22
  ```
12
23
 
13
- ## development
24
+
25
+ ## Why?
26
+
27
+ Most developers might not see much reason to **preserve commit history** or **create multiple pull requests of smaller changes**.
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.
30
+
31
+
32
+ Okay, so you decide to break changes up. This process is commonly referred to as **[stacked diffs](https://graphite.dev/guides/stacked-diffs)** (pull requests that depend on other pull requests).
33
+ Manually this means managing multiple local branches, jumping between them, rebasing, etc.
34
+ This process gets even more complicated when you start getting feedback in code review and have to update individual branches.
35
+ 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
+ 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
+
39
+ ## How is this different than **`x`**
40
+
41
+ ### [`ghstack`](https://github.com/ezyang/ghstack)
42
+
43
+ - `git stack` automatically synchronizes each pull request in your stack, as needed
44
+ - `git stack` does not create local branches (instead it annotates commits locally with metadata to denote groups of commits, e.g. `git-stack-id: E63ytp5dj`)
45
+ - `ghstack` requires rebasing and squashing since each commit creates a pull request, which means you lose commit history
46
+ - `git stack` allows developing in a single local branch and selecting groups of commits for each pull request
47
+ - `git stack` adds a clear comment to each pull request in the stack showing the entire stack
48
+ - `git stack` does not break if you land pull requests through Github directly, `ghstack` requires landing from the command-line interface
49
+ - `git stack` uses the [official GitHub CLI](https://cli.github.com/) (`gh`) instead of personal access tokens
50
+
51
+ ## Development
14
52
 
15
53
  ```bash
16
54
  npm run dev
@@ -18,3 +56,5 @@ npm link
18
56
 
19
57
  git stack --verbose
20
58
  ```
59
+
60
+
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "git-stack-cli",
3
- "version": "0.7.2",
3
+ "version": "0.7.3",
4
4
  "description": "",
5
5
  "author": "magus",
6
6
  "license": "MIT",