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

21–30 of 273 posts

Re: How to teach Git

#21

Post by JediWing »

radarsat1 wrote: post #4
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”.

> WHY there is a staging area I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging? You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?

So I have a solid mental of git, and I understand the theoretical need for the staging area.

However, I find the occasions for using the staging area in practice are few and far between, for the simple reason that I can't test and execute the code that's in the staging area without also having the code from the working directory also be there. It feels like after having partially staged some of my working directory, it would be a blind commit with no guarantee that things are working.

Very rare is the situation that I can break out a list of files over here that are for feature A and some over there for feature B, and never the two shall interact.

I think this is probably what most struggle with regarding the staging area, without being able to articulate it.

Re: How to teach Git

#22

Post by spurgu »

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.

This is like teaching people to drive a car with an automatic gearbox.

Re: How to teach Git

#23

Post by mtrn »

I once taught[1] the building blocks of git (basically bullet time view of a commit) and people found it a bit too theoretical - even though it contained all the elements, that helped me to understand and appreciate the simplicity.

There is a point, where you go from memorization (add, push, commit) to deduction (graph, objects and refs) but when this point is reached, depends on many individual factors.

[1] https://git.io/fhWxg

Re: How to teach Git

#24

Post by fdsak »

radarsat1 wrote: post #4
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”.

> WHY there is a staging area I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging? You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?

probably related changes grouped together

Re: How to teach Git

#25

Post by pjmlp »

spurgu wrote: post #22
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.

This is like teaching people to drive a car with an automatic gearbox.

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

Re: How to teach Git

#26

Post by jordigh »

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

The staging area is really an extraneous concept that isn't required. It's like a commit that isn't a commit.

In Mercurial, I much prefer to just make it an actual commit in the draft phase (the default phase) and just keep rewriting that commit. Mercurial provides tools for both selectively adding and removing hunks from a commit (both `hg amend` and `hg uncommit` accept --interactive for hunk selection). If you're extra paranoid, you can make it a commit in the secret phase so it's not shared prematurely by accident.

It's pretty much functionally equivalent and doesn't require an extra location in which your code can be. It's either in your working directory or in a commit.

A bonus of this approach is that now you have a meta-history, hidden by default, of what you've "staged" and "unstaged". It's kind of like a reflog but with, in my opinion, a better UI. And of course, the index/cache/staging area in git doesn't use refs, so there's no reflog there.

Re: How to teach Git

#27

Post by jamesb93 »

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.

It sounds stupid but something that really simplified git to me as an absolute beginner about a year ago was the fact that it doesn't exist on GitHub. Knowing that git was just something that sat in the folder on your filesystem and monitored changes took away the notion that there is some kind of sync between your remote and local. Working just on my own laptop made me realise how intuitive all the commands and strategies for solving problems were. Then came pushing, pulling etc between branches and it all just fell into place.

Re: How to teach Git

#28

Post by crispyambulance »

abhishekjha wrote: post #6
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.

Its opposite for me. I am very comfortable with the command line. It lets me do crazy things and if I mess up, quitely crawl back to the peaceful place. GUI integrations have some advantages but the knowledge is not transferrable. Different GUIs work differently but the commands stay the same. I think both can complement each other. I use Pycharm a lot and it is a lot easier to see diffs or file history there. I thin…

    > and if I mess up, quitely crawl back to the peaceful place.
Ok, but getting to THAT level of comfort takes a long time and many failed attempts.

While I understand why folks may want a GUI for git, I am continually amazed that there hasn't been an effort to "refactor" git commands so they're more consistent, easier to remember and easier to discover. It's a miracle that git has taken root so strongly, given it's shitty user experience.

I've been using git for years, and STILL, I need my cheatsheets and google far more than I would ever admit in person. Anything that's outside of heavily practiced workflow-- and I'm in a world of confusion.

Re: How to teach Git

#29

Post by quietbritishjim »

abhishekjha wrote: post #6
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.

Its opposite for me. I am very comfortable with the command line. It lets me do crazy things and if I mess up, quitely crawl back to the peaceful place. GUI integrations have some advantages but the knowledge is not transferrable. Different GUIs work differently but the commands stay the same. I think both can complement each other. I use Pycharm a lot and it is a lot easier to see diffs or file history there. I thin…

Committing to version control is one of the ideal uses of a GUI. You can skim your eye over the files you've changed, and flick between their diffs by just clicking on their file names, before going ahead with the commit. You can simultaneously cast your eye over recent commits in the revision history. Of course these are easily accesible with git status and git log (|less) but it's not the same as dealing with the information graphically.

I would posit the ed text editor for comparison. Why bother with a graphical text editor (including terminal editors like Vi and Emacs)? After all, you can look at the context surrounding lines you wish to edit by entering the appropriate ed commands.

I think it comes down to developers being so used to working with command line tools that they don't give GUIs a proper chance - ironically the exact objection they have with less experienced users not using the command line.

Re: How to teach Git

#30

Post by Wehrdo »

When I was first learning git, I found an online visualizer like this [0] that really helped make make concrete the ideas of git history being a graph, and what different operations did on that graph.

There was still obviously the issue of memorizing the commands, but at least I knew what the commands were doing on a deeper level.

[0] https://learngitbranching.js.org/

Post reply on HN