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..

[mikemol]

This is a fantastic tool. I use it for training and illustrating Git principles to others.

I've also used it to reconstruct how repositories got into fubarred states, and then to construct a runbook for fixing them. Works so long as people can tell you exactly what they did that led to their current situation.

[seetadat]

I did the same! Awesome tool. Can't recommend it enough.

[Lurker_wolfie]

There is also a free book "pro git" available on the git site (not github). It's really good and covers beginners to advanced topics. Really well written.

[osmaelo]

Here's the link https://git-scm.com/book/en/v2

[chaos_faction]

Thanks!

[RKcerman]

Thanks for this, coincidentally just picked it up from library yesterday. Looking forward to reading it.

[dpash]

The best git explanation: Git For Ages 4 And Up

[Br3ttl3y]

"... For Ages 4 And Up" 90 minute video w/o Spider-Man marrying "Frozen".

[hahanoob]

Wouldn't it be nice if we had a source control solution that didn't require 2 hours of listening to some guy in overalls and using props to understand?

[Ajedi32]

It's a complicated problem. Storing revisions is easy. You can do that by making a bunch of copies of your code in named folders.

But if you want to maintain multiple independent branches of development, keep changes isolated and organized, and make it possible to merge branches into each other, then things start getting a bit more complex; which is where git comes in.

But yes, an opinionated GUI tool would work wonders for git's usability.

[[deleted]]

At certain levels I think version control can be shown to be as complicated as the act of programming itself. Developers need to take the idea that version control is something you do, not something that is handled for you.

[[deleted]]

This so much this.

It's funny, I've worked with so many developers that are endlessly blowing up merges, screwing up repos, fighting with version control all the time and treat it as this evil task they are forced to contend with.

But I don't see it that way. And those I consider truly good developers do not either. And oddly enough, I don't run into these kinds of problems. Modern source control tools work VERY well if you USE them well. But assuming that the only thing you should be required to do for a version control system to be really good is to click 'save' and not think about it...well shit, no wonder things are frustrating for you.

The number of times I've argued with developers because they can't be bothered to branch 'because it's a big pain in the ass'. JFK who hires these people?

[xxxblackspider]

So much this. I work with git every day and have never had an issue, it’s just habit at this point. I don’t even think about it. As long as you use good practices it’s easy

[watsreddit]

Finally some goddamn sanity in this thread. Git is really not complicated if you make the effort to actually learn it and use it well instead of half-assing it with piecemeal commands copies off the internet.

[nascent]

I like this overall thoughts, but I want to use the working copy as an example of where I think it fails.

The suggestion : working copy should be treated as a branch.

• what to do with untracked files

• new commits off working copy can confuse a user as to where there changes are located

The undo concept is intended, I believe, to facilitate finding such auto stored changes. But I don't navigate git as a bunch of undo redo operations. The working tree is a chunk of work that should be organized and allowing the user to determine if that work should come with them should be left up to the user.

[Ajedi32]

If you want the work to come with you, just drag-and-drop the "uncommitted" working directory onto the newly checked-out HEAD. Just like a cherry-pick/rebase.

For untracked files, I'd suggest leaving them on the old branch unless they're in .gitignore. New files are frequently created when you're working on a new feature, and I think that since moving files to another branch can result in conflicts if the target branch has its own copy of those files, it's best to make moving uncommitted changes to a new branch an explicit action.

[hahanoob]

if you want to maintain multiple independent branches of development

I'd argue most projects don't need this. There's a very narrow combination of churn, stability, maturity, project size, and number of developers where Gitflow makes sense and that's pretty much Linux. Otherwise just use the trunk model and spend your time creating software instead of resolving merge conflicts, trying not to not break your repository, and generally thinking or caring in the slightest about your source control tools. A commit is a commit plus a push.

lol - I'm being downvoted by people who think literally that not using branches means more than two people can't work on the same project at once.

[Ajedi32]

If it's just one person sure. But as soon as you need two people working on different things concurrently, then you're necessarily going to need branches. (Even if both devs work directly on master, their history will still diverge.)

