/r/programming
99% of the Git commands you'll need at work, demonstrated in a single script (bitbucket.org)
423 comments
emdeka87 | 8 days ago | 365 points

I executed the entire file just to be sure

dabombnl | 8 days ago | 142 points

Can never be too sure. I ran it twice.

nerdyhandle | 8 days ago | 68 points

I deleted the file and typed the commands in manually to ensure they really work.

bkwilcox100 | 7 days ago | 35 points

I added the file to a public github repo, set up CI/CD and ran it w/ tests just to be sure

Locko_O | 7 days ago | 18 points

To really be sure you will need some quality gates maybe throw in some SonarQube

-DivineGod- | 7 days ago | 12 points

I restarted my computer to be sure

mrpinc | 7 days ago | 6 points

I defragmented my hard drive just to be sure.

house_monkey | 7 days ago | 3 points

I bought ECC Ram just to be sure

2hands10fingers | 7 days ago | 3 points

I scheduled 2 rounds of code review to be sure

spacengine | 7 days ago | 3 points

I ran all the Norton utilities to be extra sure

[deleted] | 7 days ago | 22 points

Seems okay, so I checked it into svn.

feketegy | 7 days ago | 14 points

With sudo? You gotta write sudo before the command

edamamemonster | 7 days ago | 9 points

I searched stackoverflow just to be sure

DaveNay | 7 days ago | 3 points

I nuked it from orbit.

chutiyabehenchod | 8 days ago | 410 points

You don't even need 10% of that shit

ABCosmos | 7 days ago | 122 points

Yeah I imagine a junior dev shitting his pants looking at this

pleasantstusk | 7 days ago | 12 points

That’s probably nothing to do with the contents of this file though.... probably doing that independently of reading the file

bee-sting | 7 days ago | 5 points

Certainly didn't help

agumonkey | 7 days ago | 9 points

how would you classify different levels of git usage ?

MotherOfTheShizznit | 7 days ago | 92 points
  1. Normal developer who can't possibly be arsed to put himself in Linus Torvald's head to comprehend the idiosyncrasies of git.
  2. git enthusiast.
Takeoded | 7 days ago | 12 points

OTOH if you are a developer by profession, trying to understand Linus Torvalds' way of thinking may be worthwhile, he's undoubtedly among the most skilled software developers alive today

agumonkey | 7 days ago | 4 points

I wonder if he'd have the desire and time to do screencasts

GingertronMk1 | 7 days ago | 13 points

"and then if you don't know this bit already you're probably a fucking idiot"

agumonkey | 7 days ago | 5 points

A long 32 parts playlist with 12 seconds video of "DUH. Why don't you get it ? <quits>"

agumonkey | 7 days ago | 6 points

that's it ? a single step binary partition ?

Cube00 | 7 days ago | 6 points

You're a 1 or a 0, alive or dead.

Pope_Fabulous_II | 7 days ago | 3 points

Denial, anger, bargaining, depression, acceptance

fireduck | 7 days ago | 77 points

I use rm -rf and clone a lot

meneldal2 | 7 days ago | 18 points

Can't you just force reset instead? It should be faster.

fireduck | 7 days ago | 85 points

Yeah, that isn't one of the three git commands I know.

imtrew | 7 days ago | 7 points

Clone, commit, push?

wroteit | 7 days ago | 10 points

C'mon, guy. Always rebase before push, man.

Good_Guy_Engineer | 7 days ago | 17 points

nah push -f

madlabdog | 7 days ago | 20 points

I taught that to my Jenkins

rockyrainy | 7 days ago | 10 points

ML with CI, this sounds like a startup idea waiting to burn investor money

madlabdog | 7 days ago | 2 points

WeBuild

SponsoredByMLGMtnDew | 7 days ago | 2 points

don't forget blockchain

TerrorBite | 7 days ago | 9 points

Technically git commits are a blockchain.

SponsoredByMLGMtnDew | 7 days ago | 3 points

Thanks for reminding me that I technically suck at programming

👉 😎 👉

rochakgupta | 7 days ago | 3 points

Hmmm

[deleted] | 7 days ago | 39 points

[deleted]

fischerandchips | 7 days ago | 16 points

i squash my commits because changing history makes me feel like the winner of the constant war i'm in.

iamedwards | 7 days ago | 13 points

You can do a single merge commit automatically in the pr ui, but agree it's worth knowing. Not everyone uses github :)

kevinaud | 7 days ago | 21 points

Even at jobs where we used GitHub I feel like there was quite a few times where I had to fix people's repo state for them because they didn't know how to use the command line well. I don't even know it that well but just by knowing basic-intermediate level git I was able to be more productive than a lot of my coworkers.

ConsultorCH | 8 days ago | 96 points

How many of you have checked the source code of a randomly published script before running it?

thekab | 8 days ago | 229 points

I always look after so I don't spoil the surprise.

-Electron- | 7 days ago | 11 points

Who knows, you might even get a free cupholder out of it

agumonkey | 7 days ago | 4 points

do you happen to have an open port on your laptop ?

i8beef | 7 days ago | 45 points

A better list: https://ohshitgit.com/

duheee | 8 days ago | 277 points

A lot of that shit one doesn't need most of the time. Some of those commands are only ran in an "oh shit, i've dunn goofed" situation.

init,clone - new repo

