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

71–80 of 273 posts

Re: How to teach Git

#71

Post by url00 »

detaro wrote: post #55
Double_a_92 wrote: post #34

Earlier quoted context omitted.

But why is it an extra step? It's basically just a "longterm" selection of what you want to commit.

Because you not always want to put everything in the box (and if you do, there's a shortcut to do it), and "git commit file1 folder/folder/ * .cpp folder/folder/ * .h ..." for a complex set would be annoying and require you to mentally keep track of it from the beginning. Many beginners will start by always doing "git commit -a" and that's fine, as long as they know there's an alternative once they need it.

But why is the exceptional case the default?

Surely, most of the time when you go to commit, it's all the files you've changed?

Re: How to teach Git

#72

Post by max23_ »

navinsylvester wrote: post #52

No one is appreciating the effort and a different take here. Let me congratulate the author on job well done. There are people who love illustrated explanation and for those these are perfect. This is just meant as a template which others can use to build the illustrated material and in no way a comprehensive git tutorial.

Agree, I think this is sort of like a very simple introductory on what git is about and to me it does the job.

Re: How to teach Git

#73

Post by philbarr »

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

That's fantastic!

Re: How to teach Git

#74

Post by dahart »

meuk wrote: post #5

Personally, I think using git from the commandline is too complicated for the purpose it serves in most companies. Using a git GUI works quite well for people inexperienced with git.

> Using a git GUI works quite well for people inexperienced with git.

I agree, and I wish there was a really good git GUI that either abstracted git nicely, or was as powerful as the CLI, or both. I’ve tried many of them, in production, and there aren’t any that give you a UI for everything git can do.

The problem I’ve noticed is that people raised on the GUI often don’t understand how to get out of trouble once they have a serious problem. Also the GUI tends to be a crutch that prevents them from learning the CLI well.

Git is natively a CLI and it really shows once you know both. Git’s CLI interface is awkward and hard to learn, and all the GUIs for git are somewhat awkward, both due to git being awkward, and also because trying to fit UI workflow onto CLI commands introduces awkwardness. All git GUIs are incomplete interfaces to git, there are none that give you access to all of git... specifically things like finding lost data and managing repos is something you’ll need to drop to the CLI for.

Re: How to teach Git

#75

Post by zwischenzug »

'How to teach Git' was something I had to think a lot about when a lot of my technical colleagues didn't know what a rebase was, and asked me to sort out their 12-team merge history (the 'git log --graph --oneline' spanned the width of multiple pages before you could see any commit message at all).

I realised that there's a point you can't progress beyond with git without having to do some thinking and learning. And lots of people aren't interested in the theory behind distributed file content. So I took Zed Shaw's hard way method and applied it to git. It made for a really enjoyable course at work and I then turned it into a book (1).

The tl;dr is I believe you need real world experience with a mentor prodding you at the appropriate time to think a bit deeper. Then the understanding will follow.

Here's an example from an 'advanced' chapter: https://zwischenzugs.com/2019/01/09/git-hooks-the-hard-way/

[1] https://leanpub.com/learngitthehardway

Re: How to teach Git

#76

Post by creeble »

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.

+1 these, I wish they were default for git. Much better both for beginners and experienced users.

Re: How to teach Git

#77

Post by Fellshard »

Humbly, I'd disagree that's the best, though this is a superb _part_ of the picture to teach Git well. These are nearly the last steps, I would say.

When new colleagues joined our firm and hadn't yet learned Git, the problems were always the same: uncertainty. They didn't know which Git operations were safe, and they didn't understand how to perform seemingly risky maneuvers with zero risk. They're used to even more dangerous tools that can wipe your work in a second - and, to be fair, Git can as well. The difference is that once you understand Git, you never have to worry about losing work.

So the way I would teach Git is to honestly start with the graph. Show it in action with pictures. Show how to always keep references to commits around to ensure work sticks around. Show how branching and stashing work, let them be confident that the tool will keep everything right where you left it.

_Then_, once they're confident in the basics, weave in the remote repositories.

Re: How to teach Git

#78

Post by syntaxing »

This is a pretty great overview! However, I learned Git and Github from Udacity's free course [1] and it was amazing to me since I am more of a visual learner. It got me up and running with Git within a week or two. I recommend others who have no prior experience with Git to check it out.

[1] https://www.udacity.com/course/how-to-use-git-and-github--ud...

Re: How to teach Git

#79

Post by hoorayimhelping »

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.

    git config --global alias.lg "log --color --graph --oneline --decorate"
for easy copy-pasting. HN doesn't support backticks or triple backticks like a lot of markdown parsers. To get fixed-width fonts, you have to insert 4 paces at the beginning of the 'code' block.

Re: How to teach Git

#80

Post by oblio »

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.

Git in many occasions (including when using git log) feels like the designer just threw their hands up and said:

"F*ck this shit, make your own UI on top if you want to use this tool!"

I don't think Torvalds has a proper excuse for the pain and suffering he's inflicted on millions of developers worldwide :(

(To the people going: "Oh, it's Open Source!". Sure, so are Mercurial, Fossil, etc.)

Post reply on HN