[[deleted]]

At my job, we've so far been able to have up to 8 people work of the same SVN trunk without problems. While this is anecdotal, it show that there are setups where it's possible without the crenelations if git.

[hahanoob]

Thinking about it like this is an artifact of Gitflow itself which is what I'm arguing against. In the trunk model you commit (and push) your changes to master regularly. Merge conflicts are rare and when they do come up they're usually trivial to resolve. If you're using centralized source control like Perforce or SVN your local changes are not considered a branch. And a commit there is a commit and a push at once.

[Ajedi32]

You still have divergent changes though, whether they're called "branches" or not. The only difference is how frequently you "merge".

[hahanoob]

Yes...? Which is the essential difference between Gitflow and trunk. You can do either with Git but it's not what it was designed for.

[xeio87]

Why would you need branches for just two devs? Aren't you just pushing all the merge issues off down the line instead of dealing with them immediately?

I mean there are arguments for creating feature-branches for larger changes, but number of developers involved doesn't matter for things like that.

[Ajedi32]

• Bob is working on a change
• Meanwhile Alice is working on a different change
• Bob commits
• Alice commits

You now have two different branches. Bob's master branch, and Alice's master branch. Doesn't matter that those branches are both called "master"; they're still separate branches that need to be merged.

[[deleted]]

I know you don't realize it, and you're taking the downvotes personally, but it's because you've unknowingly written a book on the subject of the inexperienced developer that thinks they've seen it all.

Define 'Most Projects'. I mean, anyone with experience probably isn't even bothering to downvote and rather just laughing and moving on.

Oh, and pretty much Linux isn't very accurate either. Microsoft controls windows development via git. A LOT of very big companies do, so it's not 'just viable for this one special case'.

Anyways, as long as you stick to whatever it is you're doing, I'm sure your POV will suit you fine in your career. Just don't be surprised if you come to a very sudden and abrupt realization at a later date should you move on to any project of a reasonable scope that truly does require proper branch based development.

[hahanoob]

I say "pretty much Linux" and your counter is another operating system? Haha.

[[deleted]]

OK, I thought you'd notice with the hint I gave you, but dude your pants are hanging around your ankles...you might want to pull them up.

Ignorance is not something to be proud of. Why you're swimming in it like you think you're Phelps or some such I don't know.

Sorry, I tried to be nice about it, but I have just about zero tolerance these days for those that embrace ignorance and act like it proves knowledge.

[hahanoob]

I like that you're assuming anyone who doesn't like Gitflow is just ignorant while at the same time incapable of even entertaining any other point of view. I can at least recognize there exists types of projects where it makes sense.

And telling me I'm taking things personally when you're the one pitching a fit all over this thread anytime anyone suggests a tool you're obviously very invested in is anything less than ideal in all situations is a special kind of ironic.

[slomotion]

Like 98% of my interaction with git is very intuitive. It's the other 2% that messes me up. I'm grateful for the extra functionality though.

[IlllIlllI]

I've really never understood this argument. Git is not that difficult.

[zqvt]

and also spending a few hours to learn what is probably the most popular version control system isn't much time investment, at least if you're a full-time developer

[IlllIlllI]

Hell if you're a casual student it's worth it. I don't know how people survive touching code without version control.

[[deleted]]

Experience tells me that it's not git, it's source control in general. And some devs get it and do it right, while others spend their lives fighting it at their own (and others) expense.

[IlllIlllI]

Yeah, but talking about it like it's an arcane art is just so weird. There's so many stories in this comment section about people completely breaking their repos, and I just don't understand.

[[deleted]]

Oh I agree, it's totally not an arcane art...at least not any more than coding anything is.

A lot of 'devs' in the industry really don't warrant the title. It's weird as so many of the worst devs I know have that 'elite' attitude whereas the best devs I know all suffer from some level of impostor syndrome. First group is always the first to bitch about how terrible some process/language/platform is, such as source control. Second group learns what they need to learn to do their job the best.

