Branchless workflow for Git
git-branchless is a suite of tools to help you visualize, navigate, manipulate, and repair your commit history. It's based off of the branchless Mercurial workflows at large companies such as Google and Facebook.
Demos
Repair
Undo almost anything:
- Commits.
- Amended commits.
- Merges and rebases (e.g. if you resolved a conflict wrongly).
- Checkouts.
- Branch creations, updates, and deletions.
Why not git reflog?
git reflog is a tool to view the previous position of a single reference (like HEAD), which can be used to undo operations. But since it only tracks the position of a single reference, complicated operations like rebases can be tedious to reverse-engineer. git undo operates at a higher level of abstraction: the entire state of your repository.
git reflog also fundamentally can't be used to undo some rare operations, such as certain branch creations, updates, and deletions. See the architecture document for more details.
What doesn't git undo handle?
git undo relies on features in recent versions of Git to work properly. See the compatibility chart.
Currently, git undo can't undo the following. You can find the design document to handle some of these cases in issue #10.
- "Uncommitting" a commit by undoing the commit and restoring its changes to the working copy.
- In stock Git, this can be accomplished with
git reset HEAD^. - This scenario would be better implemented with a custom
git uncommitcommand instead. See issue #3.
- In stock Git, this can be accomplished with
- Undoing the staging or unstaging of files. This is tracked by issue #10 above.
- Undoing back into the middle of a conflict, such that
git statusshows a message likepath/to/file (both modified), so that you can resolve that specific conflict differently. This is tracked by issue #10 above.
Fundamentally, git undo is not intended to handle changes to untracked files.
Comparison to other Git undo tools
gitjk: Requires a shell alias. Only undoes most recent command. Only handles some Git operations (e.g. doesn't handle rebases).git-extras/git-undo: Only undoes commits at currentHEAD.git-annex undo: Only undoes the most recent change to a given file or directory.thefuck: Only undoes historical shell commands. Only handles some Git operations (e.g. doesn't handle rebases).
Visualize
Visualize your commit history with the smartlog (git sl):
Why not `git log --graph`?
git log --graph only shows commits which have branches attached with them. If you prefer to work without branches, then git log --graph won't work for you.
To support users who rewrite history extensively, git sl also points out commits which have been abandoned and need to be repaired (descendants of commits marked with rewritten as abcd1234). They can be automatically fixed up with git restack, or manually handled.
Navigate and manipulate
Rewrite history without fear:
Why not `git rebase -i`?
Interactive rebasing with git rebase -i is fully supported, but it has a couple of shortcomings:
git rebase -ican only repair linear series of commits, not trees. If you modify a commit with multiple children, then you have to be sure to rebase all of the other children commits appropriately.- You have to commit to a plan of action before starting the rebase. For some use-cases, it can be easier to operate on individual commits at a time, rather than an entire series of commits all at once.
When you use git rebase -i with git-branchless, you will be prompted to repair your history if you abandon any commits.
About
The branchless workflow is designed for use in a repository with a single main branch that all commits are rebased onto. It improves developer velocity by encouraging fast and frequent commits, and helps developers operate on these commits fearlessly.
In the branchless workflow, the commits you're working on are inferred based on your activity, so you no longer need branches to keep track of them. Nonetheless, branches are sometimes convenient, and git-branchless fully supports them. If you prefer, you can continue to use your normal workflow and benefit from features like git sl or git undo without going entirely branchless.
Installation
See https://github.com/arxanas/git-branchless/wiki/Installation.
Short version: run cargo install git-branchless, then run git branchless init in your repository.
Status
git-branchless is currently in alpha. Be prepared for breaking changes, as some of the workflows and architecture may change in the future. It's believed that there are no major bugs, but it has not yet been comprehensively battle-tested. You can see the known issues in the issue tracker.
git-branchless follows semantic versioning. New 0.x.y versions, and new major versions after reaching 1.0.0, may change the on-disk format in a backward-incompatible way.
To be notified about new versions, select Watch » Custom » Releases in Github's notifications menu at the top of the page. Or use GitPunch to deliver notifications by email.
Related work
See the Architecture page for work related to the implementation of git-branchless.
Alternative tools:
~krobelus/git-branchstack: A tool which allows you to make all of your commits to one branch, and then automatically split them up into separate branches later based on their topic.- Stacked Git: This tool lets you efficiently manage a stack of patches alongside your regular work. In comparison,
git-branchlessencourages that you commit all of your work directly and manipulate those commits directly. - Git Patch Stack: Similar to Stacked Git, specifically intended to support using a pull request workflow.
- Jujutsu: An experimental, Git-compatible VCS. Supports anonymous branches, undo, checked-in conflicts, auto-rebase. Uses a completely different CLI (
jjinstead ofgit) and does not work in a Git working copy, but can work as an alternative working copy (likegit worktree).
Complementary tools:
git-absorb/git-autofixup: These tools let you take your current changes, at the top of a stack, and intelligently "absorb" them into previous related changes in the same stack.git-revise: This tool lets you "efficiently update, split, and rearrange git commits" without touching the working copy.
-
最近准备给同事培训git，发现了一个不错的资源，在这里：http://www.gitguys.com/topics/creating-a-shared-repository-users-sharing-the-repository/ 原文如下，有空再译： ommands discussed in this section: git init –bare git clone git remote
-
创建一个新文件 ~/.gitignore ，并将以下内容添加进去，这样全部 git 仓库将会忽略以下内容所提及的文件。 # Folder view configuration files .DS_Store Desktop.ini # Thumbnail cache files ._* Thumbs.db # Files that might appear on external disks .S
-
功能分支(feature branches)、发布分支(release branches)、主干(master)、开发分支(develop)、紧急修复分支(hotfixes)和标签(tag)。 Git Flow 太复杂 Git Flow 违背了分支的“短命”原则:在使用 Git 时，在同一个分支上开发代码的人越多，出现合并冲突的几率就越高。在使用 Git Flow 后，冲突几率会变得更高，因为还有
-
规范建设 commit message格式 <type>(<scope>): <subject> type(必须) 用于说明git commit的类别，只允许使用下面的标识。 feat：新功能（feature）。 fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。 fix：产生diff并自动修复此问题。适合于一次提交直接修复问题 to：只产生diff不自动修复此问题
-
集中式与分布式 中心服务器 工作流 分支实现 冲突 Fast forward 储藏（Stashing） SSH 传输设置 .gitignore 文件 Git 命令一览 参考资料 集中式与分布式 Git 属于分布式版本控制系统，而 SVN 属于集中式。 集中式版本控制只有中心服务器拥有一份代码，而分布式版本控制每个人的电脑上就有一份完整的代码。 集中式版本控制有安全性问题，当中心服务器挂了所有人都没
-
作为一名开发者怎么可能没有 Git 呢? 我们马上就来安装： $ brew install git 好的，现在我们来测试一下 git 是否安装完好： $ git --version 运行 $ which git 将会输出 /usr/local/bin/git. 接着，我们将定义你的 Git 帐号（与你在 GitHub 使用的用户名和邮箱一致） $ git config --global user.
-
Name git - 迟钝的内容跟踪器 概要 git [--version] [--help] [-C <path>] [-c <name>=<value>] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] [-p|--paginate|--no-pager] [--no-replace-objects]
-
Overview 始终没有很好的掌握Git， 这又是Stage又是Stack的，每次冲突都要找同事来帮忙解决。 Tools 貌似SmartGit最美观最好用，但License始终是个问题，只有非商业软件才能免费用。 SourceTree最大问题是不能按目录来查看文件和Log。 Commands remove tag remotelly git tag -d V4.0.0.GA git push o
-
Git 可以为项目做版本控制项目。 先搜索一下： yum search git 我看到一些 git2u 这个前缀的包，这应该是 ius 仓库提供的。 安装 Git： sudo yum install git2u -y 如果出现冲突的提示，是因为你的系统里已经包含了 Git，需要先删除掉系统里的 Git 才能继续安装。 再做一点简单的配置，告诉 Git 我们是谁： git config --g