I'm assuming the point was power tools versus very basic and more approachable ones, and I think there's a place for both. To use this example, I use vim most of the time but sometimes I jump into nano to do a quick edit on something.
I don't love most of the GUI tools for git, but I use Sourcetree for 10,000 ft visualization and can't really parse CLI git --log graphs, even if they're heavily decorated.
You're not wrong. Personally, I just used GitHub's web UI to preview my PRs, but I suppose having a local GUI makes it easier to amend commits and not have to force push changes.
It was mentioned elsewhere but you might find Sublime Merge to be useful; it's not based on Electron, it's very fast, and it makes working with various git workflows a lot nicer (to me, at least).
I've found piping the output of git diff to my editor makes it much easier to browse compared to using the UI. For instance, searching for a particular file or line of code it much easier in the editor compared to the browser.
I use Github Desktop. One thing I do like a lot is that the diff I see is exactly what my code reviewers will see.
Personally, I spend a lot of time reviewing other's code ad also going through my own PR's in Github. I'm very familiar with that view. I think it helps my brain that I use the same diff view when I'm working locally and when I'm reviewing code on Github.
Colors and fonts especially. After ten years my brain is fast at reading a GitHub diff. It’s pretty slow at reading a terminal diff because I don’t do it very much.
Presumably most people use an editor or IDE for coding and it's likely that editor or IDE could also be used to display diffs, so I don't really see colors or fonts being an issue. The IDE or editor could also be configured to use colors and fonts similar to what's used in Github. For example, vim has a colorscheme[1] that's similar to what Github offers.
GitHub desktop/mobile apps have been the worst thing to happen to GH since / along with the acquisition.
The website is being neglected, (especially on mobile) which is the primary value the service has for me. If I have `git` I really don't need GitHub except to view comments.
Ironically, notifications and comment management is still pretty bad.
Don't get me wrong, I still think GitHub is the best at what they do, but like many incumbents, I feel like they are losing a bit of what makes them so great.
Polish up the features you have, we don't need endless feature releases, we need smooth features we know and love.
As someone who has built GUI wrappers for perfectly working tools, it’s because support is a nightmare.
There’s a subset of your users who aren’t going to invest in learning your existing tools but you still want them to use your product.
You can’t write more documentation because the more documentation there is, the less people will read it. You can’t tell them to ask for support because they’ll just flood you and eventually give up.
So you build a GUI for these users and they’re happy and you’re happy. Your expert users won’t understand, will complain that you’re wasting your time, but that’s a price worth paying.
Using git on the command line can be hard to learn and unintuitive for people - the desktop client makes things easier and that's a good thing (kind of like how the GUI made computers accessible to more people and ended up benefiting everyone in software...)
TBH, I felt the same way for a while... but I found that I really only need to actually remember a handful of things.. git add, git commit, git pull --rebase, and the git rebase -i HEAD~N
Other than those, when I need something I don't typically use, I have google. And most of those instances where it's not one of the commands above, the UI is usually pretty bad anyway. I do like the preiew/diff in VS Code a lot though on the git tab.
I do wish there was a way to post-operate on the most recent commit (uncommit) via the gui though. I tend to work in a branch, regularly squashing and rebasing against upstream branch... then would prefer to be able to (via gui) uncommit the most recent commit, just so I can preview/edit a final pass at once. That is about the only workflow that I sometimes want/need that isn't really in the box, or otherwise more of a pain in the UI anyway.
I would use more non-GitHub solutions if they had GitHub Desktop or equivalent. The number of accidental commits I've seen by long term industry experts demonstrates that command line isn't always the best for all things. I generally avoid opening PRs on machines I don't have Desktop, which is why it's such an embarrassment GitHub has refused to publish an official Linux version, despite an employee maintaining one for years.
Completely disagree. The desktop app helps me greatly to create digestible commute and PRs. I use the command line for 99% of the actions I take but the desktop app gives me a much better visual of my changes and has helped me catch unintended (or temporary) changes many times.
On the website, the Notification Center has gotten better, linked methods is very helpful, code spaces are very cool (though I haven’t gone deep on them), repo redesign is great … IMHO, only gotten better.
I agree that I don’t need most of the new features but, in my experience working with it almost daily, the web experience has only gotten better for me in the last year or more.
In one comment, you say the webapp is abandoned. In another, you say it gets too many new features you don’t care about. If the latter is true, the former is definitely not true. That’s the main reason you’re getting some flack in this thread!
Sorry, let me be clear. Existing features feel abandoned and neglected. CSS styles are getting out of whack, margins and padding are way off in many places as they shoehorn in new features.
You can neglect something's foundation while strapping new bells and whistles on.
Let me be clear, Primer is a UI kit, not a feature, so if they're working on polishing the UI kit, which we can all see that they are, then they're doing what you're asking them to do. Again, fact over perception because the commits and activity are telling a completely different story.
I think github looks fairly nice/modern given it's age and I'm not having issues or feeling like anything is "abandoned". All I'm hearing is hyperbole.
"The website is being neglected"—really? Compared to their complete feature freeze pre-acquisition, new Github platform features come out regularly (WIP PRs, code owners, the entire Actions and Codespaces products, and Merge Queue being the most recent one). I've never used Github Desktop, but the idea that the website is being neglected just doesn't make any sense to me.
Not to mention more in-depth notification management, much better code search, and significantly improved code browsing! (Examples of polished features.) I have been pretty impressed at the pace of new features over the past two plus years.
Absolutely, what an excellent tool. One of those one-time purchases I almost wish was a subscription so I can be sure the team keeps working on it.
I actually understand git better because of Merge. It's great because it provides a great interface into git, but it doesn't _hide_ git from you; it explains it quite a well.
I suppose a newcomer to git might find Merge intimidating, but for anyone with a bit of experience I think it's quite an awesome power tool with a rare balance of handy abstraction and transparency around git itself.
Then the software isn't a subscription, the updates are. This is also kind of how the Jetbrains stuff works and it's far less user-hostile than making someone pay in perpetuity to simply use the software.
I can't imagine the Sublime Merge version I have today won't still be super useful once my license expires, so for a lot of people, buying a new copy might not seem particularly compelling. It's also so cheap (or it was when I bought it) that it's waaayyyyy less expensive than any 3 year subscription I've ever seen – something like $2/month.
People on my team use it. I guess it's fine, but when they get stuck with git (a-la locate git.txt and call the number listed on it), I am sort of at a loss of what they did to get where they are. At least with git commands you can sort of see how they got there.
If you get a lot of value out of the pull request view, you might enjoy adding partial committing to your workflow. Rather than committing entire directories or folders at a time, you can page chunk by chunk through uncommitted changes, committing only the ones you select. You'll easily spot those stray logging statements you don't want to commit. (You can also discard chunk at a time by using partial checkout/restore.) If you have, for example, two pairs of backend/frontend changes that you want to commit logically rather than simply according to their directory structure, partial committing is handy.
It's just `git commit -p` (and `git checkout -p`). It's not exactly a deep cut, but I encourage people who are familiar but don't use it to give it a try.
Interesting, I knew of `git add -p` (which I then use to `git commit -m ...`, but it looks like I could add all changes and _then_ decide what to commit. I think I'd still use `add -p` (I like being thorough), but I like that I can add all at once and then make partial commits based on specific change sets.
Thanks for pointing this out, I feel like git is the thing I should know best by now yet I'm missing so much of what it can do. It's great to see others' workflows.
I've tended to have a similar workflow... but since I use VS Code mostly, then I do use the git tab a lot for previewing changes before committing them. Other than that, I've mostly avoided using any GUI for git, mostly because I find it annoying. I'll say that the Github client and the VS Code integrations for Github have come a long way all the same for those that use and like them.
My favorite git workflow extension is `git commit --fixup SHA` combined with `git rebase -i --autosquash` to create targeted retroactive amendments. Kind of like `commit --amend that can target more than just the last commit.
You can commit line by line within Github Desktop and its a much nicer experience IMO than doing so via CLI. Its much easier to jump around to different files and commit related line changes in a bigger PR than jumping in and out of the patch command.
It's been a while since I've tolerated the git gui interface, but when I used to use it, the line-to-chunk logic would regularly fail on short 2-3 line spans.
There's a stackoverflow discussion [1] that suggests it was fixed in 2018, but for many years it was a terrible experience that pushed me to use other frontends just for reliable partial staging.
For those who want a GUI around this on Mac, https://rowanj.github.io/gitx/ is an incredible secret weapon. You can swipe over a bunch of lines or let the software identify a whole span of contiguous changed lines, click a button, and see just those changes move over from your unstaged to staged changes, then commit exactly what you want.
A lot of times people don't even understand how powerful the staging area is; they're just used to saying git add && git commit without realizing that it can be an incredible way to take a day of chaotic fixes and turn it into a set of commits you can be proud of!
It also provides an incredible tree view of commit parentage, perfect for when you need to instantly understand what happened with this weird merge/rebase that broke things, and to screenshare it to teach colleagues who might not have developed an internal understanding of the tree structure that Git is based on.
The software is now 9 years old and abandoned, but I've used this specific fork at least weekly - often daily - for every one of those years, across Intel and M1 Macs, and it's never let me down!
I assume it’s the fact that staging changes takes them out of your working tree. From there, a lot of git operations (diff, restore) will not include or modify the staged changes. This can help reason about logical chunks of code within a commit
I commit small chunks so often that I have a keyboard shortcut set up for that "stage selected range" command in VSCode, definitely recommend it to get a more useful commit history.
SourceTree has the same problems. I'm fond of just using the CLI but I'd like to be able to recommend a UI tool for other Devs. Haven't found one that works for Windows and WSL2 together.
71 comments
[ 4.6 ms ] story [ 126 ms ] threadI don't love most of the GUI tools for git, but I use Sourcetree for 10,000 ft visualization and can't really parse CLI git --log graphs, even if they're heavily decorated.
Much easier to read and browse than a terminal.
Personally, I spend a lot of time reviewing other's code ad also going through my own PR's in Github. I'm very familiar with that view. I think it helps my brain that I use the same diff view when I'm working locally and when I'm reviewing code on Github.
> One thing I do like a lot is that the diff I see is exactly what my code reviewers will see.
What will they see in the diff that you can see using Github Desktop that you wouldn't see by running git diff master?
[1] https://github.com/cormacrelf/vim-colors-github
The website is being neglected, (especially on mobile) which is the primary value the service has for me. If I have `git` I really don't need GitHub except to view comments.
Ironically, notifications and comment management is still pretty bad.
Don't get me wrong, I still think GitHub is the best at what they do, but like many incumbents, I feel like they are losing a bit of what makes them so great.
Polish up the features you have, we don't need endless feature releases, we need smooth features we know and love.
There’s a subset of your users who aren’t going to invest in learning your existing tools but you still want them to use your product.
You can’t write more documentation because the more documentation there is, the less people will read it. You can’t tell them to ask for support because they’ll just flood you and eventually give up.
So you build a GUI for these users and they’re happy and you’re happy. Your expert users won’t understand, will complain that you’re wasting your time, but that’s a price worth paying.
Using git on the command line can be hard to learn and unintuitive for people - the desktop client makes things easier and that's a good thing (kind of like how the GUI made computers accessible to more people and ended up benefiting everyone in software...)
Other than those, when I need something I don't typically use, I have google. And most of those instances where it's not one of the commands above, the UI is usually pretty bad anyway. I do like the preiew/diff in VS Code a lot though on the git tab.
I do wish there was a way to post-operate on the most recent commit (uncommit) via the gui though. I tend to work in a branch, regularly squashing and rebasing against upstream branch... then would prefer to be able to (via gui) uncommit the most recent commit, just so I can preview/edit a final pass at once. That is about the only workflow that I sometimes want/need that isn't really in the box, or otherwise more of a pain in the UI anyway.
Mind sharing where I can get this?
On the website, the Notification Center has gotten better, linked methods is very helpful, code spaces are very cool (though I haven’t gone deep on them), repo redesign is great … IMHO, only gotten better.
You can neglect something's foundation while strapping new bells and whistles on.
https://github.com/primer
I think github looks fairly nice/modern given it's age and I'm not having issues or feeling like anything is "abandoned". All I'm hearing is hyperbole.
I actually understand git better because of Merge. It's great because it provides a great interface into git, but it doesn't _hide_ git from you; it explains it quite a well.
I suppose a newcomer to git might find Merge intimidating, but for anyone with a bit of experience I think it's quite an awesome power tool with a rare balance of handy abstraction and transparency around git itself.
Just my 2c
Also git reflog?
It's just `git commit -p` (and `git checkout -p`). It's not exactly a deep cut, but I encourage people who are familiar but don't use it to give it a try.
Thanks for pointing this out, I feel like git is the thing I should know best by now yet I'm missing so much of what it can do. It's great to see others' workflows.
I wrote https://github.com/brasic/fixdown to make this easier to use.
There's a stackoverflow discussion [1] that suggests it was fixed in 2018, but for many years it was a terrible experience that pushed me to use other frontends just for reliable partial staging.
1: https://stackoverflow.com/questions/58133092/git-gui-error-f...
A lot of times people don't even understand how powerful the staging area is; they're just used to saying git add && git commit without realizing that it can be an incredible way to take a day of chaotic fixes and turn it into a set of commits you can be proud of!
It also provides an incredible tree view of commit parentage, perfect for when you need to instantly understand what happened with this weird merge/rebase that broke things, and to screenshare it to teach colleagues who might not have developed an internal understanding of the tree structure that Git is based on.
The software is now 9 years old and abandoned, but I've used this specific fork at least weekly - often daily - for every one of those years, across Intel and M1 Macs, and it's never let me down!
[0] https://github.com/rowanj/gitx/issues/481
In Fugitive, open it with :Git , select the unstaged file then press = . Select the desired range with visual mode, then press s and commit as normal.
In VS Code, select a hunk, press Ctrl+P, then type "Stage Selected Range." Repeat this process and commit as normal.
Edit: formatting and typo.
SourceTree has the same problems. I'm fond of just using the CLI but I'd like to be able to recommend a UI tool for other Devs. Haven't found one that works for Windows and WSL2 together.
might fit your needs