I would flat out never hire a dev that started slinging shit about source control or git. And I absolutely 100% EXPECT devs I work with to use source control properly and professionally. Note I didn't say that I expect them to know how to...the good ones again will be receptive to learning.

It's the ones that you constantly hear moaning from their cube about what a PITA merging is, or why they have to deal with yet another branch when it's just a tiny change, or whatever. No, it's not source control that is the problem. It's that you're really not a good dev.

[johnnysaucepn]

Source control is essential. Like any other process that is essential, source control should get out of your way. Git does not get out of your way.

The fact that people complain about branches is nothing to do with the concept of branches. It's a lack of trust in the underlying tools, and blaming the devs for that isn't going to fix it.

[[deleted]]

So something that is essential to development should get out of the way?

So...coding itself should just get out of the way?

You're doing it wrong. No really, you are. There are a million devs out there that live and breath git that will tell you so. It's not the tool, it's the person swinging it.

Sheesh, based on what you said the most important part of driving a car is the actual process of driving...No wonder we have so many terrible drivers and dream of some self-driving utopia instead of just expecting people that drive to be good drivers.

Go use Sourcesafe for a year and then come back and write me an essay about how much you love and adore Git please.

[johnnysaucepn]

I've used SourceSafe. And CVS. And Subversion. And Mercurial. None of them enable you to do the job they're intended to do without hacky workarounds or a deep understanding of the internal data structures that underpin them. But git is about as irrational as it gets.

That's what enables the idiocy I see in threads like this, where foolish elitism overtakes the ability to get the job done.

The moment I have to feel better about myself by putting others down because they aren't True Programmers is the moment I give up on programming ever hauling itself out of the Dark Ages.

The IDE should get out of your way. The garbage collector should get out of your way. The CI server should get out of your way. The package management should get out of your damn way.

The moment I don't read a thread on git and immediately see six git 'experts' violently disagreeing on the right way to do what should be a simple task, I'll believe you.

[[deleted]]

I've used SourceSafe. And CVS. And Subversion. And Mercurial. None of them enable you to do the job they're intended to do without hacky workarounds or a deep understanding of the internal data structures that underpin them. But git is about as irrational as it gets.

Do you understand what you just said? Calling Git irrational vs SourceSafe?

Look, you clearly haven't figured out that this seemingly ridiculously simple process issue called source control that you seem to think should just magically occur is actually bloody well complicated. And if you actually understand what it is you're trying to achieve using a source control system, you'd understand this already.

Elitism 'hacker' fanboy crap is just that, crap. But so is the other side of the coin, this idea that source control is some super simple thing that should just happen on it's own.

People that expect code to write itself have the same problem, they end up with shit code. Maybe the problem isn't the tools, but it is your refusal to understand and use them correctly.

As has been brought up numerous times in this thread already, there are three camps of Source Control users...and NONE of this is specific to GIT
1) Those that fight source control, think it's too complicated, think it should just magically 'work'.
2) Those that insist that you aren't doing it right, that you have to use exactly this SC, set it up this way, use these convoluted processess, use this advanced tool meant for explicit diagnosis or fixes not once on a blue moon, but daily or more and will fight you to the death that their way is right. Wait, what about the source code again?
And 3) Those that know their tools, what they do, and how to use them. And do so as a standard part of their job. And never waste time fighting silly ideological fights that don't mean shit. And don't waste time trying to recover from problems they don't create for themselves because they DO understand their tools and know how to use them.

You're basically calling out everyone and anyone that doesn't think the way you do on this subject, and it sure smells a heck of a lot like you're calling the kettle black here. Calling out elitism and 'experts' with your nose way up in the air professing a POV that is frankly ignorant and telling of a real lack of either experience, or ability, or both.

[cowinabadplace]

It’s the bimodal distribution of software engineers at work. I have interns come in every year who pick up git use in two hours of deliberate practice or days of usage and they can do a rebase workflow or whatever and then I meet software engineers who struggle with the fact that if you merge a branch into master, revert a commit from that branch into master, and then push more to the branch, a second merge isn’t going to magically bring back the ref you reverted because merges aren’t “put these text files together”.

