My choice is the VCS client in JetBrains IDEs, like IntelliJ, WebStorm, PyCharm etc.
IntelliJ Community Edition is even free and open-source, so for Java coding it's perfect, but pretty good for Clojure, Python, PHP too.
The JetBrains IDEs are cross-platform, including Linux and cross architecture, including ARM, because the JVM/JDK is cross-arch.
The sticking point for me is how well it deals with the 3-way resolution of merge conflicts.
It also has a magic-wand icon, which seems to resolve 95% of conflicts automatically and correctly, presumably doing something based on common ancestor commits.
BUT what makes both this 3-way merge interface AND the commit interface really great, is the ability to edit in-place, with all your custom keybindings, syntax highlighting, linting and code intelligence tools!
You can auto-complete code, look up docs or the source code of function definitions, even in JAR files, without leaving the context of the commit dialog.
If you need to do something more involved, like refactoring or jump to definition, u can always get to the source code with F4 from the commit dialog or from within any commit context.
You don't know what are you missing out on, until you experience it!
It's a significant reduction in mental overhead, imho.
Now the cost of all this convenience is that you need to download hundreds of megabytes and IntelliJ CE has a substantial startup time and memory consumption, since it indexes your code. It also sprinkles your repo with projects files under a .idea folder.
I will check out Fork regardless, because it's good to know what's out there and what are the different set of tradeoffs it choose. Then I can choose and/or recommend it for different situations.
It's the same reason I'm learning vc.el and magit too. If you need to do some git surgery over high-latency SSH, then it's hard to beat Emacs with TRAMP...
Fork is the only GUI in Mac performant enough to handle my work monorepo. That alone would be sufficient, but it's also a stellar client with great support for things like interactively rebasing and handling merges. I can do roughly everything I need, faster, in its UI.
I've found Fork to be faster than Gitup for very large repos. I used to use Gitup exclusively but switched to Fork a few years back. The graph drawing in Gitup can get bogged down when you have hundreds of branches. I still love that representation of branches but I'm usually not that confused about the repo state and I've found the vertical layout that Fork uses to be sufficient.
I tried a few Git clients over the years and am proficient with the CLI.
My impression is that Fork captures how git actually works better than some of the other GUI tools and it has a lot of handy features that make certain tasks a pleasure instead of a chore (common rebasing things, add/deleting/changing local/remote branches, splitting up changes in single files into multiple commits - this is maybe be an antipattern but I do it frequently enough).
Also, it's very cheap. I hope they make enough money with it to continue development.
Our whole team works with git fork and we're really happy with it. You can browse the repo at a specific commit, branch, merge, rebase and blame everything from the gui. I rarely need to fall back to the command line and there's even the option to add custom commands to the gui. And it's really fast, even with multiple repos.
Just had an issue today and Dan replied in less than 5 minutes. Thumbs Up
Been using Fork for several years now, and it’s great. It’s exactly what I look for in a tool: capable, yet focused and fast, with everything being as it should right out of the box. It never feels like it’s getting in the way.
I use it along with Secretive[0] to keep GitHub SSH keys in my MacBook’s Secure Enclave and add a biometric prompt whenever pushing or pulling. All together it’s extremely smooth and unfussy.
I discovered this on the day pandemic was declared, god this tool is well polished and is so great.
It is closed source but that shouldn’t be a blocker, its not like every app we use is open-source and not everyone is going to take a look under the hood.
I think it was a two people team(a couple) if Im not wrong. Awesome work guys!
The UI does look really good, but I do wonder how much of the dev community uses a GUI vs just sticking in the command line?
Personally the only GUI stuff I find useful are the features that are already part of VSCode (live showing what I have changed or doing a diff). Outside of that I generally find that any GUI for git just inevitably makes something just opaque enough that I don't really know for sure what I am about to commit or where I am pushing too. For me "git status" >> "git add XYZ" >> "git status" >> "git push" are so ingrained in my workflow that I don't get that feedback in any UI I have seen.
I have started to dip my toes into it a bit now with the Atlassian integration that can name new branches properly... but even using that just gives me a weird disconnect with what is actually happening that it doesn't feel right. After the creation of the branch I am back to my cli.
Maybe it is just because I live in the command line anyways (enough so that I have iTerm setup to just pop up from the bottom of my screen with a keyboard command) that I just feel more comfortable with the command line?
I just feel like I am missing something here since I know some do rely on these tools heavily.
I work 100% in a git UI. Everything but merge diffs I do in Sourcetree... for diffs I use VS. It's how I've learned. Here's some of my scattered reasoning:
- It's a separate, dedicated application to do just my source control
- Keeping repos in tabs makes it easy to switch between projects (yes, you could use screen or some other multiplexer, but it's just not as fast for me)
- I'm Windows
- Easier to review history / merges at a glance
- Sucks that SourceTree doesn't have diffing, but it's much easier to do diffs/merge conflict resolution in a UI
- Clicking through items to see what's staged/unstaged is quick
I use both the git CLI and Fork for different tasks. For the `git add` workflow you describe I use the CLI exclusively, and for interactive rebase it's about half and half.
An example where Fork comes in handy is deleting branches, especially on remotes. It's pleasant to see all the branches and just click on the ones I want to delete, and not have to deal with git CLI's differences between deleting local and remote branches, or remember how git deletes remote branches this week.
In my case my git usage is so mundane that the most basic of its CLI commands are sufficient 98% of the time. Reaching for the more advanced commands is so infrequent that they don't ever stick meaning I'm always looking them up (and probably subsequently screwing them up).
My work is scattered across different IDEs/editors too so the differing UI conventions of integrated VCS make that more trouble than it's worth.
So I just use Fork all the time. It covers base case very well regardless of the project, and on the occasion that I need to do something more fancy I can do it without pulling up docs and with far fewer screwups.
Unrelated to fork itself, but I always wonder how do people implement the vertical colored lines representing branches and merges. This is present in almost all git desktop clients, and of course very useful.
Going further afield into tangent, I love the looks of these "subway diagrams" of the commits, but I keep thinking that as great as they look and as nice screenshots as they make what I'd love to see a Git UI do is something very different: take a --first-parent approach by default and use a drilldown/expandable view of commits past first parent. It would look a lot more boring in screenshots, but could be a great way in practice to ease people into the two dimensional git DAG without making it seem so messy/busy by default. Many projects it would provide a good "PR focused" view of the repository up front and center (without being reliant on specific PR tools/APIs, only that those PR tools create merge commits).
Going off to a different tangent: the vertical colored lines down the side of a list of chronologically ordered items to show reply threads was a visualization I first spotted in the early oughts or late 90s from a showcase of Microsoft Research Visualizations and so Microsoft Research has published research and had patents on it at one time. Those patents have all since expired, I believe, but it's interesting to note that it was on some minds even back then, which was neat, and curious to wonder what if a Microsoft product had embraced it earlier. (I recall the demo felt a lot like Outlook's email list and the impression was that was what they were trying to sell it as a possible tool to the Outlook team. Which seemed a neat idea for email visualization, though I think Outlook decided that strict temporal ordering wasn't necessary for reply threading that users were happy enough with.)
Hi. In Fork you can expand/collapse nodes in the graph. Collapsing all (i.e. --first-parent) and then expanding particular merge commits is also possible.
Good to know. I'm just thinking it might be useful as a default.
I'm also thinking that it's related to that "why didn't Outlook end up using 'subway diagrams'?" question: maybe strict chronological ordering isn't necessarily the best focus for commit ordering with respect to "top-level" merge commits.
Anyway, not a direct criticism of your app specifically, more just a long slow stewing of my own thoughts on the subject that I likely won't ever get around to even prototyping, in case they do congeal into something worth prototyping. You are certainly ahead of me there by having built a thing, and I appreciate that.
Right now I don't think enough people appreciate the idea of --first-parent as a default in as many views as possible (especially as opposed to how many seem to prefer squash/rebase-based workflows solely based on gut reactions to how the "subway diagrams" can look), and I like mentioning that in case it sparks ideas for other people to maybe find workflows that they like more than that (and can take advantage of the 2D nature of the git DAG possibly better than "straight line" approaches).
I'm probably rambling at this point, because yeah I still haven't quite found the right "shape" of this idea and it is interesting to think out loud about it.
it is part of my workflow for years. I prefer direct git commands. But sometimes it is nice to explore history and complex changes there. And most of the parameters are the same as `git diff ...` just `tig ...` with (almost always) same values for the ellipsis.
I struggled with anything besides committing or pushing when I first started using Git. People keep trying to make better GUI's to account for this, but going and in and learning how to use the command line and reading Pro Git really was the best solution. It's so much easier to work with.
I'm a paying user of Fork, it's my favorite Git GUI, I love it.
However, it "only" supports macOS and Windows. I'm migrating to Linux for my work and home computers, so I haven't used Fork in a while, just so I can get familiar with other tools available on Linux - and, importantly, learning to do more advanced Git operations in the terminal.
So far I still depend on a GUI, mainly VS Code's built-in Git integration and the GitGraph extension. (One of the advantages of this setup is that it also works for remote SSH editing.)
..But I sure miss using Fork. I used it everyday for the last couple years. It does everything I want to do with Git, the UI is familiar and well-designed. I whole-heartedly recommend it.
I see the main developer @DanPristupov is on HN, maybe he'd consider supporting Linux? I totally understand if you won't, since creating the same application for two OSes must be quite difficult already, especially for a small team rather than a company.
I think it doesn't count characters in the body but I am sure Dan could add this as optional feature (though I think it's a bad idea to enforce 80 chars there. Maybe a max line length would be better).
Also, I think it doesn't enforce the limits but counts down letters and if you're above the 50 chars for the message it shows a negative char count in bright red (which makes me reconsider what I want to tell my coworkers in that message).
My statement about the character limits was incorrect and ambiguous. Git-cola is similar. It displays the number of characters and a color. No color for up to 64, yellow to 72, orange to 78, and red above that.
The body wraps the next word onto a new line if it crosses past 72 characters. (By default, that is configurable and disable-able)
Those are fairly arbitrary choices, but they work well enough for me in practice and help keep my titles/messages clean and readable.
If Fork could do something similar (the auto-wrapping and title warning) I'd be happy.
Enable 'monospace font in commit description' in Fork preferences and set the guideline for the description width. You can wrap the commit message using the context menu option in the description field.
I've gone ahead and downloaded/installed git-fork and did some brief testing with the features I use most in my existing client. I've sent feedback based on that.
Never heard of GittyUp, but I used to use the GitHub desktop client. It was great originally, but then they rewrote it with Electron and it’s been a shadow of its former self ever since.
Hi. Dan from Fork is here. I guess there's some mistake. I answer a lot of user questions daily and this is the first time I hear about such a feedback. I would really appreciate if you could send me any details (by email or using the feedback button on the toolbar in Fork).
My experience has been exact opposite. SourceTree has been regressing since going Atlassian and Fork has been rock solid for years, especially for large repos.
Opposite situation for me. I've been using Sourcetree for YEARS and it was a PITA, so bad, slow and counterintuitive. On the other hand Fork saved my mental health and it's by far the best git manager I've always used. This is the only software I would be happy to pay for.
I also had the opposite experience. I used Sourcetree for a while, but the performance became really bad, so I switch to Fork and have never looked back.
Does this handle LFS file-locking? Very handy for repos with lots of binaries (eg game dev), but also almost wholly unimplemented in the most popular Git GUI clients.
SmartGit supports it too but I find that even with access to it, its less useful than with something like P4 simply because git style ends up using more branches and locks don't work across branches.
I’m in no position to comment, unfortunately - I do game dev as a hobby with a small number of collaborators and tend not to use branches at this stage. Hopefully someone more knowledgeable will jump in. I use two different dev machines, though, so locking of binary files is essential.
I will say that I ended up going with Git (+ LFS) for two reasons. I was comfortable with it from my other work and, more importantly, P4 felt like an absolute car crash - one of the worst pieces of software I’ve had the misfortune to use in the past few years. Unless and until I’m forced to use it, I’ll stick with Git.
Yes, you can lock and unlock LFS files using file context menu. There's also the ability to see the list of locked files (and force-unlock one, if needed).
Excellent, thank you - I’m trialling it now. Loads of positive comments for your product on this thread. High quality paid native Mac software from smaller developers is one of my favourite things about the ecosystem.
Being honest, we don't use LFS internally, so dogfooding doesn't really work in this area. If you don't like something or you have an idea how we can improve LFS support in Fork, please feel free to contact me directly.
Fork is great -- except for when you try and google about it b/c at least for me, I haven't been able to differentiate my queries between the git fork operation and git Fork the UI.
Also on my local machine, push to remote gitlab does not work reliably and I have to push via command line. Have not been able to find a solution, but also haven't done more than googling about it.
File -> Accounts -> + -> GitLab should solve the problem. Otherwise, contact me using the feedback button on the toolbar (or by email) and I'll be able help you.
This looks neat, but I don’t see anything off hand that will pull me away from my current git tower + kaleidoscope ~rut~ workflow.
In particular, the drag & drop rebase support in tower is very convenient. Kaleidoscope is capable of all kinds of diffing but the text conflict resolution is probably the feature that I use the most.
I used to use tower, but I switched to fork for two reasons - it was more performant with my work monorepo, and fork's a one time payment and tower's an annual subscription (and more expensive). I'm not affiliated with them at all but I'm a happy customer and recommend you give it a shot; they have a free trial.
I’m not the GP. I don’t like subscriptions and looked at Fork after your comment. I couldn’t find the policy on versions and upgrades. Is it a one time purchase with updates for major versions or for a period of time (after which updates wouldn’t be available) or a one time purchase forever (how would the developers and the product survive)? The purchase page says one license is for up to three computers. It doesn’t explain it there is some activation process (in which case there needs to be a way to deactivate and reassign).
Hi! I develop Fork with my wife. We don't have manager, marketing team, designers, etc. We also don't have meetings which makes us more efficient :). So, we don't need too much money to survive.
Answering your question, yes, it's a one-time purchase which includes future updates. We may release a major paid update in the future, however currently we don't have plans for that. The license is cross-platform. You can activate, deactivate and reassign the license.
Same reaction. My Tower subscription is up for renewal next month, so I'm primed to give this a try. A cursory look, however, and I find the user interface to be baffling. As one example, on loading the app presents a list of repositories to manage. Select one and you get to interact with that particular repo. But, as far as I can tell, there's no simple way to go back to the repository list to select a different repo to manage. At least, no way other than closing the app and relaunching it. Maybe I'm just used to the way Tower presents things and Fork is simply different, but I felt totally lost in the app, unsure of what to do or how to accomplish non-trivial tasks. With Tower, by contrast, all the interactions seem intuitive and straightforward. Looks like Tower will be getting my money in June as scheduled.
I merely cited this as one example of a confusing UI, but this response makes my point even stronger. For most applications, the normal user flow is from general (what the app calls Repository Manager, I guess) to specific (a particular repository). Well-designed user interfaces anticipate the typical user flow and give the user a chance to "go back." For example, a user may accidentally click on the wrong repository. That user likely wants to return the app to its previous state so as to make the correct choice.
Neither of these steps really does that. The first opens a command palette which does not have anything resembling a "go back" command. It does list "Recent Repositories," but there is no reason for a user to assume that "Recent" is the same as All the repositories listed on the first screen. The command palette also omits the folder hierarchy present on the first screen, and that hierarchy may be key to finding the desired repo. Opening a new tab is not at all intuitive for a user that wants to go back. And the most obvious result of the command is a new blank screen.
There a lots of things about Fork that look to be very well-done, and it appears to have a great feature set. But if I'm going to use a GUI instead of the command line for git, then I expect the app to be intuitive and easy to use. For me, Fork is not that. I appreciate that other users may have different opinions, and I do wish the developers great success with the project.
I'm a huge fan of Fork too! I love the speed and how Mac-native it feels. I'm comfortable with the git CLI but I still find Fork superior for many tasks, like deleting remote branches.
IntelliJ Community Edition is even free and open-source, so for Java coding it's perfect, but pretty good for Clojure, Python, PHP too.
The JetBrains IDEs are cross-platform, including Linux and cross architecture, including ARM, because the JVM/JDK is cross-arch.
The sticking point for me is how well it deals with the 3-way resolution of merge conflicts.
It also has a magic-wand icon, which seems to resolve 95% of conflicts automatically and correctly, presumably doing something based on common ancestor commits.
BUT what makes both this 3-way merge interface AND the commit interface really great, is the ability to edit in-place, with all your custom keybindings, syntax highlighting, linting and code intelligence tools!
You can auto-complete code, look up docs or the source code of function definitions, even in JAR files, without leaving the context of the commit dialog. If you need to do something more involved, like refactoring or jump to definition, u can always get to the source code with F4 from the commit dialog or from within any commit context.
You don't know what are you missing out on, until you experience it! It's a significant reduction in mental overhead, imho.
Now the cost of all this convenience is that you need to download hundreds of megabytes and IntelliJ CE has a substantial startup time and memory consumption, since it indexes your code. It also sprinkles your repo with projects files under a .idea folder.
I will check out Fork regardless, because it's good to know what's out there and what are the different set of tradeoffs it choose. Then I can choose and/or recommend it for different situations.
It's the same reason I'm learning vc.el and magit too. If you need to do some git surgery over high-latency SSH, then it's hard to beat Emacs with TRAMP...