Do you ever forget to commit a crucial file and end up with a broken build? Or your latest work is on your desktop, and you can't continue working on your laptop because you forgot to push? These are common challenges for developers, and we want to fix those with HighFlux.

HighFlux is a tool that automates git so that your code gets synchronized to GitHub automatically, similar to how Dropbox synchronizes your files as you change them.

Using HighFlux is simple and straightforward. After installing it, you can start creating automated feature branches (which we call WIPs, Works in Progress) to manage your code. Every WIP has a name, which will become the commit message once the branch gets merged.

After creating the WIP, you can start writing code as usual. If you notice a typo or want to make a change unrelated to your current WIP, you can easily create a new WIP and switch between them. HighFlux synchronizes your code to the local and remote git repository all the time, so you don't have to worry about stashing; a switch is always immediate.

The real-time synchronization also makes it easy for your colleagues to see what you're working on, if necessary. And when you're ready to submit your code for review, you can open the GitHub pull request with one click on the “Create Review” button.

With HighFlux, git becomes easy and hassle-free. Give it a try and see how it can improve your workflow.

Mathijs is one of the co-founders of HighFlux.io

HighFlux is a transformative git client that lets you automate tedious git tasks, get early feedback on your code, and prevent conflicts, all while maintaining the full power and flexibility of Git.

This year, we built HighFlux, a transformative git client that synchronizes code to the cloud while a developer is writing it. As a team with experience in mobile and web app development, building a desktop app was a new and exciting challenge for us. Here, we want to share the decisions we made and what we learned along the way.

Why Rust was the ideal choice for our app​

When we started, we needed to choose which core technology to use. We wanted a lightweight and fast solution that would not consume too much CPU or memory. Developers frequently run multiple programs, like an IDE, development servers, and potentially docker images, and HighFlux should leave as much CPU and RAM as possible available for those tools.

To meet these requirements we rejected garbage-collected technology like a JVM language (Kotlin would have been our preferred technology given our previous experience) or Go. Almost all information on the internet points in one direction: Rust is the modern non-garbage collected multi-platform language of choice right now.

Frontend: Tauri + React​

For the GUI, we chose the Tauri platform on which we built a React frontend. Tauri reuses an already installed browser on your system, so the app stays lightweight. Our final app is less than 20MB for all three platforms we’re targeting (Windows, macOS, and Linux).

Rust took a short while to get used to, but once we got the hang of the borrow checker and the tokio async runtime, development was productive and pleasant, with (libgit2)[https://github.com/rust-lang/git2-rs] as a big help in implementing our fully git-compatible code.

Supporting Windows, macOS and Linux from the start​

We considered doing a single platform launch first, but as between the three founders we use 2 out of the 3 platforms already, we decided we could launch for all three. With Windows being the least used platform by us as developers, that platform required the most tweaking: named pipes work differently than on UNIX platforms, UNC pathnames sometimes break stuff (thankfully, there’s a crate called dunce crate that simplifies this), and we ran into some issues with the maximum length of pathnames. Apple macOS required sending our builds to Apple for signing and notarizing to prevent users from having to click through a big scary security warning, and this also took some time to set up.

We ended up with one Rust codebase with a limited number of #[cfg(unix)] and #[cfg(windows)] classifiers for OS-specific code. The UI is a node React project without special cases for the different OSes.

Other choices​

Some other choices we made:

• We track any potential crashes of our app using Sentry’s Rust SDK.
• We use Rudderstack to log essential usage metrics to analyze our app's usage and make improvements. Rudderstack allows us to choose where we view our user events flexibly, and at this moment, we can view them in Google Analytics and Mixpanel.
• We created an in-app notification when there’s a newer version of our software that users can upgrade to. Unfortunately, there’s no good mechanism to automate the upgrade for the user yet. Upgrading software is a no-brainer in the web app and mobile app world, and, unfortunately, desktop apps don’t have a method that’s just as easy.

Overall, building a desktop app with Rust, Tauri, and React was a great experience. Rust's performance and safety made it a perfect fit, while Tauri and React allowed us to quickly develop a modern, lightweight GUI. Supporting all three platforms required some extra effort, but it was worth it to reach a wider audience.

Mathijs is one of the co-founders of HighFlux.io

HighFlux is a transformative git client that lets you automate tedious git tasks, get early feedback on your code, and prevent conflicts, all while maintaining the full power and flexibility of Git. Download now

Git is a beautiful work of engineering. It's blazingly fast even on massive repositories, and it efficiently manages vast numbers of branches.

These qualities have made git the dominant source control system, even though it's hard for humans to use.

So what's wrong with git?

Git commands are too many, too low-level and hard to understand.​

The git program is a collection of 157 commands:

The sheer number of commands is a problem. Even though it's pretty easy to master the most common 10 commands for day-to-day coding, you often run into commands you've never seen before. So git makes you feel like you're always a beginner!

Also, git commands are low-level operations, so they don't map exactly to things you want to do.

You need multiple commands to execute common actions (like "put my code on GitHub" and "make my coworker's code available in my editor").

Finally, some of the commands do quite different things depending on their parameters (e.g., git reset and git checkout), making them hard to understand.

Git has been trying to create less confusing commands (like splitting git checkout into git switch and git restore), but this creates even more commands to learn!

Git tracks 4 versions of files, instead of just "my" version and "the team's" version.​

When I'm working on a file, I mostly think about "my" version (what I'm working on in my editor) and "the team's" version (what the file looks like on GitHub).

