Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to teach Git

rachelcarmena.github.io

Post reply on HN
Print view View original

211–220 of 273 posts

Re: How to teach Git

#211

Post by sonnyblarney »

ahartmetz wrote: post #60

And here is something to take the garbage quality of Git manpages with some humor https://git-man-page-generator.lokaltog.net/ "git-eliminate-head eliminates all downstream heads for a few forward-ported non-counted downstream indices, and you must log a few histories and run git-pioneer-object --pose-file instead. [...]"

This is funny, but in reality it's not.

Git is one of the most amazing, powerful tools ever conceived, with one of the must byzantine and ridiculously designed 'interfaces' ever conceived.

People confuse the raw power of a tech, with how well it can be feasibly used. Sadly, due to the later issues, git will only ever be a shadow of what it could have been.

With all due respect to Linus, who'd be the first to admit he's not very good at UI stuff (I mean command line as well)... it's truly a sad thing.

This is a major 'problem that needs to be solved' I'm interested to see how it could evolve into something 'better'.

Re: How to teach Git

#212

Post by [deleted] »

svat wrote: post #146
iheartpotatoes wrote: post #106

This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)

My recommendations: * Git From the Bottom Up: https://jwiegley.github.io/git-from-the-bottom-up/ (PDF: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf ) (See also: "Linus Torvalds' greatest invention": http://perl.plover.com/yak/git/ ) Once your mental model matches the program, you'll be able to understand everything, hack your own solutions if necessary, etc. * Learn Git Branching: https://learngitbranching.j…

[deleted]

Re: How to teach Git

#213

Post by miccah »

Ajedi32 wrote: post #47
cyborgx7 wrote: post #19

Here is my personal recommendation for getting more comfortable with git. Use "git status" a lot. Everytime you do something in git, and before you do something, do a "git status" and see what you change with your commands. And what you didn't change. Also "git log".

`git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.

Zsh users can use glgga to get a nice full detailed graph log as well. It's not as concise as the custom config, but I use it quite often.

Re: How to teach Git

#214

Post by pjmlp »

spurgu wrote: post #184
pjmlp wrote: post #25

Earlier quoted context omitted.

Which happens to be the only option on future car driving technologies.

Not sure whether your statement is ignorant or insightful. Yes, once electric cars (with superior traction and brake control) take over automatic gearboxes (actually electrics don't even have gearboxes) will be the norm, but as long as there are engines driven on dinosaur fuel there will be a need for manual gearboxes. Which is why you should learn how to drive one. Once you're able to do that, driving an automatic i…

I mentioned future, naturally I drive manual today.

The point being that what is right to learn today won't stay like that forever.

Only people that maintain old timers still know how to use a motor starter.

Re: How to teach Git

#215

Post by dave7 »

dahart wrote: post #202
spurgu wrote: post #184

Earlier quoted context omitted.

Not sure whether your statement is ignorant or insightful. Yes, once electric cars (with superior traction and brake control) take over automatic gearboxes (actually electrics don't even have gearboxes) will be the norm, but as long as there are engines driven on dinosaur fuel there will be a need for manual gearboxes. Which is why you should learn how to drive one. Once you're able to do that, driving an automatic i…

> Not sure whether your statement is ignorant or insightful I’ll answer that for you. It’s insightful. In the U.S. today, less than 2% of new cars sold are manual now. Automatic gearboxes are well beyond the norm already. https://www.chicagotribune.com/classified/automotive/sc-auto... I didn’t understand why you said there will always need to be manuals for vehicles that run on gas... what do you mean?

> In the U.S. today, less than 2% of new cars sold are manual now. Automatic gearboxes are well beyond the norm already.

At that percentage, the U.S. is a huge outlier however, and accounts for quite some chunk of of worldwide automatic gearbox equipped vehicle production on it's own.

The automatic gearbox remains the less popular option worldwide [1], though as you can see they are more popular than they were before.

[1] https://www.statista.com/statistics/204123/transmission-type...

Re: How to teach Git

#216

Post by yyx »

jen729w wrote: post #196
wickchuck wrote: post #127

Earlier quoted context omitted.

SublimeMerge is also a wonderful tool. Been using that since it came out and has helped tremendously with difficult merges. It's lightning quick as well. Similar to magit - Sublime Text also has SublimeGit, not as fast as SublimeMerge. Visual Studio Code built in git functionality is also nice.

A mention for Tower. I only do the basics but it totally took away my Git fear. https://www.git-tower.com/mac

gitKraken is nice too

https://www.gitkraken.com/

Re: How to teach Git

#217

Post by Derbasti »

I have taught git for university classes for some years. To be honest, git is a mess. It is conceptually not that hard, but the nomenclature is inconsistent and dangerously ambiguous (quick, what is the difference between reset, rebase, revert, and checkout?).

The most effective work flow I have found so far, is teaching only status/clone/pull/add/commit/push. Show them explicitly what happens normally, what happens when two changes conflict, and how to resolve merge conflicts. Using git on the command line only.

Then, have the students use git for a big-ish multi-student project. They will figure out the workflow themselves. After that project, once they understand the basics, you can talk about branches, debasing, the log and reflog, pull requests, and all the rest. Don't introduce graphical front ends before this point.

This method works well. It takes about one hour of teaching, and five weeks of active use afterwards. Git is a total pain to learn, and can only be understood by actively using it. I often get very positive feedback for having taught git.

I have gone through a few iterations with this topic, and have found that stripping down the initial instructions to an absolute minimum works best. All those fancy box diagrams are actively harmful to beginners.

Re: How to teach Git

#218

Post by diegoperini »

rachelmcarmena wrote: post #176
diegoperini wrote: post #3

An honest criticism: If I had trouble with understanding the reason behind add->commit->push workflow, I would definitely have no idea what this article talks about when it says things like "merge, rebase, diamond shape". The flow chart looks almost exactly the same for "pull" and "pull --rebase". The only difference between the charts is the wording which has no meaning at all for a newbie.

Thanks for the feedback! Right, this is only a help to have a mental map. Only some initial drawings for a mentor or trainer, not for the newbie.

If so, I'd love to see a more elaborate, guide-like version of this model.

I've tried a similar approach years ago for teaching and failed spectacularly. Eventually, my peers became comfortable when they got used to the Github Desktop Client. They compared the buttons they click with my terminal commands. We also compared our graph views on Github website to visualize the logic.

It's been years and still none of them used rebase even a single time. A sad story in my teaching non-career. :(

Re: How to teach Git

#219

Post by IshKebab »

Ajedi32 wrote: post #47
cyborgx7 wrote: post #19

Here is my personal recommendation for getting more comfortable with git. Use "git status" a lot. Everytime you do something in git, and before you do something, do a "git status" and see what you change with your commands. And what you didn't change. Also "git log".

`git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.

Classic git CLI. The option everyone wants is behind 5 optional flags.

Re: How to teach Git

#220

Post by IshKebab »

iheartpotatoes wrote: post #106

This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)

Use a GUI. Git repos are graphs and trying to understand a graph from the command line is like trying to paint over the phone.

I recommend GitX (FOSS, Mac only, a little buggy but has the most logical UI and let's you easily amend commits), SourceTree (free, quite slow, Windows/Mac), Tower (paid, cross platform) or SublimeMerge (paid, easily the fastest, cross platform).

Post reply on HN