Think Odin project has a few links to git education

http://www.theodinproject.com/web-de...101/git-basics

One from codecademy

https://www.codecademy.com/blog/74-g...arted-with-git

Is there anything an average joe developer really needs to learn to do in Git besides commit, fetch, pull, push, squash, merge and rebase? Thats pretty much all I have ever done aside from a sporadic cherry pick or some other command I could google in 10 seconds

You don't believe I work in a restaurant?

Not really looking for advice. More or less venting and stating facts. Clearly, something is going on and I don't have the wherewithal to figure it out. It isn't git, lol.

I was pretty floored by the last rejection. I mean, this job was a copy / paste of my work, both real and volunteer, using Python, PL/pgSQL, and Linux command line, all of what I can do and think my projects prove it. The recruiter said "Contact me any time you need advice on your next job you are applying for." Ugh, really?

If I believed in the "universe is sending a message" lard... in either case, it is time to move onto other stuff, but keep programming as a hobby. Not worth the stress. I don't need the money or whatever else I'd gain.

Don't forget 'checkout' but yep, I don't really use much else.

This list plus checkout and branch and the average developer should be pretty well covered. Maybe format-patch.

It's not really about the commands. It's more do you understand the model behind how Git works. If so, everything is pretty straightforward and answerable from SO. If not, you can spend half a day trying to figure or how to create a clean pull request.

Edit: This is more often a problem with olds that are first using Git after using something like svn for years.

The git book is great: http://www.git-scm.com/book/en/v2

The "shock" isn't about do I know how to use git. It was more about using git on a team of 20 developers, which of course I wouldn't know how to do. That should have been self-evident, I thought. It is hard to remember sometimes that smart people can be stupid too.

It's kind of silly to talk about 'knowing' how to use Git on a team anyway. It's not like there one right way. And some of the worst meetings I've ever been in have had to do with branching/tagging strategies. Should master always be what's live on production might be as horrible a question as is vim better than emacs.

Edit: even though yes is obviously the right answer to both.

I think it's funny to mention git in an interview or job description when you can learn the basics in an hour or two.

I've had git questions thrown at me just about every time. Usually something like "do you know what git is?" or "list some git commands." Once in a blue moon, I would have to describe a specific git command.

blame? Well, I sort of know who's fault it is every time... http://git-scm.com/docs/git-blame

It does seem like a weird interview question. Do you have Git on your resume?

Edit: maybe it makes more sense when interviewing for a junior position? Still seems kind of silly.

I don't have git on my resume. Probably a good that I don't if that would bump the response rate up another 2 points.

wouldn't junior applicants be less likely to have collaborated?

The only times we've really gotten into big messes with git was after a rebase by a developer who didn't know what they were doing. I say avoid rebase on big teams/projects unless you're a git master. Not worth it. We're always going to have new devs who don't know what they're doing.

Our team makes us do rebases for "prettier history". Confirmed suck

Reflog. It has saved my butt a few times from my own stupidity

We have so many individual commits, I never parse through them anyway. We just make a new release branch every time we push to production - then use pull requests to compare that to other release, dev or feature branches.

Git bisect is incredible if you ever get a weird bug and you don't know when it was introduced. Here's how to use it from our docs:

+1 to not rebasing and using pull requests to view grouped commits.

I think most junior applicants should still have used source control. And if they've listed it on their resume its an easy thing to ask about and get a sense of how truthful they are being with things they've listed on their resume.

Asking a Git question to someone that doesn't have it on their resume seems just plain stupid. Unless you're GitHub or something.

I just use no ff merges and then amend the commit to something that describes the feature instead of "merged branch". Rebase defeats the purpose of SC imo.

Yea gits not that hard. You just have to learn as you go. Though I did remember spending a couple of hours or so trying to figure out how to git rebase interactively. The biggest pain are knowing what to do with merge conflicts, those can get a little scary if you don't know what you are doing. But I just use git mergetool and it's pretty easy to resolve .

Maybe you should try an experiment and replace Clojure with Java on your CV. I think having Clojure on the CV may lead to some crazy selection bias effects of people on the other side expecting some wunderkind ninjahacker.

No I wasn't sure if you were saying you're obviously not fat and unacceptable in public, with the proof in the pudding of you being able to hold down a front-of-house restaurant job. Or if you were saying you are super awkward and unacceptable in public.

Regarding software archiving systems, I've pretty much used all of the most popular ones except Visual Source Save or whatever it is called. Microsoft doesn't use it to archive their production code either btw. Asking specifically about a particular tool for archiving seems kind of silly to me. Git is easier to use than something like ClearCase for instance but an organization could implement its development process on either one.

Visual Studio has an easy to use Git interface that if you don't want to use the command line that will work well. Either way specific questions about Git commands would be silly. Large organizations tend to have build teams dedicated to building and archiving production software that provide "cookie cutter" instructions for developers.

@Dave -Yeah I think I would have to be local first to significantly improve my prospects. Maybe in a year or so I will do that.