Unfortunately, git has two more versions that I need to keep in mind: the one in the "index" (or "staging area") and the one in the HEAD commit in my local repository.

Because of the low-level commands and the 4 different versions, there's no single git command that tells git to just take a file I saved in my editor and update GitHub. Instead, I have to do the following:

# disk -> index/staging area
git add README.md
# staging area -> local branch
git commit
# local branch -> remote repository (e.g., GitHub)
git push origin branch

(The first two commands can be reduced to one with git commit -a, but beware: that will only add changed files and skip any new files you created while coding.)

Clearly, the 4-version internal git model complicates most common tasks.

Git doesn't let us safely experiment​

Most of us learn new tools by experimenting with them, but git is not set up for experimentation. It lacks "undo", "--dryrun", and safeguards against you deleting your own code.

• Undo would allow you to try some commands and backtrack if they don't lead to the right result.
• A dry run parameter would show you a summary of what a command does without making actual changes. If git had that, you could confidently explore commands and preview the effects before applying them.
• Finally, a safeguard against deleting code could prompt you with an extra warning before executing commands like git reset –hard or git push –force origin¹. If all commands that might cause you to permanently lose your data had a safeguard, you could experiment more.

Because these three features are missing, you can't casually experiment with git commands unless you want to risk losing code you spent hours working on.

In summary,** git forces you to convert commands that make sense to you into commands that make sense to git, and it punishes you for any mistake you make**.

The way forward: new tools will improve the git user experience.​

Despite the user experience issues, git will probably not be replaced by a new source control system. Instead, new tools on top of git can make it easier to use by converting commands that make sense to humans into commands that make sense to git. They will offer us fewer, more meaningful commands, automatically manage the 4-version model of git and make experimentation easy and safe.

Several tools are already out there:

• Gitless ²
• Sturdy
• legit
• jj
• Sapling: just opensourced yesterday by Meta
• HighFlux: our product, currently in beta

We're focused on improving the git user experience. We'd love to hear your thoughts:
discuss with us on Discord
or
follow us on Twitter.

Mathijs is one of the co-founders of HighFlux.io

HighFlux is a CLI and GUI that incorporates these ideas and is currently in beta.
Download now

More productive software development using the HighFlux method.

We've been programming most of our lives.

We always felt software development should be simpler, more enjoyable, and more productive.

The methodologies we used at Google transformed how the developer community and we worked. It popularized Trunk Based Development and code reviews.

Automated test and build tools offered by CI/CD companies and Git hosting services have also advanced it.

**Still, there are too many workflows, practices, and tools to choose from. **

Remote work, which we have practiced since 2011, adds unaddressed challenges to software development.

Over the years, we've selected the best practices that have proven to be the most effective for us in building Android apps, SDKs, SaaS platforms, games, and more.

The result is an opinionated process of code management and development workflow we internally call "The HighFlux method".

We spend most of our time coding a work in progress, while most tools are available only once the code is ready for review.

Being lazy programmers, we wrote some code to automate the HighFlux Method, allowing us to practice it without creating additional friction.

It turned into a git client written in Rust. But that's for a different blog post.

The HighFlux Method​

TL;DR: The HighFlux method is a descendant of trunk-based development and prescribes:

• Use a monorepo
• Use WIPs, not feature branches
• Use feedback early and often

Each of the above deserves its own post - but here's a short introduction:

Trunk based development​

A source-control branching model, where developers collaborate on code in a single branch called 'trunk' *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after."

– The trunk based development site

Use a monorepo​

