# GitUp: a macOS Git client that edits the repository graph directly

> GitUp is a GPL-3.0 macOS Git client built on a reusable toolkit called GitUpKit. It replaces commit-by-commit commands with a live graph, unlimited undo and repository snapshots, and it is only for macOS.

**git-up/GitUp** — The Git interface you've been missing all your life has finally arrived.

- Repository: https://github.com/git-up/GitUp
- Website: http://gitup.co
- Stars: 12,129 · Forks: 1,502
- Language: Objective-C
- License: GPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/git-up-gitup

## The problem GitUp targets: Git commands that hide what the repository is doing

The README opens with a complaint rather than a feature list: most engineers are still confused by Git's intricacy, and it points at the asymmetry between "git add" to stage and "git reset HEAD" to unstage. The stated goal is a new interaction model that lets engineers of all levels work quickly, safely, and without headaches. The audience is therefore not people who have never used Git. It is people who use Git daily, know what a rebase is, and still find the command surface a poor map of what is happening to their repository. The design bet is that the map should be the interface: you manipulate the repository graph instead of manipulating commits. That distinction matters for anyone who has ever run an interactive rebase and had to hold the resulting shape in their head. If your work is mostly linear commits on one branch, the graph is a thin thing and the payoff is smaller.

## How GitUp works: direct database access, a minimal libgit2 subset, and its own rebase engine

GitUp is unusual in that it interacts directly with the Git database on disk rather than driving the git command line. The README also describes GitUp as a thin layer on top of GitUpKit, a reusable generic Git toolkit, so the app and the framework share the same core. GitUpKit is organized as two independent layers that communicate only through public APIs. The base layer depends on Foundation only and is compatible with OS X and iOS; it contains Core/, a wrapper around the minimal functionality of libgit2 that GitUp needs, plus Extensions/, categories that add convenience features using only public APIs. The UI layer depends on AppKit and is OS X only, split into Interface/ for low-level views such as GIGraphView, Utilities/ for classes such as GIViewController, Components/ for single-view controllers such as GIDiffContentsViewController, and Views/ for multi-view controllers such as GIAdvancedCommitViewController. The README is explicit that GitUpKit is not ObjectiveGit: instead of extensive raw bindings to libgit2, it uses a minimal subset and reimplements the rest, including its own rebase engine, and GitUp itself uses a slightly customized fork of libgit2. That is the architectural trade-off: a tighter, more consistent API that hides libgit2 complexity, at the cost of reimplementing machinery you would otherwise inherit.

## Installing GitUp and opening a repository for the first time

The README points to the official website at gitup.co and to the GitHub releases page for the latest build. Homebrew also works, though the README notes the formula is not maintained by the GitUp developers.

```bash
brew install gitup-app
```

Releases are split by tag prefix. Builds tagged with a v, such as v1.2.3, go to the Stable channel; builds tagged with a b, such as b1234, go to the Continuous channel. The update channel is a setting in the app preferences, so the first thing to decide after installing is which stream you want. If you would rather build it yourself, the README gives a single clone command, then asks you to open the Xcode project and hit Run.

```bash
git clone --recursive https://github.com/git-up/GitUp.git
```

The recursive flag is not optional: the repository has a .gitmodules file, and the build depends on the submodules being present. Open GitUp/GitUp.xcodeproj and run the Application target. The README warns that without an Apple ID with a developer account for code signing Mac apps, the build fails with a code signing error, and the workaround is to delete the Code Signing Identity build setting of the Application target. If you do have a developer account, the alternative is to create Xcode-Configurations/DEVELOPMENT_TEAM.xcconfig containing the DEVELOPMENT_TEAM setting with your TeamID. Once the app is running, the interface you land in is the live repository graph; the README lists editing, reordering, fixup and merging commits as graph operations, with unlimited undo and redo covering almost all operations including rebases and merges.

## Where GitUp stops being the right tool

The first limitation is the platform. The UI layer depends on AppKit and is compatible with OS X only, so there is no GitUp for Windows or Linux. The base layer of GitUpKit claims iOS compatibility, but that is the framework, not the app. The second limitation is the build path. The README's own instructions assume Xcode and an Apple developer account, and the documented failure mode is a code signing error that you resolve by deleting a build setting. That is a normal macOS developer workflow and an unreasonable one for a team that just wants a binary. The Homebrew formula exists but is explicitly not maintained by the GitUp developers, so its cadence is someone else's problem. Third, the repository does not document rollback of the app itself, and the README does not document a CLI or a headless mode; this is a GUI, and scripting it is not part of the described surface. Finally, the DEBUG constant is worth knowing about if you build GitUpKit: when it is defined to a non-zero value, which the README says is the default in the Debug configuration, extra consistency checks and extra logging are enabled at run time. That is a debugging aid, not production behaviour, and the README's sentence on it is cut off mid-thought, so treat the exact scope of those checks as undocumented.