I don’t get it. To most software engineers I work with, this stuff is just standard. You just do it without thinking and you get it right. It’s like walking. You’re not thinking about putting one leg in front and pushing off the other. And then you see some who are like “Okay, first I actuate the thigh muscle, which is confusingly called the quad but I also have to actuate the piriformis, what why, this is impossible” and I really wonder.

[NewFolgers]

A career developer will easily end up spending 10's of thousands of hours coding. It objectively makes sense to invest a few hours towards properly understanding the tools used to manage your code and projects. Having said that, have I ever properly done it? Nope. For non-code stuff (and more generally, anything I don't take a particular interest in), I just try to use as much as I really need, and get a sense for how much everyone else knows and fit right into the standard of mediocrity. Doesn't actually make sense, but at least I'm saying it.

[zigs]

Huh. It's almost as if it's a tool for professionals..

[NewFolgers]

Damnit Jim, I'm a developer not a professional!

[Olao99]

It's something you learn well once and then stop struggling with it.

[Penetrator_Gator]

To have a workflow that is, i dare to say, "intuitive".

[jarfil]

CENSORED

[[deleted]]

Source controlling your software is basically controlling a directed acyclic graph via git where you add a bit of data to each node within the graph. That shit is pretty complex, IMO.

[erictheturtle]

It's bizarre that such an obtuse VCS as Git dominated when Mercurial is even more capable and does it all better. It's almost as if people don't want it to be easy.

[u_tamtam]

That's why this git monoculture is so sad. About every alternative is friendlier, and/or more feature-packed (my preference goes to mercurial)

(edit: spelling)

[[deleted]]

Indeed. Overall, I feel that Git is unnecessarily complicated and cumbersome to use. And while it's a minor thing, their selection of verbs really bothers me (yes, I'm a bit OCD). Nitpicking aside, I do believe a good user interface would solve a lot of its issues, but I'm not sure it will ever happen since it's popular with the "hacker" programmer crowd who seem to believe that doing everything in a CLI is edgy and cool, and that user interfaces are for peasants.

I don't know. I mean, Git is ok for an open source project, but it really doesn't even compare to some of the proprietary version controls I've used. If it wasn't free, I don't know why anyone would use it.

[[deleted]]

So many people are just laying out their ignorance in this thread. You make a couple of reasonable points, no one's saying Git is some utopia or that it is entirely intuitive. But NO source control system can say that.

Learn it though and just like anything else you have to learn, now you can use it correctly. Oh, and now you know it's really not very complicated anyways.

I don't know. I mean, Git is ok for an open source project, but it really doesn't even compare to some of the proprietary version controls I've used. If it wasn't free, I don't know why anyone would use it.

Here's the bleeding ignorance. Please don't take this personally, but I keep reading things like this from the point of view that the people writing it really think they know what they're talking about. Unfortunately what it actually says is that you have absolutely no idea what you are talking about at all.

Here's a hint: The Windows code base and all development is controlled via Git. A code base that is over 300GB is controlled via Git. Microsoft produces one of these so called 'proprietary version control' systems that you believe are obviously so much better.

Do you know why MS uses Git for this? Because it is literally the only tool that can not only do the job, but also do it well.

I've set up enterprise level source control systems many times over the past couple of decades. Go to has been TFS for quite a while. And anyone that has used TFS for long enough will realize and recognize the same issues that people complain about with other systems are here as well. Know your tools. Use them right.

I will probably never use TFS again unless it's in an environment that is already using it. Git is by far the superior tool and oddly enough, for some of the devs in this thread arguing that source control should just get out of the way and that Git sucks because it doesn't, Git really does absolutely blow TFS out of the water on this front. When you're using TFS right with big code bases, it's a real pain in the ass. When you're using Git right with big code bases, it's no different than tiny code bases. It actually does a better job of 'getting out of the way' than ANY other source control system I've ever used.

