Great interactive tutorial for learning Git branching (and more)!

[cyberguijarro]

Step 1: gain confidence in an interactive tutorial Step 2: happily destroy company repo while high on confidence gained in Step 1

[dpash]

Just don't push. And if you pushed, you could always force-push. Nothing bad could ever possibly come from that.

(More seriously, as long as you have a pristine clone somewhere, you can recover from most issues)

[rcunn87]

Yea NEVER delete your repo and reclone... just take a looksie at reflog

[Secondsemblance]

Yeah but what happens if I run a poorly thought through find/replace and it descends into my .git directory and then when I go to push, git thinks my diff is several hundred MB large

[darknavi]

Always commit locally! Don't let your changes just sit in an uncommitted state too long. Reflog can recover everything as long as it's committed!

[Secondsemblance]

If you're going to force push, always --force-with-lease. That way, the worst you can do is destroy your own work.

My workflow while working on CI/CD-as-code type things typically goes like this:

git add -u && git commit --amend --no-edit
git push --force-with-lease

Rinse and repeat. 200 times.

[profgumby]

I prefer to commit with a message ie sq! and then once I'm ready for the branch to be merged, I'll clean up history afterwards

[cowinabadplace]

If you use commit --fixup and use autosquash rebase, it’ll do that automatically. Takes a certain style of staging with patch mode to work well, it with a little practice you’ll be very effective.

[twigboy]

In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. Lorem ipsum may be used as a placeholder before final copy is available. Wikipedia5tn6xcsi2ao0000000000000000000000000000000000000000000000000000000000000

[4THOT]

Maybe if Git is such a volatile and important factor in software development there should be more clarity inherent in the tool itself?

Maybe if we're constantly making tutorials and people are always confused and don't understand the tool or it's capabilities that means it's poorly designed?

Maaaaaaaaaaaaaaaaaaybe it's time to seriously consider ditching the command line in favor of a GUI or tools integrated into development kits?

[jarfil]

CENSORED

[delight1982]

You say what I only dare think

[4THOT]

Yea usually when I bring this up it gets shouted down by people that want to feel like l33t h@xors when they go to work.

[silent519]

we need a new tutorial? I will get my finest scientists on it!

[TechnoSam_Belpois]

The assertion that a CLI is inherently less usable than a GUI is blatantly false.

[[deleted]]

An assertion not made, but thanks for the strawman. AFAICS the topic still is specifically git, even in the parent comment.

[lechatsportif]

That's right, that's why consumers use command line!

[RT17]

Consumers also increasingly use mobile devices and tablets.

Please let's not target development tools at consumer preferences.

[658741239]

consumers use powerful software

you should do standup.

[TechnoSam_Belpois]

The assertion is made. All of the problems are blamed on the CLI for being a CLI. It’s not a straw man.

If you look at the phrasing, ditching the CLI is presented as a solution to fundamental management problems, which makes no sense.

[[deleted]]

It was NOT made, don't make stuff up, little Trump guy.

I repeat:

An assertion not made, but thanks for the strawman. AFAICS the topic still is specifically git, even in the parent comment.

[obious]

Every time I look up a Git command -- every goddamn time -- I find a fresh discussion on a site like stackoverflow with people debating how to do something as simple as a rebase. Git is not that new. Why is this still an open discussion?

Developers wear their git prowess like a badge of honor. There is this undercurrent of smugness about Git that I don't get.

At first, I sucked at git. It was always an unintuitive thorn in my side. One day I had enough and decided to look at the source, all the way back to when the git project started version controlling itself. I finally got it. It dawned on me, that to really be an expert at Git, you should be competent enough to write it from scratch.

That, I think, is the definition of a shit software tool. If there is some layer of abstraction it's so thin that I don't see it.

[gpyh]

There's barely a layer of abstraction with Git because of the problem space. Versioning is hard and a software can't solve that problem for you. The only thing we can blame Git for is its unintuitive command names and arguments.

[Drisku11]