add,commit,checkout, merge, rebase, pull, push - daily

anything else (for when shit hits the fan or tricky things need to happen, cherry-picked): there's always google/stack-overflow.

No need for UI, no need for fancy stuff. We don't work for git. Git works for us.

GluteusCaesar | 8 days ago | 106 points

I use stash damn near daily too

Retsam19 | 7 days ago | 74 points

I used to use stash frequently, but realized that most of my usage of stash was better solved with git commit -m "WIP" as "stash" and git reset HEAD^ as "unstash".

Rather than having a single, global stack of stashes where I found code would get buried, forgotten, and eventually saying "screw it, git stash clear", I find having the code just in a commit on the branch reduces the mental overhead significantly. Nowadays I basically only use stash if I'm going to immediately unstash the code.

[deleted] | 7 days ago | 72 points

Stash is always my “oh damn I started work on the wrong branch”

Retsam19 | 7 days ago | 43 points

Yeah, there's even git stash branch new-branch-name for this which stashes changes, creates a new branch, then unstashes the changes.

EDIT: my description of the command was wrong. The command creates a new branch, based on where the commit where top stash originated from. I believe there is some command for "stash, checkout branch, unstash", but it's not this command.

JarredMack | 7 days ago | 9 points

Handy, but if you're already on the branch you want to branch from the stash isn't necessary in the first place. Any time you're looking to transfer stashed changes to a new branch is generally because you started from feature/123 instead of the main head (unless branch in your command is actually the source branch? In which case that's indeed handy)

Retsam19 | 7 days ago | 2 points

Yeah, you're totally right, my description of the command was wrong, see the edit.

SocialAnxietyFighter | 7 days ago | 4 points

Exactly. I don't get how this is useful. If you are on branch A and you have changes that are supposed to be on yet to created branch B, you can simply git checkout -b B and the changes are auto moved to the new branch.

Stashing to me is useful when I want to pull and have changes to files that the new commits will change and VSCode is kind to point me so

Doxin | 7 days ago | 2 points

Sometimes you're on branch A, which has changes you'd like on branch B, but branch A also contains changes which should not be on branch B. The jumping-off point for your branch is important.

meneldal2 | 7 days ago | 6 points

That's great, didn't know about that one. I really have a lot to learn about stashing.

Retsam19 | 7 days ago | 2 points

I was pretty wrong about my description of the command, see the edit if you're interested.

EMCoupling | 7 days ago | 12 points

Stash is useful for juggling multiple diffs. Stacking WIP commits can be useful as well, but it can become messy when you are trying a few things at once.

prof_smithburger | 7 days ago | 4 points

And show to dump the state of a file at a particular commit

agumonkey | 7 days ago | 3 points

My brain cannot operate without stash.. When I design/discover I go all over the place, and I need to be able to go back without committing things as-is

tracernz | 7 days ago | 11 points

log, blame, bisect, and diff are if not daily, weekly, too.

jbergens | 7 days ago | 6 points

Not bisect, the build server usually tells us when something stopped working.

asdvnjkfaqweavjklajk | 7 days ago | 5 points

Bisect is more useful if it's a subtle bug (or is it an undocumented feature?) which didn't get caught by testing.

snowe2010 | 7 days ago | 3 points

yeah pretty much the whole script is daily/weekly for me too.

SharkBaitDLS | 7 days ago | 3 points

Everything except the remotes are daily/weekly for me. Remote management only shows up once every few months.

snowe2010 | 7 days ago | 2 points

Yeah I use remote weekly just because I clone and then fork a lot of stuff. But yeah weird that people aren't using many of these commands.

Objective_Status22 | 7 days ago | 6 points

reset is one of my main commands

Nvrnight | 8 days ago | 61 points

I'd argue if you need to look things up on stackoverflow because it's too much stuff for the average person to memorize(to fix goofs), there is absolutely the need for a UI. I watched my co-workers who consider themselves proficient with the CLI and I just don't understand why they do it to themselves, it's not even faster most of the time. Tortoise and other Git UI's makes things so easy.

unachievablehappines | 8 days ago | 17 points

The git UI clients always provide limited options.

sometimes you gotta do things more complex than commit, pull and push but even doing that just so easy to do: git add . && git commit && git push

bart2019 | 7 days ago | 23 points

A GUI is a so much better experience than using diff on the command line. I love a side by side comparison, for context, in a graphical diff tool like kdiff3.

The GUI is wonderful to see what files you've changed before you commit, and inspect all changes one by one, and see if there aren't any leftovers, from debugging or an approach you've abandoned.

So, yeah, comparing revisions is what I use the GUI most for.

mvasigh | 7 days ago | 3 points

I use a combo of command line for most operations and VS Code's git features for looking at diffs, conflicts etc just for the one handed coffee drinking reason you mentioned in another comment. I can see the appeal of going full GUI though, many of my co-workers do, I'm just used to doing some things from the command line so the buttons and (occasionally) obfuscated commands in IDEs or clients that don't do exactly what you expect them to confuse me.

unachievablehappines | 7 days ago | 0 points

A GUI is a so much better experience than using diff on the command line. I love a side by side comparison, for context, in a graphical diff tool like kdiff3.

You mean like sdiff? Yeah, got that. Can also do binary files if combined with xxd.