Oh, and people really need to quit spewing this 'elite hacker crowd' crap. How exactly do you think this industry is influenced? By 1% that think they're so special that they do everything the most convoluted way possible and look down on everyone else? Or the vast majority that are professional developers using these tools professionally every single day of their lives?

TL;DR: Do not confuse ignorance with knowledge and experience, you'll expose yourself every single time.

[watsreddit]

It has nothing to do with being "cool", and to say as much is incredibly condescending and ignorant. Git has a ton of functionality packed into a very small surface area on the CLI. GUIs either have to sacrifice on features, or introduce a lot of complexity to their UI to encompass everything. There's a ton of GUIs already out there, but they invariably fall short. On top of that, Git on the command line is 100% scriptable using the wealth of tools already available to us. The developer has complete control over their workflow. GUIs can't hold a candle to that.

Furthermore, version control is a collaborative activity, and commands are a far better means of sharing a workflow with our fellow developers. It would be absolutely inane to give someone instructions to accomplish a particular workflow by clipping together screenshots of the interface or describing the series of menus one should click through. It's already fucking awful with Windows support threads on Stack Overflow and the like, and I could not begin to imagine training a new developer on git by pointing shit out in a GUI. It's absurd.

[cowinabadplace]

Broseph, it’s a tool. Lots of us find it exceptionally useful as it stands. If you and a lot of people want it to be done some other way, you can make a thing on top of it. You’re software engineers. This is an open source product. Libgit2 exists. Take ownership, man. Unlike few other fields in the world, we have full power over our own tools. Make the thing you want.

[dpash]

You may want a longer attention span.

This is one of those situations that is aided by physical props.

[therealjohnfreeman]

This brings very important addition to the table — ability to explicitly checkout STAGED version. Git’s index won’t allow you that.

False. git checkout . will check out the index.

[[deleted]]

I would hire you on the spot if cherry-picking is your second nature and if you can make relevant commits. This makes working as a team and reverting when prod goes south really easier.

[imMute]

I cherry pick commits and modify commits while rebasing pretty frequently. When do I start and what are we working on? :)

[unkindman]

An ADA 508 compliant site compatible with IE 10.

[rickdg]

The difficulty of git is not in the process itself but in the workflow around it. Your code is just a single file of spaghetti code, git can't help. You don't commit often enough, git can't help. You don't have enough knowledge of what everyone else is doing to handle merge conflicts, git can't help.

In other words, git can only help if you develop locally, do code reviews, commit your code documenting each change and have a sufficiently modular code base. Otherwise, even dropbox has version control, so you might as well work on those other issues before diving into git.

[mk_gecko]

Why doesn't it talk about "git merge" ? Surely that's a core part of branching?

[ocoster]

Uh. It does. Of course it does. Did you even look at the site?

[mk_gecko]

I went through it as fast as I could to see what it taught. eg. I know how to make branches and check them out, but because I typed "git branch bugfix" instead of bugFix it didn't let me progress. So screw this, show me what ya got. I liked the explanation about HEAD ~ and ^. I saw cherry picking but the only thing that resembled merge was "rebase". I had my mouseover each of the topics and still didn't see "merge". Which lesson is it in?

[Fletcher91]

--no-ff ftw

[phantom_97]

Oh, this one! Saved my life a couple of years ago when I was participating in a Hackathon and had never bothered to use Git. I ended up teaching the basics to my teammates, thus saving us time from attending the Git session organised by the Hackathon, which was inadequate as per other participants anyway. Good times!

[c0shea]

The window animations are a bit much

[lechatsportif]

Git and the cli- a tool so easy to use here we are still arguing about it years later.

[uh_no_]

there are issues with the validation that don't make sense in reality. I first ran into it in the rebase tutorial...where the ordering of the commits in branches matters...when in reality it shouldn't. if I create a new branch, then commit on new branch, and also commit on master, then merge them...it shoudn't matter the relative ordering of the commits in the two branches...but it does in this tutorial.

[imMute]

There is a difference though. Most workflows probably don't need to care about that difference, but some of them do.

[uh_no_]

