21 ms·

A lot of comments along the lines of ‘why do people use <ide> instead of learning the commands’. For me, I used to use the terminal git, and I still do occasio

A lot of comments along the lines of ‘why do people use <ide> instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use <ide> or not. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of arguments to merge. The guy who knows every command of git backwards is welcome to apply for a job managing a git repo or something if such a thing exists? But I could harp on the same way about his missing MATLAB or firmware skills.

benglish11 5y ago
For me I’ve used visual git tools in the past and it ends up doing something unintended/unexpected. So now I only use the terminal commands. Perhaps the old git tools I’ve used have improved significantly though.
- aetherspawn 5y ago
  I prefer to rebase on the terminal also, but I reference Sourcetree when doing it.
emsy 5y ago
I completely agree. It always baffles me how something so simple (yes, simple!) as version control can end up as the abomination that is git. After controlling for popularity, you don’t see nearly as much posts explaining subversion in detail, and subversion being centralized is neither the only nor the biggest reason for that.
- gallier2 5y ago
  No, version control is not simple, never was. git was the first vcs that didn't suck because it was the first tool that understood the nature of the problem. All others were ass backward and instead of solving the problem stood in the way and actively made things worse.
- mikeyjk 5y ago
  What VCS system is simpler? I've used mercurial, svn and git, and git seems the far easier of that sample space.
- baq 5y ago
  Wow, I’d never call version control simple. Actually it’s fiendishly hard. Git makes some simplifications (!) to make the problem more tractable.
- crooked-v 5y ago
  Git's basic problem is that it has a really a good model for the data, but a really terrible CLI.
oauea 5y ago
All visual git tools I've used suck and wound up eventually corrupting the repo. Also I've noticed that all of my colleagues who learned git using these visual tools didn't actually learn git, and have no idea how to anything other than add/commit/push. I say "just rebase your branch" and I can see the panic grow in their eyes.
- toxik 5y ago
  For these people, I think a manual backup is what they actually want. “If I fuck up so bad I have to roll back.” I don’t think it’s wrong necessarily either, and GitHub actually encourages this behavior with the easy Web file uploads. Many repositories are now 99% automatically created commits by drag and drop. I think these people would be better served by a backup system where you can pin snapshots. They don’t really want to use VCSs like they’re meant to be.
  - Nursie 5y ago
    How are version control systems meant to be used, if not as a history of the work? If not as a remote backup of work in progress? I get the whole “we should have a neat history of feature commits” argument, but that’s really only one facet of a good source control system. The fact that these goals appear to conflict shows me there’s some sort of lack in git. For all its (many, many) problems, uber-complex source control system ClearCase at least allowed you to specify a view, so you could see both types of information depending on your use-case.
    - jen20 5y ago
      They’re not really in conflict at all. The workflow I’ve been using for ~11 years is: - Make a branch for my work. - Commit early, often and with often meaningless commit messages like “WIP” or “try x” or “nope x doesn’t work, do y instead” - in other words, what the work was. - Push this branch to a remote (either personal or shared depending on policy) largely to synchronise between machines, but also as a backup. - When ready to integrate, interactively rebase into a set of cohesive units which are independently buildable and have detailed commit messages which explain why the work was done, not what the works was. - Push _this_ as a pull request, Gerrit change set, or email patch, depending on policy. This approach gives you the best of both worlds: fast, easy backup and easy unwind when doing work, and a clean history for the benefit of future developers on the project.
intellix 5y ago
I wouldn't say I'm an expert but I've got about 10 years experience using git via CLI and whenever a noob does something weird and he's using an IDE I'm like... Sorry I have zero idea what this is trying to do and cannot help you
- FunnyLookinHat 5y ago
  I've had similar experiences with git or other tools - not being able to help a junior dev because the GUI they're using is obfuscating whatever it is the underlying tool is trying to do. I think the irony is that we've got this insanely complex version control system that actually could have several valid use cases for what is likely a common path for users in a GUI. I'm also not sure referring to people as "noobs" is going to help you empathize with their difficulty. ;)
  - gavinray 5y ago
    Eh, that term seems to have fallen out of favor compared to when I was a growing up but I don't think it necessarily has a negative connotation. I remember being in programming and software related IRCs at 10-11 years old having no earthly clue what in the fuck I was doing, asking adults questions and getting called a "noob". Well, yeah, it was true. (I also made damn sure they had no idea I was a child.) They could have said "inexperienced person" but that's not got quite the same ring and people are lazy, aye? Haha
    - ketzu 5y ago
      My personal experience around noob is covered by the ones I found on ~~most~~ edit: the most high search-ranked online explanations: Mostly negatively conotated, deregatory version of newbie. Often associated with people not sufficiently able to learn or at least not learning on their own. Examples: * https://en.wiktionary.org/wiki/noob https://en.wiktionary.org/wiki/noob * https://www.etymonline.com/word/noob https://www.etymonline.com/word/noob Examples not containing the negative connotation: * https://www.merriam-webster.com/dictionary/noob https://www.merriam-webster.com/dictionary/noob * https://neologisms.rice.edu/index.php?a=term&d=1&t=2471 https://neologisms.rice.edu/index.php?a=term&d=1&t=2471 It might be something used quite differently by two similar groups, so it is good to be aware that other people may use it the other way.
tryingtogetback 5y ago
For me, as a dentist, I used to use the dental drill, but now I trust my janitor to handle it, this way I make less mistakes myself My job as a dentist isn't to use dental drill, it's to fix teeth in general. If I managed to fix a tooth and customer is happy, it doesn't matter whether I use drill myself or janitor does. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of drill bits you need for a root canal. The guy who knows dental drilling backwards is welcome to apply for a job managing dental drills or something if such a thing exists? But I could harp on the same way about his missing medical or braces-training skills.
- zarzavat 5y ago
  It's more like getting the dental assistant to operate the autoclave.
  - tryingtogetback 5y ago
    Endless opportunity for analogies here. The gist is that you are delegating all sensitive versioning and versioning history management operations to a 3rd party with extremely limited capabilities, 3rd party you know nothing about (effectively a black box). We thrive on abstractions, but unfortunately in case with versioning and git in particularly, GUI apps is a wrong one.
    - aniforprez 5y ago
      Your analogy is completely awful The janitor knows nothing about dentistry. The git GUI knows plenty about it and the devs make it their job to know it too. A janitor is not an abstraction, he's a liability. If a GUI abstraction helps me get the job done faster, I really don't see the problem. Plus almost every one of them fully state the commands being used to perform every action and have logs you can parse. I used to use Sublime Merge and now use Fork and both have this
      - tryingtogetback 5y ago
