Crates.io | git-stack |
lib.rs | git-stack |
version | 0.10.17 |
source | src |
created_at | 2021-08-18 03:11:57.588952 |
updated_at | 2023-08-09 14:50:09.247784 |
description | Stacked branch management for Git |
homepage | |
repository | https://github.com/gitext-rs/git-stack.git |
max_upload_size | |
id | 438778 |
size | 474,500 |
Stacked branch management for Git
Dual-licensed under MIT or Apache 2.0
Like Stacked-Diffs? git-stack
is another approach to bringing the
Stacked Diff workflow
to PRs/branches that aims to be unintrusive to a project's workflow. Branches are the unit
of work and review in git-stack
. As you create branches on top of each
other (i.e. "stacked" branches), git-stack
will takes care of all of the
micromanagement for you.
Unfamiliar with Stacked-Diffs? git-stack
helps automate a lot of common
workflows when dealing with PRs, especially when you start to create PRs on top
of PRs.
Features:
git revise
)--push
, detects which branches are "ready" (e.g. root of stack, no WIP)Non-features
git-stack
will give up and you'll have to use
git rebase
yourself to resolve the conflict.To see how git-stack
compares to other stacked git tools, see the Comparison.
From your feature branch, run:
jira-3423423 $ git stack --pull
git stack --pull
:
main
).git pull --rebase <remote> <parent>
jira-3423423
(and any dev branches on the stack) onto <parent>
See Getting Start for a complete workflow example.
The closest equivalent is:
jira-3423 $ git checkout main
main $ git pull --rebase upstream main
main $ git checkout jira-3154
jira-3154 $ git rebase HEAD~~ --onto main
jira-3154 $ git checkout jira-3259
jira-3259 $ git rebase HEAD~ --onto jira-3154
jira-3259 $ git checkout jira-3423
jira-3423 $ git rebase HEAD~ --onto jurao-3259
jira-3423 $ git log --graph --all --oneline --decorate main..HEAD
For more, see Command Reference
Parent branch auto-detection works by separating the concept of upstream-controlled branches (called "protected branches") and your development branches.
Download a pre-built binary (installable via gh-install).
Or use rust to install:
$ cargo install git-stack
We also recommend installing
git-branch-stash
for easily
undoing git stack
operations:
$ cargo install git-branch-stash-cli
git-stack
Aliases: To avoid name collisions while keeping things brief, git-stack
ships as one binary but can help configure aliases by running git stack alias --register
. You can then modify the aliases if you want to make
some flags the default.
Protected branches: These are branches that git-stack
should not modify.
git-stack
will also rebase local protected branches against
their remote counter parts. Usually you mark shared or long-lived branches as
protected, like main
, v3
.
Run git-stack --protected -v
to test your config
git-stack --protect <glob>
.git-stack
as a team, you can move the protected branches from
$REPO/.git/config
to $REPO/.gitconfig
and commit it.Pull remote when working from a fork, where upstream is a different remote than
origin
, run git config --add stack.pull-remote <REMOTE>
to set your remote in $REPO/.git/config
.
To see the config, run git-stack --dump-config -
.
For more, see Configuration Reference.
If you registered aliases, you'll want to run git stack alias --unregister
to remove them.
See the uninstall method for your installer.
Once removed, git-stack
leaves behind:
.git/branch-stash
Removing this is safe and will have no effect.
$ # Update branches against upstream
$ git sync
$ # Start a new branch / PR
$ git switch -c feature1
$ git add -A; git commit -m "Work"
$ git add -A; git commit -m "More Work"
$ git run cargo check
$ git prev
$ git add -A; git amend # Fix problems in "Work" commit
$ git run cargo check
$ git next
$ # See what this looks like
$ git stack
$ # Clean up in preparation for a push
$ git sync
$ # Push whats ready
$ git stack --push
For more, see Command Reference.
This is up to you. Some might prefer to have linear development (single branch) and just manipulate ordering within that.
For me, I prefer to stack branches of related work or when there is a dependency between them, like a feature being stacked on top of a refactor to enable that feature
git switch feature1 && git switch -c feature2
and start adding commitsgit stack --rebase --base feature1 --onto main
moves feature2
to main
, from off of feature1
git stack
: git rebase feature1 --onto main
This works like normal, just checkout the branch you want to base the feature on and start adding commits.
For example:
$ git switch feature1
$ git switch -c feature2
git commit --fixup <ref>
and then git-stack --rebase
will move it to where it needs to be.git rebase -i
Currently, Github is limited to showing all commits for a branch, even if some of those commits are "owned" by another PR. We recommend only posting one PR at a time within a stack. If you really need to, you can direct your reviewers to the commits within each PR to look at. However, you will see the CI run status of top commit for each PR dependency.
If a commit summary is only WIP
or is prefixed by:
WIP:
draft:
Draft:
wip
WIP
This includes the prefixes used by Gitlab
git branch-stash
git-branch-stash
is a
separate utility that is like git stash
for instead of your working tree, it
stashes what commit each of your branches points to. git stack
backs up
using git branch-stash
s file format to lower the risk of trying things out
with git stack
.
Have an idea, we'd love to hear it!
There are probably git
operations or workflows we haven't heard of and would
welcome the opportunity to learn more.