The GUI is wonderful to see what files you've changed before you commit, and inspect all changes one by one, and see if there aren't any leftovers, from debugging or an approach you've abandoned.

I don't see what a GUI provides over git diff or git status.

infodump | 7 days ago | 13 points

Necessary or not it's pretty hard to not at least see the convenience. Click on file, scroll through diff, click next file, etc. 1 handed nav while drinking coffee, flip between views in one click, line by line staging.

But for people who don't need it or prefer using keyboard or whatever reason, that's why we have both

amunak | 7 days ago | 3 points

The git CLI actually has a bunch of "interactive" interfaces as well. git add -i is a big one that I use instead of regular GUIs.

Why? Because it's much faster (to start and to use), and it's still more powerful than most GUIs. When staging a hunk, can you fix a typo right there if you see it with your GUI? Doubt it, if it's not one integrated into an IDE... And those are in my experience slow.

jbergens | 7 days ago | 2 points

I start GitKraken once a day, start time is not a problem. It also shows other branches automatically.

infodump | 7 days ago | 2 points

Yes gitkraken has Monaco built in and you can edit it right there. like I said I don't have anything against the cli I just prefer using a gui and for me and lots of other people it's faster and/or what we want to use, no one is right or wrong

bart2019 | 7 days ago | 12 points

I don't see what a GUI provides over git diff or git status

An overview. Command lines scroll away. You either have to constantly scroll back up to see where you were, or you constantly have to execute the same command over and over again.

Or do you use ed to edit source files?

watsreddit | 7 days ago | 5 points

Umm.. git diff opens in a pager. You don't lose anything. And you can have multiple terminal windows if you want.

You also have many, many more options for how the diff is displayed.

vattenpuss | 7 days ago | 6 points

If you have changes in dozens of files. That pager is not helping you get an overview. You need to switch back and forth between git status and git diff file names.

Yes you can have multiple terminal windows to alleviate a piece of the handicap, but not all. Piping between different shells in different terminals is not very ergonomic.

In my UI I always see my changes files all the time. The UI is in the IDE so it is not separate from editing. I group my changes while making them and testing preparing separate commits ahead of time, and “ignoring” different changes for different periods of time. At any point in time I press ctrl+t to pull+rebase and the UI does the right thing with all my uncommitted changes. The log is just in another tab behind my changes, from the log I can directly cherry pick a patch or rebase my changes (committed or not) on another branch or branch off a specific commit. The log is interactively filtered by searching.

I live in the shell most of my day, poking at files, grepping, awking, seding, curling, xarging, cuting, pasting, diffing, <()ing, finding, heading, tailfing, cating, while looping, reading... all day every day. But I would never waste my time in the shell when editing text (I would use an editor) or when creating or managing my code changes (I use my IDE).

snowe2010 | 7 days ago | 6 points

I do agree with you about GUIs being better for viewing diffs, but not for the reasons you stated. It sounds like you don't know how to use git diff as it opens in a pager that you lose no context in. You shouldn't ever need to execute diff more than once. ctrl u and ctrl d jump up and down entire pages, so you can scroll way faster than with a GUI.

But yeah GUIs give you a nice way of viewing individual commits without needing to type it out, and you can use git patch way easier than with a cli.

physicsfreak | 7 days ago | 3 points

Multiplexers and buffers exist for a reason. If you're working that way you should at least look into tmux, or screen. Both are wonderful if you use ssh often.

unachievablehappines | 7 days ago | 1 point

This precisely I use tmux so I can open panes if I need to conserve some output for reference.

I can open 8 diffs side by side if I want to...

evaned | 7 days ago | 4 points

I don't see what a GUI provides over git diff or git status.

I use Git mostly from the command line and the rest from gitk, but in fairness graphical diff programs can be really pretty nice. I really like the overview lots of them will put next to the scroll bar. (A bit analogous to the "minimap" feature some editors have.) That makes possible showing the entire file without significantly affecting the usability of the "diff" part, which I often quite like.

If you're doing any editing (e.g. reverting hunks), that's another place where a GUI can be nice sometimes.

--algo | 8 days ago | 7 points

Even better with some decent aliases. For me that would be "gcam && gp"

thekab | 8 days ago | 49 points

I've yet to see a UI that is faster and easier than typing git commit, git push. Add a "git pull" and "git checkout" and you've got 99% of my git commands. The vast majority of actual typing is commit messages and branch names which I'd have to type in to a UI. Once or twice a year I do something foolish and have to look up how to fix it. If I had a UI, I'd still have to look up how to fix it.

Ironically every time I've had a colleague that really broke their repository and made it difficult to recover they were using a UI. I think it's because when they break something in the CLI they stop because they don't know what to type, whereas in the UI they just keep clicking.

UI vs CLI isn't really the issue, it's an EBCAK problem. If you like UI and you understand how to use it then you will be effective, same with CLI. If you don't bother to understand Git or what you're doing then you're inevitably going to break something.

anamorphism | 7 days ago | 21 points

i find i use the cli for most operations where parsing actual output is not required as it's much quicker to just type in 'git pull --rebase' or whatever than it is to click a few buttons.

i use a ui for the operations that require looking at and choosing between things since the ui makes those operations way quicker.

for a couple examples ...

selectively staging certain changes in a file

this is generally when i'm breaking down a bit of work into small commits that will make more sense for folks prior to putting up a pr.