madeofpalk 5y ago
At the end, it comes down to a personal preference of what you're most comfortable with. Some will prefer to use GUIs, others will prefer the command line. Personally, I really enjoy using both the command line and the Github app. The Github app is super simple and straight forward, its great for just committing (parts of) files. Anything more than that and I prefer using the command line for "direct control".
akamoonknight 5y ago
I will agree that visually seeing the tree is such a useful tool to have access to. I know that's not the true desire of your use case, but in case it's useful, I will add what is obviously the best git alias, 'git lg': https://coderwall.com/p/euwpig/a-better-git-log https://coderwall.com/p/euwpig/a-better-git-log git lg --all is probably my most used command in terminals and I think it gives me a better view of how projects are flowing on the whole.
- res0nat0r 5y ago
  I exclusively use git via the cli because guis are too confusing for me to keep track of what is going on, I also like to use tig to browse the commit history like above.
- gallier2 5y ago
  and the ultimate option for git lg is --reflog. Seeing all branches, even the old ones that do not exist anymore is a eye opening event in discovering the true nature of git: it never changes a commit, ever.
  - azundo 5y ago
    While reflog is amazing, the "ever" in your statement is not true, `git gc` will prune your reflog: https://git-scm.com/docs/git-gc https://git-scm.com/docs/git-gc Most of the time this doesn't matter in practice but you should be aware that unreachable refs don't stay around forever.
- jamesmontalvo3 5y ago
  If I need to visualize the network of commits I use this alias in .gitconfig: network = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all
  - jbverschoor 5y ago
    I'd rather use a "visual tool" to visualize
snarfy 5y ago
We are all using git only because Linus wrote it. The cargo cult is real and very much alive in our industry, I think precisely because we are all here to write specialist software. Too busy in our domain to worry about version control nuances so we just go with what is popular and don't think about it too much. It's not just version control, it's libraries, frameworks, languages, all of it. If it's not popular it's doomed to failure.
- cerved 5y ago
  we use it because it's blazing fast, stable and extremely versatile
  - mberning 5y ago
    It’s not very fast when you account for all the time and productivity wasted on getting “unstuck” all the time.
    - cerved 5y ago
      I devoted some time to RTFM and actually learning how things work so I can't say that I run into this issue
    - reidjs 5y ago
      Once you get over the initial learning curve you will not get stuck very often
  - jen20 5y ago
    I’d add another reason to that: we’re using Git because BitKeeper wasn’t free (as in beer) at the time for general purpose use. Had it been, we’d all be using BitKeeper instead.
    - schlupa 5y ago
      Probably not. The free (as in speech) part of git is what made it usable for entities like google, Microsoft, github etc. If git had been released with the same license model of BitKeepr it NEVER would have taken off.
emodendroket 5y ago
I find the visual ones often harder to use but that's just me. Whatever works works.
mberning 5y ago
Absolutely. I can’t wait until something with better ux comes along and gets enough traction to make git a distant memory. I do not want to know the detailed inner workings of my VCS data model or 100 incongruent commands to make it work.
crazygringo 5y ago
Seriously, seeing the commit tree laid out with colored lines is essential to me. A glance at the interface lets me know exactly what state the repository is in. Just like you say, it's less mistakes. Which is precisely one of the benefits of good UX. Going from SourceTree back to the command line would be a huge step backwards for me. I still use the command line sometimes because there's advanced stuff SourceTree can't do. But for most of my basic everyday operations, the command line is just inviting me to make little accidental mistakes every so often because the state of the repository and branches isn't obvious at a glance. I only see upside to using an IDE, zero downside. (I've never had SourceTree "corrupt" my repository, and all its commands do exactly what I expect -- it's just running the git commands I'd be typing out anyways.)
- dvlsg 5y ago
  Yeah, viewing a changeset and staging only some files or just parts of files is really important to my workflow. Sometimes I leave myself comments or skip tests locally and I have no intention of committing those changes. Using a tool like sourcetree to review, add, and commit only the lines I want is very helpful and saves me time. I do use the command line for everything else, though. Well except interactive rebasing, I suppose. I pop back in to vscode for that. But even that gets started in the terminal.
  - einherjae 5y ago
    I’m in the same camp, often staging is easier to handle with a GUI, particularly if you want a partial staging. But then again, there is always git add -p
  - themulticaster 5y ago
    Just in case you didn't know, there is git add -p (or --patch) which does precisely what you want: It splits your changes into small parts ("hunks") and allows you to specify whether to stage every hunk. I don't know your exact workflow in Sourcetree, but most likely git add -p is the CLI equivalent of the Sourcetree interaction you describe. Bonus commands: -p/--patch also works for git stash (allowing you to stash only certain changes) and for git checkout (allowing you to discard only certain changes). Since I'm an Old School Git user I actually don't really know the restore/switch commands, but apparently git restore supports -p/--patch as well. Another neat git add flag is -u/--update: The manpage is a little confusing on this flag, but essentially it makes git add ignore untracked files (it will only stage files that are already part of the repository). If you're like me, you have tons of files laying around in the project folder (e.g. benchmark results or local test input files) that you don't want to commit and yet don't want to add to the .gitignore file (since the files are really just temporary files, other users have no use for the gitignore entries). By using git add -u, you prevent adding them by mistake in a command like git add src/ and realizing a few weeks later that you accidentally added 10 MB of cat pictures to a bugfix commit. If you can identify with this story then git add -u is made for you. Another bonus fact: If the temporary testing files mentioned in the last paragraph ever reach the status of permanent testing files, and they're still only useful to you personally (so adding them to gitignore doesn't make sense), Git has a little-known feature: You can add local ignore patterns (same syntax as gitignore) to .git/info/exclude (go ahead and check, this file most likely already exists in your Git repository). These patterns are not be part of the repository itself (you don't commit them), rather they act as local configuration. The idea is that you put exclude patterns that are valid for every user of the project (e.g. target/ for a Rust project) in .gitignore, and local exclude patterns for your IDE/editor configuration (.vscode/, .idea/ and friends) and similar files in .git/info/exclude. In conclusion, I only every run a) git add -u $file (when I want to add all changes made to an existing file), b) git add -p $file (when I want to add only certain changes made to an existing file), or c) git add $new_file (when I consciously want to add a previously untracked file). These three commands are all you need if you're in the camp of Git users that at least try to make every commit a good package (single, reasonably-scoped and atomic change). If you're in the git commit -a/"squash all intermediate commits into one single monstrous commit" camp then.. have fun with your cat pictures, I guess. I hope that was at least a little bit helpful to someone. May I ask why you drop into VS Code for interactive rebasing? Is it about resolving the merge conflicts, or editing the rebase command list? I'm just going to drop two more nice Git features here, but I'll stop myself now before I write too much: git commit --fixup= together with git rebase --autosquash, and git rerere (not a typo).
