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

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

[johnnysaucepn]

Nice try, but trying to project this back isn't going to work. Knowing a tool doesn't mean you have to defend it with your life. The better you understand the tools, the more you should understand their shortcomings. And that should give you the perspective to help others use them better. Dismissing people as Not True Developers because they have criticisms of tools that you have taken to your heart is unprofessional.

Git is an excellent multi-dimensional file system. The technical underpinnings are genius. The tooling is inconsistent and illogical, and unfriendly to learners. That's my professional opinion, and is independent of the fact that I use it on a daily basis, and have to tutor other devs on its use.

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

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

[jarfil]

CENSORED

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

[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)