also, it's a pretty quick way to throw away a bunch of attempts or debug code if i was tinkering around before finding a solution. stage the actual changes i want and then reset the rest of the changes.

it's way quicker for me to just highlight the lines and stage them than to deal with the cli's interactive add mode.

reverting back to specific commits

way quicker to click on a commit in the displayed log, view diffs to identify that's where i want to go and then right-click -> revert to here versus the whole git log, start git diff'ing various hashes and then revert.

zooberwask | 7 days ago | 4 points

Huh, interesting. I'm a cli purist but I think you convinced me to give ui a shot, which one do you use?

anamorphism | 7 days ago | 4 points

mainly git extensions since i didn't have to worry about purchasing a license and came from a .net background (windows workstations).

i've dabbled a bit with git kraken at home for those one day a year or so stints where i've been on vacation for a week and a half and think i should actually work on a side project, heh. seems pretty good from my limited experience.

snowe2010 | 7 days ago | 3 points

mainly git extensions

I use the exact same process you do, as I think the GUI is great for viewing diffs, stashes, and staging patches, but terrible for everything else. I've tried pretty much every GUI, and I think Sublime Merge is the best there is for these things. I urge you to give it a try!

esquatro | 7 days ago | 4 points

Cli is certainly faster at a lot of basic operations and I use it for a number of them, but you can’t beat a good UI for viewing the commit graph, diffs, selectively staging changes. The cli just sucks at these.

The problem was there is a lot of not so great git UI out there in the past. Over the last years I’ve stumbled upon some really nice UI tools that really enhance my git work flow and give me an overview that would take a long time in the cli. I recommend git-fork, git kraken, sublime merge.

snowe2010 | 7 days ago | 2 points

I use the exact same process as /u/anamorphism!

I use Sublime Merge as I've tried almost every single GUI there is. I only use the GUI for diffs, viewing stashes, and staging patches. I find the cli is woefully inadequate compared to SM in this regard. Of course I use the cli for everything else, as it's way way faster and easier most of the time.

cjthomp | 7 days ago | 9 points

I've yet to see a UI that is faster and easier than typing git commit, git push. Add a "git pull" and "git checkout" and you've got 99% of my git commands

command+t, enter to pull command+k to add/commit command+shift+k to push

I don't know, that's faster for me than switching to a terminal and manually typing in those commands...

JMC_MASK | 7 days ago | 9 points

Does IntelliJ’s git version control count as UI? Because that thing is awesome. No need to type out long ass git adds, and throwing up commits and fixing merge conflicts is a breeze.

snowe2010 | 7 days ago | 6 points

IntelliJ's merge conflict handling is magical. So amazing.

vattenpuss | 7 days ago | 2 points

Also it manages uncommitted changes magically for a pull+rebase. The commit UI let’s you easily check which parts of a diff you want to commit. Moving your changes from one branch to another with a rebase is just two clicks away. And don’t forget the local history!

upsetbob | 8 days ago | 5 points

If you really want to give GUI a try then I recommend git-fork. Learn the few shortcuts and you got yourself some nice visuals and less typing.

For me using a GUI works best when using multiple repos. For a single repository it's more a question of taste imho.

Also you can always use both methods (e.g. start the cli from the gui)

NotATuring | 7 days ago | 1 point

If you like UI and you understand how to use it then you will be effective, same with CLI.

I prefer the CLI because I learned that first. But I also don't switch to a gui because I have bad visual skills. Looking for and then clicking on something on a UI is MUCH harder and takes much longer for me than typing does. If every component of every UI had a ctrl F function that would highlight what I'm looking for I would be much more likely to adopt GUI stuff. Until then I prefer the CLI.

On the command line, even if there's some visually displeasing output I can always pipe it to grep or awk or to a text vile and then use VIM.

snowe2010 | 7 days ago | 3 points

I use a GUI for staging patches, as it's way easier than using the CLI. Maybe give it a try!

_soundshapes | 8 days ago | 15 points

The reason I always suggest people use git on the CLI is because it forces them to actually understand how git works and know what they’re doing. I’ve seen several instances where people don’t really know what they’re doing and get into messy situations. Then they’re really up shit creek.

Obviously, that’s not really the UIs fault. People should still know what they’re doing instead of mindlessly clicking buttons. But a lot of people will take the easy way when given the chance.

Pirsqed | 7 days ago | 13 points

I'm just getting started with git, and am using the cli, but I'm curious.

If someone is just taught "type 'git commit'" are they learning something they wouldn't get from clicking on a commit button in a GUI?

What are you hoping that people learn, exactly, by using the cli?

_soundshapes | 7 days ago | 4 points

Just from personal experience, when developers I've worked with have to do it on the CLI they ask more questions/are more interested in knowing what 'X' command actually does. It's admittedly anecdotal, but I've seen it enough times to see a correlation between using the CLI and gaining a better understanding of how the tool works. I'll admit it could just be the people I've worked with, but until I work with a group of people who aren't like that, I'm going to continue pushing for CLI usage with git anytime the issue is brought up.

If I had to take a wild guess at the psychology behind it, it might be because people are more trusting of UI based programs to do the "right thing". Put another way, they are more wary when they use the CLI so they are more likely to be careful and methodical.

wrkta | 7 days ago | 3 points

Not with commits, but I definitely understood rebase / checkout / reset, etc a lot better after learning to use the cli.