Shorel 5y ago
A couple of easily added aliases to .gitconfig and my CLI can do everything your GUI can do, in a portable way, and much easier and faster IMO. Nothing to learn or even forget, either, as the CLI is actually the easier part of the job. So, you do you, nothing wrong with that, but the CLI is here to stay.
magoon 5y ago
Commands are explicit and shareable. If you’ve mastered <ide> then good on you, but it makes you an island.
PaulDavisThe1st 5y ago
> My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use <ide> or not. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of arguments to merge. Imagine if you knew a cabinet builder who said: "My job isn't to use a table saw, it's to build beautiful cabinets. If I get the cabinets built and the customer is happy, it doesn't matter whether I use a japanese handsaw or a CNC controlled laser. Imagine having 100 different pieces bouncing around around in your and having to then remember the assembly order." Now, you might argue that this supports your point, by claiming that it actually doesn't matter whether the carpenter uses a japanese handsaw, table saw or CNC laser cutter. But I'd argue the opposite: it does matter whether the carpenter knows the tools they use as well as possible, because this will affect both the quality & speed of their work, but also the range of possibilities they can even consider. It doesn't matter much which tool they use, as long as they know it intimately and in depth. I would argue that the same is true of the tools we use as software developers. Pretending that all of the skill lies only in the domain of creating actual lines of code is misleading. If you're using a revision control system, you owe it to yourself, your customers and your colleagues (if any) to be a master of that in the same way that you're a master of the specialist software you're creating.
- wizzwizz4 5y ago
  Version control isn't a tool I use. It's the filesystem I store my files in.
  - foepys 5y ago
    This is only true until the first merge conflict or when you want to know when a bug was introduced to even find its location.
    - alisonkisk 5y ago
      I resolve conflicts in GUI every week. I find the location of a bug by running tests and looking at the code.
0xEFF 5y ago
I recently tried to help someone onboard into a cloud project that requires git tunneling due to security policies. While they had experience with their IDE of choice and git, they were ultimately unable to push any changes.
nerfbatplz 5y ago
Except for 99% of all git day to day tasks are done with like 7 commands. Git commit Git checkout Git merge Git pull Git push Git rebase Git stash I can’t remember I needed a command that wasn’t one of those and I exclusively use the cli.
- paulddraper 5y ago
  I've used git for over a decade, and I can't think of anything new I've learned in the past 4 years. And that last new thing was when git added worktree, which I don't actually use, but I learned about. Contrast that with almost any other program....it's impressive.
- adwww 5y ago
  I seem to use cherry-pick at least monthly, as well as log and diff.
  - mschout 5y ago
    I was gonna say cherry-pick is farily frequent for me. Also I seem to learn new variations once in a blue moon for common commands. E.g. recently I learned about the --cherry option for git-log and it changed my life.
- djmips 5y ago
  It's funny but I forgot that Git restore was a new command, it only came in 2019 but I use it all the time.
