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

101–110 of 273 posts

Re: How to teach Git

#101

Post by cwbrandsma »

mdpopescu wrote: post #81

1. Install TortoiseGit 2. Use Visual Studio to commit (it automatically does "git add" with the new files you added to the project - I always forget to do this manually) 3. Use TortoiseGit to do "git push", because Visual Studio has a problem with ssh keys (or at least had a while ago and I didn't bother to check since) 4. When something breaks (and it will), google like crazy until you find a solution There. I never…

I've found the Visual Studio git integration to be not good with large solutions, just slows everything down. So I have it disabled in my projects.

What I do: I use GitHub desktop to get everything configured, then use the PowerShell command line to do all my work. Merge conflicts are fixed with VS Code.

Re: How to teach Git

#102

Post by nlawalker »

bagrow wrote: post #2

Having taught git several times within a data science course I find two concepts especially worth extra time: WHY there is a staging area, and what is the difference between “git” and “github”.

I've helped move a couple teams (kicking and screaming) from TFS to git, and I start back even further than that - why is it so much more complicated than clicking a button to save and share my work, and what is the benefit of that complication?

Re: How to teach Git

#103

Post by WorldMaker »

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.

I got into the habit of teaching people `gitk`. It's not the prettiest tool, but it's included with most distributions of git, defaults to a decorated color graph log, and thus avoids the "copy paste this weird config line" step on other people's machines.

Re: How to teach Git

#104

Post by WorldMaker »

rkangel wrote: post #97
oblio wrote: post #80

Earlier quoted context omitted.

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

This makes a lot more sense when you realise that Linus thought he was building a low level tool that people would build a UI on top of. The 'original' git command line was more a proof of concept and engineering tool than something aimed at actual use.

Right, doing a search through the git mailing list for the use of the word "porcelain" is fascinating. It's unfortunate some of those "porcelain" projects never finished.

Re: How to teach Git

#105

Post by epage »

Fellshard wrote: post #77

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…

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

Personally, I think this should be coupled with teaching `git reflog` as the universal undo (as long as they don't `gc`).

Re: How to teach Git

#106

Post by iheartpotatoes »

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

Re: How to teach Git

#107

Post by mcguire »

WorldMaker wrote: post #104
rkangel wrote: post #97

Earlier quoted context omitted.

This makes a lot more sense when you realise that Linus thought he was building a low level tool that people would build a UI on top of. The 'original' git command line was more a proof of concept and engineering tool than something aimed at actual use.

Right, doing a search through the git mailing list for the use of the word "porcelain" is fascinating. It's unfortunate some of those "porcelain" projects never finished.

... because none of the power users used them.

Re: How to teach Git

#108

Post by mcguire »

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.

I would suggest making sure to explain why there staging step exists: to create coherent commits. Then go into "why distributed version control."

How to write a Good Commit Message (https://chris.beams.io/posts/git-commit/).

Re: How to teach Git

#109

Post by jecxjo »

I like the diagrams, as many explanations often skip the staging portion of the whole git process. I use that so much that it baffles me that most people skip it. Then again, I typically don't like having tons of "WIP" commits so I stage a lot and if I need to switch to another branch I'll commit a WIP that I quickly `rebase -i` to get back to a clean status.

As for the teaching part, I have found the best results by having you and the learner actually "working" on the project at the same time on your own machines both pushing to a centralized server. It becomes too easy to go over all the commands and feel like you understand it. Most of the scary parts of git are used when its multiple developers on the same project. And oddly enough, having the learner do both Developer A and Developer B's tasks don't seem to work as well as having the learner just do Developer B while I do Developer A. Trying to explain to someone when to use merge, when to rebase, and when to use cherry-picking to get the code I just pushed into their current working branch can be done so much easier when its hands on AND knowing exactly who is doing what steps.

Re: How to teach Git

#110

Post by elcomet »

url00 wrote: post #71
detaro wrote: post #55

Earlier quoted context omitted.

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?

Almost never actually. I never commit all the changes in my repo (for big projects I often have some small changes in other places, I don't want to commit them)
Post reply on HN