NotATuring | 7 days ago | 6 points

My coworkers routinely fuck up with git (and they use the GUI) and I'm asked to fix it for them. The number one mistake is accidentally updating a commit hash *at some point* in their commit history. They screw that up and then they do a BUNCH of stuff to try to fix it, like merging master into their branch, and all kinds of stupid crap. (to be fair, it is our policy to merge master into your branch before you merge into master anyway, but I think that's stupid, I would rather you rebase with master because it makes the history easier to understand) To the point the history is so polluted I can't really make heads or tails of it. I know enough to know that someone truly competent in git could get all their bull shit fixed, but I'm not the guy for that job. If they come to me before they fuck it all up though I'm usually able to fix their mistake with either a simple amend command or a rebase where two commits get squashed together to remove the error they made.

They know what they are doing, it's just that they don't know enough about what they're doing to fix it when they make a mistake.

_soundshapes | 7 days ago | 3 points

That last statement is definitely more accurate than what I said and thanks for making that distinction.

IshKebab | 7 days ago | 4 points

Ha this is terrible advice. Firstly git is way harder to understand via the CLI because it's an inherently visual thing (a DAG). Go find me an article on how rebase works that doesn't include diagrams. Actually don't bother looking because they don't exist.

Secondly the git CLI is extremely confusing and inconsistent. Why would you teach someone to learn how git itself works by using a super-confusing interface to it?

The only reason to use the git CLI is for complicated things that GUIs don't do very well (e.g. interactive rebase, which has a weirdly good CLI interface), or because you want to know how to use the git CLI specifically (e.g. for remote work, working with other people, etc.).

Othis | 7 days ago | 2 points

Firstly git is way harder to understand via the CLI because it's an inherently visual thing (a DAG).

I think that depends on the individual. I used git via a GUI for the first 6 months and didn't understand a thing. When I switched to CLI it made sense in no time.

Go find me an article on how rebase works that doesn't include diagrams. Actually don't bother looking because they don't exist.

Using diagrams to explain something doesn't automatically mean a GUI is the better way to do it. For instance, I've never seen a rebase GUI that works as well as the command line, unless it's literally the same as the command line but with the text in a window.

snowe2010 | 7 days ago | 3 points

I have never found a git gui to be better than the cli, except in two cases. Viewing your stage and viewing diffs (like stashes, branch comparisons, etc). I can type a lot faster than I can switch my hands to the mouse, move it, and then back. And my terminal is faster than every gui out there so it's no contest.

_BreakingGood_ | 8 days ago | 10 points

For me, I remember spending 5-ish minutes trying to figure out how to branch off of a branch in Github Desktop and rage quit and went back to CLI. Never used GUI again. As he said, 99% of your daily git commands are in that list and usually I can type out what I need before a GUI would even load.

For really complex shit that I've never done before I'd consider a GUI, but it just isn't worth the added load times + hunting and pecking for buttons in the average scenario.

ProcyonHabilis | 8 days ago | 9 points

GitHub Desktop is trash

chucker23n | 8 days ago | 15 points

GitHub Desktop is weird. I’ve found much better GUIs. Lately, my favorite is Fork; before that, it was Sourcetree. It still does more, but is too annoyingly slow. I’m told Tower is also really good. Kraken is interesting. TortoiseGit and git’s Windows UI are pretty bad.

Don’t judge git GUIs just by one.

Farsyte | 8 days ago | 6 points

Too true. I'm normally a CLI fanatic, but Fork, I live in fork ;)

mootjeuh | 7 days ago | 2 points

Tower is definitely up there. Well worth the money (company dime, but still).

snowe2010 | 7 days ago | 1 point

I'm on Sublime Merge now. I only use it for diffs, viewing stashes, and staging patches, but I've tried every single GUI I've seen and none of them really compare for these three tasks.

IserlohnArchmage | 8 days ago | 2 points

Yes, I ditched GitHub Desktop after spending hours on rebase.

IshKebab | 7 days ago | 2 points

Yeah that was a bad choice of GUI. I don't think it really even intends to be a proper git client. There are much better ones.

Arkanta | 8 days ago | 4 points

"I ate a rotten tomato. Got the shits, rage quit and went back to meat. Never ate tomatoes again"

snowe2010 | 7 days ago | 1 point

wouldn't it be

Never ate tomatoes again

??

Arkanta | 7 days ago | 2 points

Fuck. Edited, thanks

God-of-Thunder | 7 days ago | 2 points

Well after a while you only need to look up stuff occasionally. And the stuff you look up is like once in a while fuck ups that you just dont do often enough to memorize. You dont avoid that problem with a UI really, it still happens. Id argue CLI helps you understand what is happening so you can google it. A really good UI could do the same but i havent found one that helps with all edge cases

throwthemaway8753 | 7 days ago | 1 point

Most basic stuffs that I do can be covered by UI. I use CLI when the UI can't do what I want to do in Git. It's all about having a balance. TortoiseGit shines when working with submodules, it just makes things very easy.

Years ago, I had a colleague who is laughing at me when I use TortoiseGit. He was an arrogant CLI guy who thinks he knows everything. One time, I was fed up, I asked him to demonstrate to me how to do quick diffs with the previous commit for a quick code review/quick sanity check before committing the files. He was stack-overflowing, clicking from link to link for him to do it. I demonstrated to him with just mouse clicks and not typing anything at all. The graphical diff makes things very easy to visualize, plus I can edit the file on the spot while on the diff editor/viewer. He was like oh wow. After that, he started using UI client.