gumby 5y ago
I don’t completely agree. > My job isn’t to use git, it’s to write specialist software. I’m a big fan of automation, but there are certain fundamental tools I think one needs to understand to do the job. Both because you should have some idea what the automation is there to accomplish and also to get yourself out of a pickle when something goes wrong (or to even recognize when that happens!). So, as I think most people would agree: you certainly don’t need to understand the obscure corners of your programming language, but you should have a solid understanding of the fundamentals and a decent overview of the rest. In the case of source control, and git in particular, IMHO you should have a decent fundamental understanding (which isn’t even particularly complex at a conceptual level) so even if you don’t remember the command for ‘X’ , you’ll know to look for it when you do need it. Given how you started your comment, perhaps you don’t even agree with implication of the sentence I quoted. (edit: added IMHO)
- GeorgeTirebiter 5y ago
  How should one go about achieving a 'decent fundamental understanding' (specific pointers, if you have them). And, how much time must one devote to being a 'good enough git guru'? (and, it surprises me that gitless is not more popular: https://gitless.com/ https://gitless.com/ )
- stormbrew 5y ago
  I'd go even farther than not completely agreeing with that and just say that I completely disagree. Our job as programmers is not just to write a bunch of code in a vacuum, it is to create that code and communicate it to the machines and people who will be consuming and manipulating it. Things like version control should be first class tools that we all learn in detail. They are literally the most fundamentally important tools we use every day if we work in a team. You aren't doing your job if you don't care about how your code interacts with your team and your deployment. Like an architect who doesn't know how to use a drafting table. It's incredibly frustrating that people let their egos stoke them into this idea that tooling is beneath them. It's almost certainly the cause of an incredible amount of bad software, even though much of its code is, I'm sure, quite clever in a vacuum. And I'd rather work with a hundred programmers who know how to use their tools than one programmer who looks down on them for it.
jupp0r 5y ago
Having been through two Perforce -> git transitions of medium sized repos with a few dozen people contributing and being the person with the most git knowledge in the group to be called in when people new to git mess things up: these GUI git clients are ok if you know what you are doing and what the consequences of checking various checkboxes are. They are not conducive to people learning how the tool git works and how to use it to solve real world problems. The command line is a great way to learn git and then fundamental understanding can be used to reverse engineer what GUIs do under the hood.
bob1029 5y ago
> My job isn’t to use git, it’s to write specialist software. This is true on so many other levels too. My job isn't to be an AWS expert, VIM master, Visual Studio ninja, Unix professor, et. al. My job is to make the customer happy. That is it. If the customer is happy, my project managers are happy, the executives are happy, the investors are happy. When all of your bosses are happy, you can get away with absolute murder. No one gives you shit about anything. Production went down because you fucked up? No big deal - that was like the first time in 18 months we had any problems, and the customer can't even see these things through all the magical features get to play with day-to-day. Need to take the entire afternoon to play overwatch because [arbitrary fuck you reason abc]? No one cares as long as you didn't have a scheduled meeting. In this realm, your mind is free to explore side projects without fear of reproach or guilt-trip. Tasks are executed with confidence and calm. Innovations are more frequent and valuable. People are actually relaxing in their time off and enjoy working for their employer. When the customer is pissed off, it is like entering into Doom Eternal as a non-player character. At every turn you begin to anticipate a heated conversation about missed target XYZ and incident ABC. Each ding of your outlook bumps your blood pressure by 20-30% before you even see the subject line. Your executives start taking damage from your customer's executives. Investors begin executing difficult queries regarding long-term viability. NO one is sleeping anymore. Side projects? Are you fucking kidding me? Not in this hell. So, when someone in my organization starts giving me the run-around about [pedantic greybeard doctrine which adds 10x overhead to a process], and also has no business value to show for said run-around, I begin to shut things down pretty quickly. If you want to play nuclear release authorization simulator every time you need to check in source code, please do this on your own time. Even the most elite hacker rockstars like to use GUI tools so they can see what the fuck is going on without making their eyes bleed every 10-15 minutes due to terminal character display restrictions.
agilob 5y ago
I expect other programmers to learn and master tools they use 50 times per day. You should be getting more efficient, productive and make fewer mistakes with languages, frameworks and tools you use daily. If you prefer sourcetree, be it, but I expect you to use it efficiently and not make mistakes other people wouldn't do with git, zsh and ohmyzsh (which contains like 100s of handy shortcuts).
u801e 5y ago
> My job isn’t to use git, it’s to write specialist software. Part of the job is to know and understand the tools that you need to use to in order perform the duties as part of that job. Saying that it isn't your job to use git is like a surgeon saying it's not their job to learn how to tie sutures when closing up the surgical site after completing the operation.
alerighi 5y ago
You don't even need git at that point. I don't understand why using git if you want a GUI... at this point, put the source code on the company fileserver and adopt "zip versioning", i.e. when you do a new release create an archive named "project-X.Y.z.zip" and archive it on the fileserver. If you need to work on another branch copy the source code directory. Why bother at this point? I don't understand people that wants to use git but they want do to so with a GUI that abstract everything that git was created to address, and they limit themself to write some code, commit and push. You are not gaining any benefit in using git this way, you are only wasting time to me. If you choose to adopt git, you learn how to use it, and so you learn the commands (it's not that much effort). In my experience GUI always created problems, especially if someone in a team uses a GUI that creates junk in the repository (like 100 useless merge commits created automatically for things that shouldn't really have been a merge that make git log unreadable...). Also people that uses GUI typically when they have a problem that the GUI doesn't know how to solve (because they typically implement the basic things and if something goes wrong they can't help you) just deletes the whole repo and clones it again, or worse they try to fix it by pressing random buttons in the GUI and put the repo in a shitty state so another coworker that knows how to use git has to waste his time cleaning up the crap that the fantastic git GUI made. And I'm not saying that you shouldn't 100% use GUIs. I use the one of VSCode for doing simple things like creating commits, switching branches, and stuff like that. For advanced features like merge, cherry pick, rebase, whatever I use the CLI, I find it more practical.
MisterBastahrd 5y ago
Wonder how many command line enthusiasts are using gitflow to make things even simpler than sourcetree.
neop1x 5y ago
>> My job isn’t to use git, it’s to write specialist software. It's like a plumber complaining that his job isn't driving with a car and that he wants customers to pick him up or wait for him until he comes on foot or via public transport.
- jonahx 5y ago
  A fairer analogy is that GP is saying, "I don't want to use a van to bring my stuff, but prefer a pickup truck." From the customer's POV, it makes no difference.
mattrighetti 5y ago
Using git from cli is like driving a Ferrari in a road with 30km/h speed limit
smusamashah 5y ago
If you understand how git works, its data structure essentially, then its far easier to do anything with IDE/GUI instead of CLI. They are more intuitive and shorten the work and less prone to mistakes.
OJFord 5y ago
> [I don't use git CLI so much any more] because I make less mistakes seeing the tree visually all the time. I look at the tree visually so frequently it must be my most common command. In the CLI. log --graph --decorate --pretty=oneline --abbrev-commit And then optionally adding whatever else, `--all` most frequently. (Obviously not writing it all out every time - with git config aliases, and actually `gitl` as a shell alias for that even. That's probably up there in my top.. 5? shell commands.) GUIs work too of course. Just pointing out you don't have to abandon the CLI for a tree. There's fancier third-party tools than native git log that are still CLI even.
Arch-TK 5y ago
So putting aside your argument that I completely disagree with but a lot of people have already voiced my concerns. > The guy who knows every command of git backwards is welcome to apply for a job managing a git repo or something if such a thing exists? Yes, this is the job of a maintainer in fact. They exist in a variety of organisations but maybe not enough. The best example is the linux kernel. Developers are expected to maintain their own local tree. When it comes to contributing code to the kernel, the patches are sent in a standardised manner to a mailing list and a maintainer then handles dealing with branches, rebases and merges. This means that developers don't need to know any more git than they really want to learn, aside from how to use git-format-patch and git-send-email which are really quite simple tools with an incredibly vast number of tutorials out there explaining them. This means that people who insist that it's "not their job" to learn git can achieve the requirements of "patches which build at every step and contain isolated step by step changes" using a GUI or doing something really stupid like copying the code aside, deleting and re-cloning the repository and then pasting and committing each step. It also means that people who actually know how to use git can get the job done in a fraction of the time. It also means that a carpenter^Wdeveloper's insistence to not learn how to use a claw hammer^W^W^Wgit will not affect their fellow coworkers/cocontributors.

benglish11 5y ago

For me I’ve used visual git tools in the past and it ends up doing something unintended/unexpected. So now I only use the terminal commands. Perhaps the old git tools I’ve used have improved significantly though.

aetherspawn 5y ago
I prefer to rebase on the terminal also, but I reference Sourcetree when doing it.

emsy 5y ago

I completely agree. It always baffles me how something so simple (yes, simple!) as version control can end up as the abomination that is git. After controlling for popularity, you don’t see nearly as much posts explaining subversion in detail, and subversion being centralized is neither the only nor the biggest reason for that.

gallier2 5y ago
No, version control is not simple, never was. git was the first vcs that didn't suck because it was the first tool that understood the nature of the problem. All others were ass backward and instead of solving the problem stood in the way and actively made things worse.
mikeyjk 5y ago
What VCS system is simpler? I've used mercurial, svn and git, and git seems the far easier of that sample space.
baq 5y ago
Wow, I’d never call version control simple. Actually it’s fiendishly hard. Git makes some simplifications (!) to make the problem more tractable.
crooked-v 5y ago
Git's basic problem is that it has a really a good model for the data, but a really terrible CLI.

oauea 5y ago

All visual git tools I've used suck and wound up eventually corrupting the repo. Also I've noticed that all of my colleagues who learned git using these visual tools didn't actually learn git, and have no idea how to anything other than add/commit/push. I say "just rebase your branch" and I can see the panic grow in their eyes.

toxik 5y ago
For these people, I think a manual backup is what they actually want. “If I fuck up so bad I have to roll back.” I don’t think it’s wrong necessarily either, and GitHub actually encourages this behavior with the easy Web file uploads. Many repositories are now 99% automatically created commits by drag and drop. I think these people would be better served by a backup system where you can pin snapshots. They don’t really want to use VCSs like they’re meant to be.
- Nursie 5y ago
  How are version control systems meant to be used, if not as a history of the work? If not as a remote backup of work in progress? I get the whole “we should have a neat history of feature commits” argument, but that’s really only one facet of a good source control system. The fact that these goals appear to conflict shows me there’s some sort of lack in git. For all its (many, many) problems, uber-complex source control system ClearCase at least allowed you to specify a view, so you could see both types of information depending on your use-case.
  - jen20 5y ago
    They’re not really in conflict at all. The workflow I’ve been using for ~11 years is: - Make a branch for my work. - Commit early, often and with often meaningless commit messages like “WIP” or “try x” or “nope x doesn’t work, do y instead” - in other words, what the work was. - Push this branch to a remote (either personal or shared depending on policy) largely to synchronise between machines, but also as a backup. - When ready to integrate, interactively rebase into a set of cohesive units which are independently buildable and have detailed commit messages which explain why the work was done, not what the works was. - Push _this_ as a pull request, Gerrit change set, or email patch, depending on policy. This approach gives you the best of both worlds: fast, easy backup and easy unwind when doing work, and a clean history for the benefit of future developers on the project.

intellix 5y ago

I wouldn't say I'm an expert but I've got about 10 years experience using git via CLI and whenever a noob does something weird and he's using an IDE I'm like... Sorry I have zero idea what this is trying to do and cannot help you

FunnyLookinHat 5y ago
I've had similar experiences with git or other tools - not being able to help a junior dev because the GUI they're using is obfuscating whatever it is the underlying tool is trying to do. I think the irony is that we've got this insanely complex version control system that actually could have several valid use cases for what is likely a common path for users in a GUI. I'm also not sure referring to people as "noobs" is going to help you empathize with their difficulty. ;)
- gavinray 5y ago
  Eh, that term seems to have fallen out of favor compared to when I was a growing up but I don't think it necessarily has a negative connotation. I remember being in programming and software related IRCs at 10-11 years old having no earthly clue what in the fuck I was doing, asking adults questions and getting called a "noob". Well, yeah, it was true. (I also made damn sure they had no idea I was a child.) They could have said "inexperienced person" but that's not got quite the same ring and people are lazy, aye? Haha
  - ketzu 5y ago
    My personal experience around noob is covered by the ones I found on ~~most~~ edit: the most high search-ranked online explanations: Mostly negatively conotated, deregatory version of newbie. Often associated with people not sufficiently able to learn or at least not learning on their own. Examples: * https://en.wiktionary.org/wiki/noob https://en.wiktionary.org/wiki/noob * https://www.etymonline.com/word/noob https://www.etymonline.com/word/noob Examples not containing the negative connotation: * https://www.merriam-webster.com/dictionary/noob https://www.merriam-webster.com/dictionary/noob * https://neologisms.rice.edu/index.php?a=term&d=1&t=2471 https://neologisms.rice.edu/index.php?a=term&d=1&t=2471 It might be something used quite differently by two similar groups, so it is good to be aware that other people may use it the other way.

tryingtogetback 5y ago

For me, as a dentist, I used to use the dental drill, but now I trust my janitor to handle it, this way I make less mistakes myself My job as a dentist isn't to use dental drill, it's to fix teeth in general. If I managed to fix a tooth and customer is happy, it doesn't matter whether I use drill myself or janitor does. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of drill bits you need for a root canal. The guy who knows dental drilling backwards is welcome to apply for a job managing dental drills or something if such a thing exists? But I could harp on the same way about his missing medical or braces-training skills.

zarzavat 5y ago
It's more like getting the dental assistant to operate the autoclave.
- tryingtogetback 5y ago
  Endless opportunity for analogies here. The gist is that you are delegating all sensitive versioning and versioning history management operations to a 3rd party with extremely limited capabilities, 3rd party you know nothing about (effectively a black box). We thrive on abstractions, but unfortunately in case with versioning and git in particularly, GUI apps is a wrong one.
  - aniforprez 5y ago
    Your analogy is completely awful The janitor knows nothing about dentistry. The git GUI knows plenty about it and the devs make it their job to know it too. A janitor is not an abstraction, he's a liability. If a GUI abstraction helps me get the job done faster, I really don't see the problem. Plus almost every one of them fully state the commands being used to perform every action and have logs you can parse. I used to use Sublime Merge and now use Fork and both have this
    - tryingtogetback 5y ago

madeofpalk 5y ago

At the end, it comes down to a personal preference of what you're most comfortable with. Some will prefer to use GUIs, others will prefer the command line. Personally, I really enjoy using both the command line and the Github app. The Github app is super simple and straight forward, its great for just committing (parts of) files. Anything more than that and I prefer using the command line for "direct control".

akamoonknight 5y ago

I will agree that visually seeing the tree is such a useful tool to have access to. I know that's not the true desire of your use case, but in case it's useful, I will add what is obviously the best git alias, 'git lg': https://coderwall.com/p/euwpig/a-better-git-log https://coderwall.com/p/euwpig/a-better-git-log git lg --all is probably my most used command in terminals and I think it gives me a better view of how projects are flowing on the whole.

res0nat0r 5y ago
I exclusively use git via the cli because guis are too confusing for me to keep track of what is going on, I also like to use tig to browse the commit history like above.
gallier2 5y ago
and the ultimate option for git lg is --reflog. Seeing all branches, even the old ones that do not exist anymore is a eye opening event in discovering the true nature of git: it never changes a commit, ever.
- azundo 5y ago
  While reflog is amazing, the "ever" in your statement is not true, `git gc` will prune your reflog: https://git-scm.com/docs/git-gc https://git-scm.com/docs/git-gc Most of the time this doesn't matter in practice but you should be aware that unreachable refs don't stay around forever.
jamesmontalvo3 5y ago
If I need to visualize the network of commits I use this alias in .gitconfig: network = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all
- jbverschoor 5y ago
  I'd rather use a "visual tool" to visualize

snarfy 5y ago

We are all using git only because Linus wrote it. The cargo cult is real and very much alive in our industry, I think precisely because we are all here to write specialist software. Too busy in our domain to worry about version control nuances so we just go with what is popular and don't think about it too much. It's not just version control, it's libraries, frameworks, languages, all of it. If it's not popular it's doomed to failure.

cerved 5y ago
we use it because it's blazing fast, stable and extremely versatile
- mberning 5y ago
  It’s not very fast when you account for all the time and productivity wasted on getting “unstuck” all the time.
  - cerved 5y ago
    I devoted some time to RTFM and actually learning how things work so I can't say that I run into this issue
  - reidjs 5y ago
    Once you get over the initial learning curve you will not get stuck very often
- jen20 5y ago
  I’d add another reason to that: we’re using Git because BitKeeper wasn’t free (as in beer) at the time for general purpose use. Had it been, we’d all be using BitKeeper instead.
  - schlupa 5y ago
    Probably not. The free (as in speech) part of git is what made it usable for entities like google, Microsoft, github etc. If git had been released with the same license model of BitKeepr it NEVER would have taken off.

emodendroket 5y ago

I find the visual ones often harder to use but that's just me. Whatever works works.

mberning 5y ago

Absolutely. I can’t wait until something with better ux comes along and gets enough traction to make git a distant memory. I do not want to know the detailed inner workings of my VCS data model or 100 incongruent commands to make it work.

crazygringo 5y ago

Seriously, seeing the commit tree laid out with colored lines is essential to me. A glance at the interface lets me know exactly what state the repository is in. Just like you say, it's less mistakes. Which is precisely one of the benefits of good UX. Going from SourceTree back to the command line would be a huge step backwards for me. I still use the command line sometimes because there's advanced stuff SourceTree can't do. But for most of my basic everyday operations, the command line is just inviting me to make little accidental mistakes every so often because the state of the repository and branches isn't obvious at a glance. I only see upside to using an IDE, zero downside. (I've never had SourceTree "corrupt" my repository, and all its commands do exactly what I expect -- it's just running the git commands I'd be typing out anyways.)

dvlsg 5y ago
Yeah, viewing a changeset and staging only some files or just parts of files is really important to my workflow. Sometimes I leave myself comments or skip tests locally and I have no intention of committing those changes. Using a tool like sourcetree to review, add, and commit only the lines I want is very helpful and saves me time. I do use the command line for everything else, though. Well except interactive rebasing, I suppose. I pop back in to vscode for that. But even that gets started in the terminal.
- einherjae 5y ago
  I’m in the same camp, often staging is easier to handle with a GUI, particularly if you want a partial staging. But then again, there is always git add -p
- themulticaster 5y ago
  Just in case you didn't know, there is git add -p (or --patch) which does precisely what you want: It splits your changes into small parts ("hunks") and allows you to specify whether to stage every hunk. I don't know your exact workflow in Sourcetree, but most likely git add -p is the CLI equivalent of the Sourcetree interaction you describe. Bonus commands: -p/--patch also works for git stash (allowing you to stash only certain changes) and for git checkout (allowing you to discard only certain changes). Since I'm an Old School Git user I actually don't really know the restore/switch commands, but apparently git restore supports -p/--patch as well. Another neat git add flag is -u/--update: The manpage is a little confusing on this flag, but essentially it makes git add ignore untracked files (it will only stage files that are already part of the repository). If you're like me, you have tons of files laying around in the project folder (e.g. benchmark results or local test input files) that you don't want to commit and yet don't want to add to the .gitignore file (since the files are really just temporary files, other users have no use for the gitignore entries). By using git add -u, you prevent adding them by mistake in a command like git add src/ and realizing a few weeks later that you accidentally added 10 MB of cat pictures to a bugfix commit. If you can identify with this story then git add -u is made for you. Another bonus fact: If the temporary testing files mentioned in the last paragraph ever reach the status of permanent testing files, and they're still only useful to you personally (so adding them to gitignore doesn't make sense), Git has a little-known feature: You can add local ignore patterns (same syntax as gitignore) to .git/info/exclude (go ahead and check, this file most likely already exists in your Git repository). These patterns are not be part of the repository itself (you don't commit them), rather they act as local configuration. The idea is that you put exclude patterns that are valid for every user of the project (e.g. target/ for a Rust project) in .gitignore, and local exclude patterns for your IDE/editor configuration (.vscode/, .idea/ and friends) and similar files in .git/info/exclude. In conclusion, I only every run a) git add -u $file (when I want to add all changes made to an existing file), b) git add -p $file (when I want to add only certain changes made to an existing file), or c) git add $new_file (when I consciously want to add a previously untracked file). These three commands are all you need if you're in the camp of Git users that at least try to make every commit a good package (single, reasonably-scoped and atomic change). If you're in the git commit -a/"squash all intermediate commits into one single monstrous commit" camp then.. have fun with your cat pictures, I guess. I hope that was at least a little bit helpful to someone. May I ask why you drop into VS Code for interactive rebasing? Is it about resolving the merge conflicts, or editing the rebase command list? I'm just going to drop two more nice Git features here, but I'll stop myself now before I write too much: git commit --fixup= together with git rebase --autosquash, and git rerere (not a typo).