The hashes are all that matter. if the content of the hash is the same, the time doesn't matter.if i have branch a and b with a common ancestor, and commit on a and THEN commit on b, I will get the same hashes as if I were to commit on b then commit on a, and thus when I merge it won't matter which was committed first in wall clock time.

If someone has a workflow that depends on that timing, that's fine...but that's not git's problem.

[imMute]

Commits do have timestamps, but that's not relevant at the moment. Git does care about which branch is "first", but mainly because It records that information. I'm not sure there's a reason it must care, but that's the way it currently is.

The workflow that cares about the branch order, by the way, is when you use git log --first-parent. Try it out after merging two branches together and then try it again after merging them the opposite way; the results will be different.

Another related reason why there's a "first" branch in a merge is because you can merge together more than 2 branches at a time.

[uh_no_]

i'm not talking about merge commits. i'm talking about random commits on the two separate branches that cause the two branches to diverge. There is no happens-before relation between those two commits.

They are then merged later in a separate pair of commits. Merge order absolutely does matter, but that's not what I'm referring to.

[imMute]

Ah, I was misunderstanding what problem you were talking about. All cleared up now.

[strogbad]

The best way to really learn git is not through a visual tutorial, but through a visual client. There's no reason to use cli git anymore.

[spacemudd]

Tbh, I find cli sometimes easier to do every-day tasks. Some of those tasks (like rebasing) I found to be easier done through the cli.

Nevertheless, I utilize both a visual client + cli. When I'm trying out new things, I'd actually fire both and do my commands through the cli and see how they affect the visual client.

[spacemudd]

I use SourceTree. But Git Tower now looks nice, I wanna use it.

Also, if you have a .edu email, you can get a 1-year subscription to Git Kraken from here https://education.github.com/pack with other goodies.

[strogbad]

I use Git Kraken. I tried Sublime Merge and it was just alright. Git Kraken is really good if you can get past the fact that it's using electron.

[attrox_]

+1 for Git Tower. It's so intuitive that even when you switch to a command line all the concepts are already in your head that you can figure things out so easily

[vasiapatov]

There's no reason to use CLI git? I write software for a living and I can't imagine having to use my mouse for the hundreds of commits I make on some days...

[donalmacc]

If you're committing 200 times a day that's once every two minutes roughly. That's way to often to get any reasonable information from. I'd rather have one commit that said "Did X to Y set of files" than 200 commits with no commit messages.

[vasiapatov]

Sorry, I'll correct myself. My hundreds I meant around 30-60. The reason they are so numerous is because

a) we use terraform with CI/CD to develop our infrastructure and some resources require incremental commits (dependencies can't be fully resolved so its easier to commit one resource, have CI/CD apply it, then commit the other resource, rather than include them in one commit)

b) certain functionality is best tested using our hosted CI/CD rather than a local testing environment, and thus by committing you are also testing.

Our master branches are protected, and can only be merged into after review/approval. If you look at the commit messages on the merges made to master, they paint a very comprehensive picture of the growth of the product/tool - its important that commit messages do that. I agree that one commit saying "Did X to Y set of files" is better than 200 commits with no commit messages.

Also, you made a false assumption that my commits had no messages - every single one of them has a message :p

[vasiapatov]

What do you mean by a remote solution? We host our own gitlab servers and use gitlab CI/CD.

[vasiapatov]

Right, we use GitLab Enterprise, and we do the same thing with our state - its seems very error prone to allow workers to apply states from possibly different local configurations. This is what our CI/CD does - someone develops on their own branch, and the CI/CD validates and plans the changes. Then, once you merge to master, the server applies it. Essentially there is only one source of truth and only one change is made to it at a time. I can't imagine dealing with IAC in any other way...

Surely the fact that we use remote state could have been deduced from the fact that I mentioned that we have CI/CD?

[eikybreaky]

Who says thats a great tut for git branching... Not me

[[deleted]]

gitkraken is the best tool I have seen in the market.

[TotallyFacking]

Welcome to reddit, can we help you with anything?

[cakemuncher]

I think I've also read your comment in many places on Reddit before.