Prevents dependency hell (including circular, diamond, conflicting, and, if you're really old DLL-hell)

There are so many other benefits explained in detail in this Google article. They include extensive code sharing (and duplication prevention), unified versioning, large-scale refactoring, better code security and compliance, atomic changes, cross-team collaboration, code visibility, and ownership.

WIPs, not feature branches​

WIP (work in progress) is the primary work unit. It is a short-lived branch with the following characteristics:

• Small - Small changes are proven to improve code quality and the team's velocity. They are easier to review. They get reviewed faster, and they're easier to test.

  Use a series of small incremental changes instead of one big change.

• Close to the trunk - Regularly (4 times a day) rebase your work over the fresh trunk.

• Short-lived - no more than 2-3 days of work in one WIP.

• One WIP per functionality - getting unrelated logical changes into a single WIP makes it harder to roll back and harder to review & test.

• Owned by a single developer - sharing branches causes long-lived, large changes.

• Merges into trunk atomically - resulting in one commit per WIP. History becomes clean and linear, Easy to bisect and roll back.

• Visible to the team at all times - Any team member's ability to view the code being written right now has transformed our work. It promotes code ownership and familiarity by all, and helps us be more efficient: write the right code, better, faster.

Early and often feedback​

• **Some changes do not need a review. **This deserves a dedicated blog post. the summary is that it can be fine in some scenarios, like a tiny change fixing typos in comments. The key is to be sure that there is no user impact risk, and that the probability of others contending against the change is minimal.

  Small pre-production teams working on an MVP, especially where each engineer has their domain, such as frontend and backend, might also find this useful.

• The start of a feature is the most critical time to review it.

• Pre-review - is done at the beginning of the work. Best done on a skeleton of code - empty methods that call each other, algorithm pseudo-code, or even off-code detailed design doc.

• It will save your teams' time, increase developer happiness, and prevent rapid tech-debt accumulation.

• Review the deliverable, not just the code - The running product: UI, CLI.

• Ad-hoc reviews - quickly ask and receive synchronous feedback for a snippet of code, a particular design, or an algorithm. The team should be able to answer such an ad-hoc review request within an hour or so.

• When reviewing others' work

  • Code reviews should be a high priority.
  • Focus on the important stuff - design, algorithm, efficiency, accuracy, correctness - NOT on code style, typos, or linting. The latter should be pre-submit hooks defined for all teammates.

• Some of the above can not be accomplished using current review tools.

How to practice?​

Some practices above are easy to follow, and some require setup, automation, and more structured, opinionated tools.

Here is a list of the functionality we need. We've already built some of it.

• Every code change is part of a WIP - no "index" or "staging" area. This is a controversial topic that presents real challenges. Overall we think the benefits outnumber the drawbacks.
• **Quick switching between WIPs **- this is important for "one commit per functionality", "review the product, not just the code", and "provide early and often feedback".
• Once switching between WIPs becomes easy, it allows us to respond to review and hotfix requests quicker.
• **Easily move hunks of code and files between WIPs **
• **Sync functionality that keeps everything close to the trunk: **pulling from trunk, and rebasing all WIPs upon new changes. (bonus: conflict prevention and detection).
• Continuously push all code to the git hosting service so that everyone (including machines!) can review work in progress early and often.
• **Ability to run "machine based early feedback" for all team members. **Including pre-submit code formatting and linting, continuous security and compliance checkers while writing code, all before PR is ready
• WIP size metrics (hey! You're WIP is too big) and Review time metrics (hey! You should review this code now) to ensure WIPs don't get too big.
• Support for Pre-reviews flow and Ad-hoc reviews flow.
• Continuous history - Freely go back or forward in time.

What's Next?​

This is a work in progress, and we still have much to cover.

If you're passionate about this stuff like we are and want to share your thoughts and learn more about ours - please join us on this discord server.

We hope to grow the community around the HighFlux method and bring this more productive way of working to the masses.

We (Uwe, Mathijs and Guy) are software engineers by profession and passion. We met at Google, and started our own companies since.

Throughout our careers, we felt we needed a well-defined framework for software development that improves velocity, productivity, and fun.

That's why we've been busy building the HighFlux git client in the past few months.

We use the HighFlux method to build the HighFlux git client, which is now in available for download.

You can now register for the waitlist to try out HighFlux.

Please fill out the form and we'll offer you an opportunity to try HighFlux and experience better code management as soon as possible!

We launched a first version of the documentation website today! 🎊🎉

The website gives a quick introduction to HighFlux and a step by step tutorial how to get started.

More advanced topics like architecture and configuration are also covered. Enjoy!