Shorel 5y ago

A couple of easily added aliases to .gitconfig and my CLI can do everything your GUI can do, in a portable way, and much easier and faster IMO. Nothing to learn or even forget, either, as the CLI is actually the easier part of the job. So, you do you, nothing wrong with that, but the CLI is here to stay.

magoon 5y ago

Commands are explicit and shareable. If you’ve mastered <ide> then good on you, but it makes you an island.

PaulDavisThe1st 5y ago

> My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use <ide> or not. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of arguments to merge. Imagine if you knew a cabinet builder who said: "My job isn't to use a table saw, it's to build beautiful cabinets. If I get the cabinets built and the customer is happy, it doesn't matter whether I use a japanese handsaw or a CNC controlled laser. Imagine having 100 different pieces bouncing around around in your and having to then remember the assembly order." Now, you might argue that this supports your point, by claiming that it actually doesn't matter whether the carpenter uses a japanese handsaw, table saw or CNC laser cutter. But I'd argue the opposite: it does matter whether the carpenter knows the tools they use as well as possible, because this will affect both the quality & speed of their work, but also the range of possibilities they can even consider. It doesn't matter much which tool they use, as long as they know it intimately and in depth. I would argue that the same is true of the tools we use as software developers. Pretending that all of the skill lies only in the domain of creating actual lines of code is misleading. If you're using a revision control system, you owe it to yourself, your customers and your colleagues (if any) to be a master of that in the same way that you're a master of the specialist software you're creating.