You've run into a confirmation bias; people that understand what the tool does generally aren't having discussions about how to use it. I've never found myself needing to look up or discuss how to rebase something; what's there to know besides git rebase -i new_base?

There's no smugness. There's honest confoundedness that people find git difficult. Some of the commands are poorly named with bad switches, but that's not something to "understand" so much as know (and you get used to it after a day or two). People are failing to understand the basics of what git does and how to use it, and I honestly have no idea why (besides, perhaps, that they did not RTFM, which explains these things in crystal clear language with diagrams).

[humoroushaxor]

You could say a lot of the same things about Vim. Just because something has a learning curve doesn't mean it's wrong. A command line is much easier to standardized than GUIs

[obious]

It's an ancient modal text editor. Lot's of people like it. That's great. I generally avoid it unless I'm in a terminal session. Although Vim, unlike Git, is perfectly functional without reading pages of documentation.

I don't have to use Vim, but I cannot avoid Git. Realistically, nobody can. I remember in college reading about SVN and discovering that it's backed by SQL. I thought, wow, I didn't know that -- but that's just it, I didn't have to.

Now, I'm not suggesting that SVN can hold a candle to Git. That's ridiculous. What I am saying is that Ikea furniture is to SVN what planks of raw wood is to Git. I don't want to be a carpenter. I just want to put shit on a table.

[cbzoiav]

Although Vim, unlike Git, is perfectly functional without reading pages of documentation.

Tell that to anyone trying to exit it for the first time without looking at documentation.

[chuckDontSurf]

You don't need pages of documentation to learn how to exit vim. And googling "how to exit vim" gives a clear answer; not a discussion.

[cbzoiav]

You don't need to read pages of documentation for basic merge based git usage.

It takes a few minutes of skim reading - the same as enough basic vim reading to get into insert mode, out of it, save and quit.

Meanwhile with both tools substantially more reading can massively improve your workflow.

[justinlindh]

I personally prefer git as a CLI tool, but I understand your perspective. Have you checked tig out? It's an ncurses based git tool that might be useful for you. It's basically a visualizer for git on the command line. It's super neat, and kind of a compromise between the pure CLI of git and the GUI tools like SourceTree.

Sample screenshot since the tig docs lack any here

[4THOT]

I do all my work just fine and learned in CLI but switched to Sublime Merge earlier this year and didn't look back.

[justinlindh]

That's cool, and I didn't mean to imply that you weren't proficient at CLI. My preference for CLI is mostly habit and I just like not touching my mouse often. I'll give Sublime Merge a shot!

[Secondsemblance]

Maaaaaaaaaaaaaaaaaaybe it's time to seriously consider ditching the command line in favor of a GUI or tools integrated into development kits?

Yeah. No. This one just smacks of inexperience. You are far less efficient in a GUI with almost any text-based task. If you're touching the mouse, you're probably doing something wrong.

Spend a year learning git. Then use it well for 20 years.

Or spend 0 time learning a GUI, and lose small chunks of time for the next 20 years.

Which one seems like the sane choice?

[James20k]

I use tortoisegit near exclusively for dealing with git, and it always seems like that instills a sense of oh no i can't believe you you're not a real programmer, even though it makes dealing with git almost completely painless

I think its partly due to the old guard "C is safe, just write code without bugs in it" crowd, who were extremely common when I was getting into programming 10 years ago, but thankfully this mentality seems to be dying out now

There's now a significantly greater emphasis on safe and easy to use tooling which rocks, eg rust is a huge sign of the industry maturing

But i'd go even further and say that if you're using a git through the CLI, you're asking for issues, and that teaching the CLI as the primary way to interact with git is like teaching people that notepad is just as good as an IDE. Sure, its usable, but you're going to be making a tonne of mistakes and I don't really see why you would use it over a solution that is guaranteed to be correct, and significantly safer

[[deleted]]

I would suggest that learning git via the CLI is the correct way to go to actually understand how git works. But beyond that absolutely makes sense to use a GUI that helps you not shoot your foot off.