## GitUpKit versus ObjectiveGit: two different answers to wrapping libgit2

The clearest alternative named in the README is ObjectiveGit, and the README draws the line itself. ObjectiveGit offers extensive raw bindings to libgit2. GitUpKit deliberately does the opposite: it uses a minimal subset of libgit2 and reimplements everything else on top, with its own rebase engine as the example given. The practical difference is what you get in the API. Raw bindings hand you libgit2 concepts close to the metal and leave the composition to you; GitUpKit exposes a tighter API that follows Objective-C conventions and hides libgit2 complexity and, in the README's words, sometimes inconsistencies. GitUpKit then adds features the bindings do not provide, such as undo/redo, Time Machine style snapshots, and drop-in UI components. If you are writing a Git tool for Apple platforms and want control over every libgit2 call, ObjectiveGit is the closer match. If you want a working rebase engine and ready-made views, GitUpKit is the shorter path, and the README names Retcon as an app built this way. Beyond that pairing, the general alternative is the git command line itself, which needs no install and no code signing but has none of the graph editing, undo or snapshot behaviour described here.

## Licence, maintenance and the cost of upgrading

GitUp is licensed GPL-3.0, and the LICENSE file sits at the top level of the repository. The README frames the open sourcing as a gift to the developer community after roughly 30,000 lines of code. For anyone embedding GitUpKit in their own product, that copyleft licence is the first thing to read in full rather than skim, since it governs distribution of derivative work; this is a description of the licence, not legal advice. On maintenance, the repository is not archived and the last push was on 2026-09-18. The release history shows both channels in use: v1.5.0 tagged as a Tahoe release on 2026-07-15, and a 1.6.0 Beta 1 build tagged b1059 on 2026-09-18. Because the tag prefix decides the channel, upgrading is not a single track. If you stay on Stable you wait for v-tagged builds; if you switch to Continuous in the app preferences you take b-tagged builds such as the 1.6.0 beta. The upgrade cost that is actually documented is at the build level: UPDATING-LIBGIT2.md exists at the top level, which tells you the customized libgit2 fork is something the maintainers expect to rebase deliberately rather than absorb automatically.

## Conclusion

GitUp fits macOS developers who rewrite history often and want undo and snapshots around rebases and merges, plus anyone building a Git UI on GitUpKit. It is the wrong choice on Windows or Linux, and it is not a fit if you need a client that installs without Xcode or Homebrew. Before adopting it, confirm the release channel you want in the app preferences, and if you build from source, check that GitUp/GitUp.xcodeproj opens with the submodules cloned.

## FAQ

### What is GitUp and how does it work?

GitUp is a macOS Git client that interacts directly with the Git database on disk, and it is built as a thin layer on top of the reusable GitUpKit framework. Rather than manipulating commits, you manipulate the repository graph, with unlimited undo and redo and Time Machine style snapshots.

### What does GitUp mean?

The README does not explain the name. It only states that GitUp was created by @swisspol in late 2014 as a bet to reinvent the way developers interact with Git, and that it reached 1.0 in mid-August 2015.

### How do I install GitUp on a Mac?

The README points to the latest release on GitHub and to the official website at gitup.co, and notes that Homebrew also works with brew install gitup-app, though that formula is not maintained by the GitUp developers. Building from source means cloning with git clone --recursive, opening GitUp/GitUp.xcodeproj in Xcode and running the Application target.

### What is the difference between the Stable and Continuous channels in GitUp?

Builds tagged with a v, such as v1.2.3, are released on the Stable channel, while builds tagged with a b, such as b1234, are only released on the Continuous channel. The update channel used by GitUp is changed in the app preferences.

### Does GitUp run on Windows or Linux?

No. The README states that the UI layer of GitUpKit depends on AppKit and is compatible with OS X only, and GitUp itself is described as a Git client for Mac. The base layer is compatible with OS X and iOS, but that is the framework rather than the app.

## Sources

- [git-up/GitUp on GitHub](https://github.com/git-up/GitUp)
- [License: GPL-3.0](https://github.com/git-up/GitUp/blob/master/LICENSE)
- [Project website](http://gitup.co)
- [README](https://github.com/git-up/GitUp/blob/master/README.md)
- [Releases](https://github.com/git-up/GitUp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/git-up-gitup