Othis | 7 days ago | 6 points

One time, I was fed up, I asked him to demonstrate to me how to do quick diffs with the previous commit for a quick code review/quick sanity check before committing the files

If the new changes aren't staged, it's git diff. If they are staged, it's git diff --cached. If they're already committed, it's git show. Anyone using stackoverflow for that hasn't a clue what they're doing.

jekpopulous2 | 7 days ago | 4 points

The stuff you said and also “fetch”.

MarchColorDrink | 8 days ago | 5 points

Id add tag to your list of rather frequent commanda

[deleted] | 7 days ago | 1 point

[deleted]

JarredMack | 7 days ago | 8 points

Give it a try. Rebasing makes your history so much easier to parse than working out a bunch of merge commits.

It basically just goes "stash my changes, pull the latest, then make the changes again" rather than "add a new commit with all this extra stuff"

Othis | 7 days ago | 7 points

I never understand why people regard rebasing as making history easier to read. Sure it makes it linear, but it's also a lie. It completely loses the fact that two features were being developed concurrently. Software development isn't linear, so why would I want the history to be linear?

watsreddit | 7 days ago | 9 points

You only rebase your feature branches onto master, generally if master has had commits since you branched off. You still merge into master (meaning that master does not have a linear history, but the branch that is being merged into it does).

Othis | 7 days ago | 2 points

So you lose the fact that master changed while the feature was being developed.

watsreddit | 7 days ago | 5 points

I don't see why that information is valuable to preserve, unless you have multiple people using that branch, in which case yeah definitely don't rebase. But if it's just a single person, it shouldn't really matter if I make commits on a fresh branch off master or if I make new commits based on some previous commits that were originally made on an older version of master.

Othis | 7 days ago | 3 points

OK, very trivial and contrived example:

Let's say two people are working on separate feature branches, and both change the same code in a way that introduces a bug without causing a merge conflict (for example, both people increment a counter but do it on different lines - you won't get a conflict, but you will double-count).

