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

11–20 of 273 posts

Re: How to teach Git

#11

Post by pjc50 »

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?

People are very used to the web "save always" style: There is one document, and you're editing it. Most people will be familiar with the traditional desktop "save" model where you have to do something to make your changes permanent.

People often then learn that there is a local file and some remote file: they can cope with a save -> upload workflow. Lots of traditional VCS turn this into a save -> commit workflow.

Git adds two stages to this that people can't see the need for without understanding the internals: an extra step between save and commit, and an extra step after commit.

(The discussion reminds me of all those people who think that if they just start by talking about monads then people will find Haskell easy and natural...)

Re: How to teach Git

#12

Post by meuk »

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…

I like the commandline as well, but most of my coworkers are happy using a git GUI, and I can see why:

  1. Most GUI's give you an overview of the changes before committing.

  2. Most GUI's let you commit and push in one go, and also show unstaged changes so you don't forget to add/commit/push anything.

  3. A good git GUI is explorative. Newbies just remember the icons to click at first, and they learn more by exploring menus and reading messages.

  4. Commit histories are easier to view and filter.

  5. Exotic steps are easier to do, since you don't have to remember commands you barely use.

  6. Adding remotes is a piece of cake.

Re: How to teach Git

#13

Post by mettamage »

Some ideas on how to teach it non-verbally in class, regarding the add, commit, push workflow:

In class I'd stand on my right side, so students see me on the left (people are more used to left to right motions because of reading).

I'd demarcate the working directory, staging area and local repository non-verbally as 3 different spaces. My most right space (the student's left) was the working directory, my most right space (the student's right) was the local repository.

Everytime I'd make a transition from one space to another through add or commit, I'd make a hand gesture when I'd say "add" or "commit".

In order to add some humor (humor is rememerability) with push I'd point upwards to the ceiling as if I were looking to God. I'm not religious, but people got the reference and they all left out loud.

Re: How to teach Git

#14

Post by leni536 »

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.

> The flow chart looks almost exactly the same for "pull" and "pull --rebase".

"pull" and "pull --rebase" can cause two kind of conflicts:

1. Merge or rebase conflict inside the repository.

2. The would-be merged or rebased HEAD conflicting with the dirty working directory.

The article demonstrates the latter and it's the less important one as it's avoidable by pulling from a clean working directory or pulling a non-HEAD branch.

Re: How to teach Git

#15

Post by pjmlp »

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.

Even for experienced people, I rather spend my time on GUI tools and only drop into the CLI on as needed basis.

From UI/UX point of view, developers are users as well, but many seem to think developers should put up with bad interfaces.

Re: How to teach Git

#16

Post by chrismorgan »

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.

The problem is that most Git GUIs are just that—Git GUIs, with much of their functionality being a thin layer over a subset of the decidedly poor-usability Git command line interface. There are small areas of their functionality where I find that some do a really good job, but mostly they still require you to learn the underlying concepts and nuances of Git rather than of version control in general. I am not aware of any that have evidently been constructed from the other end, focusing on the users and workflows, bending Git into shape around that. Naturally, there are dangers of being opinionated like that when it comes to playing ball with other users that might not use that particular client; this is a hard problem, which explains the paucity of attempts. (Making “a Git client” is easy; making a good tool for users is hard. It’s similar in other domains where there’s an easy path and a far better path—the far better path is seldom trodden.)

Re: How to teach Git

#17

Post by darkpuma »

I think the best thing you could do for novices is to avoid priming them with preconceptions of Git being difficult. Psyching people up before instructing them never seems to do people any good, yet it's very common.

Re: How to teach Git

#18

Post by cyborgx7 »

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.

This is an article, not for people who don't understand git, but for people who do understand git and want to explain it to others.

Re: How to teach Git

#19

Post by cyborgx7 »

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

Re: How to teach Git

#20

Post by hwh »

I got mixed results with a completely different approach: starting with what actually exists within a Git repository (i.e. roughly: focusing on aspects of the plumbing layer first).

However, this only works with people who can make the mental leap to be able to deduce knowledge of what should be from knowledge about what is. In the end, I concluded it's a bit like teaching cooking. There are those folks who need to be taught about full recipes and those who need to be taught about resources and corresponding steps.

I have not yet seen a working approach to make both of these fractions happy, unfortunately.

Post reply on HN