wizzwizz4 5y ago
Version control isn't a tool I use. It's the filesystem I store my files in.
- foepys 5y ago
  This is only true until the first merge conflict or when you want to know when a bug was introduced to even find its location.
  - alisonkisk 5y ago
    I resolve conflicts in GUI every week. I find the location of a bug by running tests and looking at the code.

0xEFF 5y ago

I recently tried to help someone onboard into a cloud project that requires git tunneling due to security policies. While they had experience with their IDE of choice and git, they were ultimately unable to push any changes.

nerfbatplz 5y ago

Except for 99% of all git day to day tasks are done with like 7 commands. Git commit Git checkout Git merge Git pull Git push Git rebase Git stash I can’t remember I needed a command that wasn’t one of those and I exclusively use the cli.

paulddraper 5y ago
I've used git for over a decade, and I can't think of anything new I've learned in the past 4 years. And that last new thing was when git added worktree, which I don't actually use, but I learned about. Contrast that with almost any other program....it's impressive.
adwww 5y ago
I seem to use cherry-pick at least monthly, as well as log and diff.
- mschout 5y ago
  I was gonna say cherry-pick is farily frequent for me. Also I seem to learn new variations once in a blue moon for common commands. E.g. recently I learned about the --cherry option for git-log and it changed my life.