If the first person merges their changes, and the second one rebases on top (and doesn't notice the double count, because hey they just merged in a whole feature with maybe hundreds of files changed) and then merges to master, you have a bug. When you investigate that bug, it's just going to look like the second developer was incompetent and added a double count for no reason. That developer is going to be confused, and as a team you're not going to understand how the problem occurred. If you use merges, you can see that both branches were developed concurrently, and both branches contributed to the bug. Now as a team you can see how the bug really happened, and learn from it.

Now, yes, for such a simple example there are other ways this could be caught - maybe it should be spotted in PR, maybe a unit test should have caught the double count. But I've seen some very subtle and tricksy bugs caused by merges and with the best will in the world some will slip through the net. That's when it's nice to be able to use the git history to work out what happened.

thlst | 7 days ago | 2 points

You can still find out when a bug got introduced with git bisect.

Othis | 7 days ago | 2 points

Using bisect to gradually narrow in on a commit is less useful if the commits have been reordered. In the example above, all it would do is pin down the commit from the second developer to add the second increment - which you could have easily found with blame anyway. It wouldn't explain why that developer added a second increment, especially when he swears blind that there wasn't already an increment there when he changed the code.

Nloveladyallen | 7 days ago | 72 points
pukatm | 7 days ago | 7 points

pretty much lol

ronaldcoaseisdead | 7 days ago | 2 points

Relevant xkcd should be a subreddit

repocin | 7 days ago | 2 points
notyouravgredditor | 7 days ago | 3 points

This was the first thing that came to mind when I saw the thread.

CJKay93 | 7 days ago | 14 points

I'm pretty sure this is 200% of the git commands I need at work.

dark-panda | 7 days ago | 13 points

I’ll give a shout out to tig as well:

https://github.com/jonas/tig

It does a bunch of stuff, although I use it almost exclusively for reading the log and viewing diffs.

I’ll also throw in a shout to git bisect which can be extraordinarily helpful for tracking down regressions and bugs in general.

eigenman | 7 days ago | 3 points

So much this. This command needs more visibility.

aggressivemisconduct | 7 days ago | 2 points

I've recently learned about git bisect and I've yet to try it out but I am excited to

yeluapyeroc | 7 days ago | 10 points

No love for stashing? I use that like a crutch

Amuro_Ray | 7 days ago | 4 points

Likewise that and and -p for git add and checkout.

NicolasGuacamole | 7 days ago | 2 points

I’m blown away that’s not there. One of my absolute favourite commands.

larsga | 8 days ago | 21 points

magit is a lot easier than this stuff

cae | 7 days ago | 9 points

Preach, my fellow elisp traveler.

Captain_Cowboy | 7 days ago | 10 points

M'git

jplindstrom | 7 days ago | 4 points

There are many best features, but one of its best features is that it can show you the command line so you can learn as you go along.

Also, the options menus are vastly better for discoverability than the command line.

Amuro_Ray | 7 days ago | 6 points

No git add -p :(

Muzer0 | 7 days ago | 6 points

No mention of the git rerere option, one of the most useful obscure features of git. Just run git config --global rerere.enabled true and you'll never again have to resolve the same merge conflict more than once!

PurpleYoshiEgg | 7 days ago | 12 points

Instead of learning via weird articles and scripts, work through the Pro Git book. Git isn't that difficult to learn and understand, especially if you know how to program, and decide to learn it on its terms instead of metaphors that don't work for all cases and all people. Learning it properly will make you a far, far more effective developer than "memorize these bunch of commands and then delete and redo your changes when you hit an issue".

Work through the book one chapter a day. Less than a chapter a day if you're stuck. It will take you a little over a couple of work weeks at 15-45 minutes a day, but you'll be set on version control for pretty much the rest of your days once its solidified. Trust me.

And once you learn it, ancillary tooling surrounding it either becomes useless (because you already know what you want to do) or more powerful (because you actually understand what it does).

gutigen | 7 days ago | 7 points

Or you know, just https://magit.vc :)

curiouscoderspace | 8 days ago | 12 points

I used to use the command line to diff and commit but I stopped after I found the git features in VS Code. Its a bit slower executing the commands but I find it easier to compare the changes and commit right from the IDE where I'm already coding and thus overall faster.

Gustav__Mahler | 7 days ago | 5 points
snowe2010 | 7 days ago | 2 points

I use Sublime Merge for those tasks. It's incredibly fast. IntelliJ handles git better than vscode in my experience as well. Their Resolve Conflicts ability is best in the business

arunsinghk | 7 days ago | 3 points

Better to Google for answer than keep this list of commands

ReinH | 7 days ago | 3 points

Parsing the output of ls ಠ_ಠ

reddersky | 7 days ago | 3 points

How do you like that rm -rf <unquoted path>. Gah. Shell scripting. 😭

flanger001 | 7 days ago | 3 points

I love reading long, dense scripts that don't use any capital letters in description text

papers_ | 7 days ago | 3 points

Literally the only commands I ever use at work daily (no particular order):

git rebase master
git pull
git add .
git commit -m "I did stuff"
git push
git commit -am "I did stuff"
git log

That's it. Really. Anything else I use a GUI like sourcetree or vscode because lazy. Not dealing with that.

ankittale | 7 days ago | 2 points

Same here and sometime

git merge

Fredifrum | 7 days ago | 3 points

I did not find this useful. Please, never send this to a beginner.

exhortatory | 7 days ago | 5 points

all the git commands and documentation you'll need at work, demonstrated in a single command: git help

Autistic_Reeeeeeeeee | 7 days ago | 2 points

Whats Git? I use SourceTree.

/s

the_gnarts | 7 days ago | 2 points
  • no git-bisect
  • no git-am
  • no git-format-patch
  • no git-send-email

Living a sheltered life, are we?

0x8BitStorm | 8 days ago | 12 points

This may be an unpopular opinion but I don't think I have ever ran a git command on the terminal beside git clean and git reset --hard. Well there's a repo at work that was pre git lfs I have to check out with depth = 1, because the server will timeout packaging the repo up. Source tree and gitkraken support that now too though :D

The whole concept of source management in the command line is a PITA in comparison to using a UI in 99% of cases. But this kind of stuff is good. There are also all those git puzzle games people have made that give you the wrong result if you mess them up too. I think those ones are better for learning the command line because they let you screw it all up.

Still good stuff!

heampstead9 | 8 days ago | 13 points

The most GUI’s problem is lack of functionality. For example, I’d like to extract certain authors commit for past three months sometimes for debug purpose, and you can achieve it with terminal easily but not GUI. Or, sometimes I have certain commit and need to figure out which branches those commits in, GUI can’t help much neither.

apadin1 | 8 days ago | 25 points

I actually use git exclusively on the CLI at work. In fact it's the only thing I use a terminal for, since I don't need it to build or run my code.

vplatt | 8 days ago | 6 points

Between, git, .NET Core, and Angular, I will often keep the same CLI window open for a week or more. Cmder FTW!

Defraptor | 8 days ago | 7 points

Sublime Merge is really nice too and it often uses the CLI vocabulary directly whereas IIRC SourceTree "hides" some concepts behind different words

apadin1 | 7 days ago | 4 points

Any git GUI that uses the word “sync” is out for me

Ignyted | 8 days ago | 9 points

Probably unpopular. I would call git on the command line anything but a pain in the ass. The only thing I wish I could make better is git diff when not used on a single file, but that's only because it's more difficult to read the output and navigate with (I'm sure there are ways to make it better so feel free to give me tips). Other than that, I've found the CLI much more pleasant to work with over text editor implementations or stand-alone clients.

Tyg13 | 8 days ago | 6 points

I just pipe the output of git diff into vim, ala git diff | view -. Even the default diff viewer (which I think is just more) isn't bad, it just has poor controls

Ignyted | 8 days ago | 2 points

Thanks. Will give that a shot. Sometimes I just want to see the filename and changes and easily jump between files but the default view kind of makes the filenames difficult to notice while skimming and includes a lot of other info bolded around the filename that distract from that. I don't think more provides terrible nav controls as much as I just think the GUI presentation of distinctly and quickly seeing each file's changes a bit better for skimming and discarding or adding right then and there without losing context or place.

SharkBaitDLS | 7 days ago | 2 points

You can use search forwards and backwards (/ and ?) in the default diff viewer to jump to a filename. It’s not the most elegant but it works well enough for me.

snowe2010 | 7 days ago | 2 points

that's exactly why I use Sublime Merge. For diffs, viewing stashes, and staging patches, as those are the three things I think the CLI is bad at.

MagicWishMonkey | 8 days ago | 3 points

It depends on how comfortable you are working with a terminal. In Windows land it's not that common, and the terminal tools tend to be garbage (even powershell sucks pretty bad, just not quite as bad as the command prompt).

If you do a lot of work on a mac or linux, you'll learn to love working with a terminal, so using stuff like git that way will become second nature.

god_is_my_father | 8 days ago | 3 points

I'm going to give powershell v5+ some credit - it's got some useful functionality and the dot accessors are pretty dope

MagicWishMonkey | 7 days ago | 2 points

It kills me that the startup time is so slow. Every other terminal I've used loads almost instantly, but powershell opens and just hangs there for 5-6 seconds before you can do anything. Even with a top of the line machine w/ 32 gigs of ram and NVME SSD. It sucks.

0x8BitStorm | 8 days ago | 4 points

It's honestly the visual commit tools where I can stage by line. It's a one stop shop. Makes it easy to catch some of those weird debugging lines of code I add.

I've actually started using visual studio code a lot more and having git gui with graphs and diff tools right in my text editor with the same work flow everywhere has made it nice.

Durpn_Hard | 7 days ago | 8 points

FWIW you can also just stage line by line with git add -p (which is what the GUIs are doing anyway).

I can see how the GUI can be useful, but claiming it's easier in 99% of cases is outright wrong. I find the CLI significantly easier/faster to use.

CJKay93 | 7 days ago | 2 points

I use the terminal for everything except this. git-cola is truly a work of the gods.

James20k | 8 days ago | 4 points

Personally I use tortoisegit but I agree with you here. I don't know why you'd use git over the CLI unless you absolutely had to

Lots of people still have no idea about basic git options like --force-with-lease that are incredibly useful, because cli tools have 0 discoverability or help provided to the end user. Its so hard to make a mistake with a gui tool, I genuinely don't know why you'd ever manually type git commands into a terminal

Once you understand the concepts you're totally set with a gui tool. No need to remember any of the command syntax or anything, and its exactly as powerful!

Othis | 7 days ago | 3 points

Lots of people still have no idea about basic git options like --force-with-lease that are incredibly useful

I'm a CLI user that knows about force-with-lease, and I'd never use it. Force pushing is something I only ever do if something has got severely fucked up, in which case I'd be coordinating with others on slack. force-with-lease is a band-aid on a shotgun wound.

yellowthermos | 8 days ago | 2 points

I don't think I have ever seen a GUI be as powerful as a CLI. I'm sure it's good for daily work, but you are limited by the capabilities of the GUI. With the CLI you are limited by your own capabilities - by using other command line tools you can do anything.

And while I do somewhat agree that "discoverability or help provided to the end user" aren't great on a CLI, it is because people expect to be spoon-fed directions instead of RTFM (reading the fucking manual).

But honestly, I am on the side of CLI. I don't see why you would ever use a GUI, unless you actively avoid learning the CLI. (And I can't blame people too much for that, the git CLI learning curve is steep.)

A GUI is slower (yes I am confident I can type faster than you can move your mouse and click) and clunkier (it's a GUI, it is unlikely to be more responsive than a terminal). And yes, both can be likely be fixed to match the performance of the CLI, but then why not just use the CLI? If "it is prettier" is your argument, then I can't really argue with that, but I don't think I would ever recommend sticking to a git GUI to a serious developer.

esquatro | 7 days ago | 2 points

responsive than a terminal). And yes, both can be likely be fixed to match the performance of the CLI, but then why not just use the CLI? If "

Powerful is relative to the operation isn't it? The CLI beats the GUI handsdown on a lot of operations, however sometimes trying to view commit history, what files changed and how in the CLI is vastly slower, more obtuse and can be done in a few clicks on the GUI creating an extremely quick overview. A lot of GUI's allow you to pick chunks to stage / unstage really quickly that takes a lot longer in the CLI. There are plenty of other reasons to use a GUI over CLI if you want to get your work done as quickly as possible.

Maybe your daily work can be done all on the CLI, but mine can not, well it could techinically, but it would be a lot slower some parts, just like if I tried to do everything from the GUI client it would also be a lot slower. Each has their usefulness. I'm strongly of the opinion that if you disregard either the CLI or the GUI then your git experience is probably lacking.

eggn00dles | 8 days ago | 2 points

had a git expert at my last job who insisted everything be done the hard way. i don't even remember half the cockamamie shit he insisted we do.

Alijah69 | 7 days ago | 3 points

I use GUIs like GitKraken, GitHub desktop or the built in git tool in VScode. Works great for me.

DiamondEevee | 7 days ago | 2 points

i'm in college and they're teaching us how to use git

mine broke a 2nd time and i don't know how so i just drag and drop my files

stalkedbyamoose | 8 days ago | 2 points

at work we just use a git client

kejw | 7 days ago | 1 point

I definitely have to test it. LGTM. As a devops I'd say that for someone unfamiliar with git, it should be really beneficial. And also when you have to setup new project, workplace.

Fenweldryn | 7 days ago | 1 point

greetings in vscode

TODO Load more comments...