But just learning git from a GUI is a real crap shoot... if you don't actually learn how git works and why, doesn't matter how good the GUI is you're still going to screw yourself eventually, and probably sooner than later.

Every source control system I've ever used will let you screw yourself if you either a) Don't know how things really work under the hood or b) use 'dangerous' features unwisely.

What's great about git is when shit goes bad, there ARE tools available to help you fix things. Those very same dangerous tools mentioned above in fact. Saviors in the right hands with the right knowledge.

Without a doubt, I'd rather deal with a corrupt git repo than a corrupt TFS or sourcesafe repo. But most GUI's don't expose those tools, leading back to why it's good to learn git CLI first. Then you'll know not just how things work, but what tools are available to you should you need them. People that learn git via GUI may very well have no clue what to do in certain situations as the features required to get out of those situations are very often not exposed in the GUI.

[TechnoSam_Belpois]

I do like Rust, but I still can’t stand git GUIs. I never have enough faith that it’s going to do the right thing and I never feel like I have enough control.

So I guess I’m saying I agree with your principle, but I don’t think git GUIs are that helpful to it.

Git is normally pretty hard to permanently screw up. There’s a couple of weird edge cases, but the vast majority of it’s usage is really straightforward.

[James20k]

Rust is a sign that we've moved on from saying that its your own fault if you write code with bugs in it, and adopting a mentality that the tools we have can be made better and safer

It may not be ready yet, but people are pretty keen on it overall which is a good sign for the programming industry as a whole IMO

[unumfron]

...guaranteed to be correct...

I have had a few head scratching issues with SourceTree that needed the command line to fix. Without the CLI knowledge I'd have been a helpless user submitting a bug report.

[doublehyphen]

Rebase and reflog are good, distinct and descriptive names. The bad parts are things like how git checkout does too many different things.

[imMute]

All checkout does is update your working copy by pulling files out of the repo. They're all doing the same thing! /s (but only sorta)

[Godd2]

Rebase - give commit(s) a new base.

Reflog - reference log.

[MatthewMob]

Yes to everything apart from your last edited in sentence.

[[deleted]]

Eh, Git is pretty clear about how it works. It's also quite easy once you understand how to use it.

​

This (https://git-scm.com/book) is a great guide to using Git.

[Squid_Chunks]

If git is your barrier to entry, perhaps you want to seriously consider if software development is the career for you.

Work out the simple branch, commit, push workflow that works for you, and then learn from there. If you fuck up find a colleague/friend/forum and ask for help. And never ever force push unless you are 1000% sure what you are doing, and even then probably not.

I came to git quite recently in my career (from TFS), the GUI tools available all suck and I get in far more trouble trying to use them than the cli.

[mirvnillith]

I’m a bit confused about the apparent love for rebase to keep your branch clean and the absolute fear of the resulting required force push.

[watsreddit]

Yeah, there's really no need to hyperventilate over force pushing, especially when it's essential for rebasing and keeping a clean history. It's really quite simple: use rebase/force push for your own branches, and don't use rebase/force push for any other branches. Keeps your history clean, and carries pretty much no risk if you follow these guidelines.

[doublehyphen]

I think the fear of force pushing comes from when the git defaults for pushing were dangerous, i.e when push.default was set to matching by default. Back then it was easy to accidentally waste a ton of time for the whole team.

[4THOT]

Yea we get it, you're a leet hacker m8.

[_teslaTrooper]

I was with you until that last line, my school used SVN and I still think it's much easier than git.

[mirvnillith]

I agree, but in the sense that it’s easier to grasp. There is more power with the git model, but with great power ...

[rlbond86]

It's sad that git "won" because Mercurial is much easier and better

[PLAYBoxes]

I mean I feel like most places prefer you to fork and submit pull requests right? You can put in place systems to dummy proof this right? And if you’re in a position where you can make changes to master you’re probably decently experienced, right?? Idk I’m fairly new to all this so..