djmips 5y ago
It's funny but I forgot that Git restore was a new command, it only came in 2019 but I use it all the time.

gumby 5y ago

I don’t completely agree. > My job isn’t to use git, it’s to write specialist software. I’m a big fan of automation, but there are certain fundamental tools I think one needs to understand to do the job. Both because you should have some idea what the automation is there to accomplish and also to get yourself out of a pickle when something goes wrong (or to even recognize when that happens!). So, as I think most people would agree: you certainly don’t need to understand the obscure corners of your programming language, but you should have a solid understanding of the fundamentals and a decent overview of the rest. In the case of source control, and git in particular, IMHO you should have a decent fundamental understanding (which isn’t even particularly complex at a conceptual level) so even if you don’t remember the command for ‘X’ , you’ll know to look for it when you do need it. Given how you started your comment, perhaps you don’t even agree with implication of the sentence I quoted. (edit: added IMHO)

GeorgeTirebiter 5y ago
How should one go about achieving a 'decent fundamental understanding' (specific pointers, if you have them). And, how much time must one devote to being a 'good enough git guru'? (and, it surprises me that gitless is not more popular: https://gitless.com/ https://gitless.com/ )
stormbrew 5y ago
I'd go even farther than not completely agreeing with that and just say that I completely disagree. Our job as programmers is not just to write a bunch of code in a vacuum, it is to create that code and communicate it to the machines and people who will be consuming and manipulating it. Things like version control should be first class tools that we all learn in detail. They are literally the most fundamentally important tools we use every day if we work in a team. You aren't doing your job if you don't care about how your code interacts with your team and your deployment. Like an architect who doesn't know how to use a drafting table. It's incredibly frustrating that people let their egos stoke them into this idea that tooling is beneath them. It's almost certainly the cause of an incredible amount of bad software, even though much of its code is, I'm sure, quite clever in a vacuum. And I'd rather work with a hundred programmers who know how to use their tools than one programmer who looks down on them for it.

jupp0r 5y ago

Having been through two Perforce -> git transitions of medium sized repos with a few dozen people contributing and being the person with the most git knowledge in the group to be called in when people new to git mess things up: these GUI git clients are ok if you know what you are doing and what the consequences of checking various checkboxes are. They are not conducive to people learning how the tool git works and how to use it to solve real world problems. The command line is a great way to learn git and then fundamental understanding can be used to reverse engineer what GUIs do under the hood.

bob1029 5y ago

> My job isn’t to use git, it’s to write specialist software. This is true on so many other levels too. My job isn't to be an AWS expert, VIM master, Visual Studio ninja, Unix professor, et. al. My job is to make the customer happy. That is it. If the customer is happy, my project managers are happy, the executives are happy, the investors are happy. When all of your bosses are happy, you can get away with absolute murder. No one gives you shit about anything. Production went down because you fucked up? No big deal - that was like the first time in 18 months we had any problems, and the customer can't even see these things through all the magical features get to play with day-to-day. Need to take the entire afternoon to play overwatch because [arbitrary fuck you reason abc]? No one cares as long as you didn't have a scheduled meeting. In this realm, your mind is free to explore side projects without fear of reproach or guilt-trip. Tasks are executed with confidence and calm. Innovations are more frequent and valuable. People are actually relaxing in their time off and enjoy working for their employer. When the customer is pissed off, it is like entering into Doom Eternal as a non-player character. At every turn you begin to anticipate a heated conversation about missed target XYZ and incident ABC. Each ding of your outlook bumps your blood pressure by 20-30% before you even see the subject line. Your executives start taking damage from your customer's executives. Investors begin executing difficult queries regarding long-term viability. NO one is sleeping anymore. Side projects? Are you fucking kidding me? Not in this hell. So, when someone in my organization starts giving me the run-around about [pedantic greybeard doctrine which adds 10x overhead to a process], and also has no business value to show for said run-around, I begin to shut things down pretty quickly. If you want to play nuclear release authorization simulator every time you need to check in source code, please do this on your own time. Even the most elite hacker rockstars like to use GUI tools so they can see what the fuck is going on without making their eyes bleed every 10-15 minutes due to terminal character display restrictions.

agilob 5y ago

I expect other programmers to learn and master tools they use 50 times per day. You should be getting more efficient, productive and make fewer mistakes with languages, frameworks and tools you use daily. If you prefer sourcetree, be it, but I expect you to use it efficiently and not make mistakes other people wouldn't do with git, zsh and ohmyzsh (which contains like 100s of handy shortcuts).

u801e 5y ago

> My job isn’t to use git, it’s to write specialist software. Part of the job is to know and understand the tools that you need to use to in order perform the duties as part of that job. Saying that it isn't your job to use git is like a surgeon saying it's not their job to learn how to tie sutures when closing up the surgical site after completing the operation.

alerighi 5y ago

You don't even need git at that point. I don't understand why using git if you want a GUI... at this point, put the source code on the company fileserver and adopt "zip versioning", i.e. when you do a new release create an archive named "project-X.Y.z.zip" and archive it on the fileserver. If you need to work on another branch copy the source code directory. Why bother at this point? I don't understand people that wants to use git but they want do to so with a GUI that abstract everything that git was created to address, and they limit themself to write some code, commit and push. You are not gaining any benefit in using git this way, you are only wasting time to me. If you choose to adopt git, you learn how to use it, and so you learn the commands (it's not that much effort). In my experience GUI always created problems, especially if someone in a team uses a GUI that creates junk in the repository (like 100 useless merge commits created automatically for things that shouldn't really have been a merge that make git log unreadable...). Also people that uses GUI typically when they have a problem that the GUI doesn't know how to solve (because they typically implement the basic things and if something goes wrong they can't help you) just deletes the whole repo and clones it again, or worse they try to fix it by pressing random buttons in the GUI and put the repo in a shitty state so another coworker that knows how to use git has to waste his time cleaning up the crap that the fantastic git GUI made. And I'm not saying that you shouldn't 100% use GUIs. I use the one of VSCode for doing simple things like creating commits, switching branches, and stuff like that. For advanced features like merge, cherry pick, rebase, whatever I use the CLI, I find it more practical.

MisterBastahrd 5y ago

Wonder how many command line enthusiasts are using gitflow to make things even simpler than sourcetree.

neop1x 5y ago

>> My job isn’t to use git, it’s to write specialist software. It's like a plumber complaining that his job isn't driving with a car and that he wants customers to pick him up or wait for him until he comes on foot or via public transport.

jonahx 5y ago
A fairer analogy is that GP is saying, "I don't want to use a van to bring my stuff, but prefer a pickup truck." From the customer's POV, it makes no difference.

mattrighetti 5y ago

Using git from cli is like driving a Ferrari in a road with 30km/h speed limit

smusamashah 5y ago

If you understand how git works, its data structure essentially, then its far easier to do anything with IDE/GUI instead of CLI. They are more intuitive and shorten the work and less prone to mistakes.

OJFord 5y ago

> [I don't use git CLI so much any more] because I make less mistakes seeing the tree visually all the time. I look at the tree visually so frequently it must be my most common command. In the CLI. log --graph --decorate --pretty=oneline --abbrev-commit And then optionally adding whatever else, `--all` most frequently. (Obviously not writing it all out every time - with git config aliases, and actually `gitl` as a shell alias for that even. That's probably up there in my top.. 5? shell commands.) GUIs work too of course. Just pointing out you don't have to abandon the CLI for a tree. There's fancier third-party tools than native git log that are still CLI even.

Arch-TK 5y ago

So putting aside your argument that I completely disagree with but a lot of people have already voiced my concerns. > The guy who knows every command of git backwards is welcome to apply for a job managing a git repo or something if such a thing exists? Yes, this is the job of a maintainer in fact. They exist in a variety of organisations but maybe not enough. The best example is the linux kernel. Developers are expected to maintain their own local tree. When it comes to contributing code to the kernel, the patches are sent in a standardised manner to a mailing list and a maintainer then handles dealing with branches, rebases and merges. This means that developers don't need to know any more git than they really want to learn, aside from how to use git-format-patch and git-send-email which are really quite simple tools with an incredibly vast number of tutorials out there explaining them. This means that people who insist that it's "not their job" to learn git can achieve the requirements of "patches which build at every step and contain isolated step by step changes" using a GUI or doing something really stupid like copying the code aside, deleting and re-cloning the repository and then pasting and committing each step. It also means that people who actually know how to use git can get the job done in a fraction of the time. It also means that a carpenter^Wdeveloper's insistence to not learn how to use a claw hammer^W^W^Wgit will not affect their fellow coworkers/cocontributors.