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

271–273 of 273 posts

Re: How to teach Git

#271

Post by 99052882514569 »

Fellshard wrote: post #131
99052882514569 wrote: post #120

Earlier quoted context omitted.

I just use a GUI for that. I don't like using applications like Sourcetree for any actions, but they really are superior for visualisation of the commit tree, diffs between non-adjacent commits or between branches, etc.

I'd recommend Git Extensions, still, as a good compromise between porcelain and plumbing. The most useful commands are all at your fingertips, with deeper ones available if necessary. Visualization is best I've seen - clean graph display, easy to read, and _doesn't lie in complex cases like SourceTree does._ SourceTree tends to treat commits with multiple ancestry in a very weird way that has led to difficulty on mul…

I don't use Windows. Seems a little clunky to get it to work on Linux, even more so on the Mac. Haven't had any multiple-ancestry issues with SourceTree - perhaps resolved in an update since you encountered it?

Re: How to teach Git

#272

Post by cben »

I only have a sample of 1 (my wife) but I've found Ungit: https://github.com/FredrikNoren/ungit unparalleled for explaining the graph model behind git — what's a merge, what it means to fetch vs pull, what's the difference between committing locally vs push etc...

The specific points that make it great for such teaching:

1. pretty graph

2. hovering over actions such as Commit / Merge / Rebase / Push shows what would happen to the graph if you do it.

3. you can manually "Move" local & remote branches anywhere you want! This is mildly risky as a habit, but much clearer to explain than fast-forward and push, especially with multiple remotes.

4. automatic fetch that works pretty well (though explicit fetch UI with multiple remotes is clunky). For people scared of merging and conflicts, it's liberating to teach "fetch is always safe" and "local commit is always safe", and that you can fast-forward or merge/rebase separate step.

Re: How to teach Git

#273

Post by JediWing »

u801e wrote: post #206
Someone wrote: post #194

Earlier quoted context omitted.

But then, you either never run/tested those smaller individual commits, or you have to do extra work (stash changes, test, restore stash) to do that. I do not see why a source control system should make it easier to make a commit that hasn’t ever existed on disk and thus cannot have been tested. I think the better model would be to stash your changes and have an diff editor between the on-disk working copy and the st…

> But then, you either never run/tested those smaller individual commits Not necessarily. One nice option that the git rebase command has is --exec (which can be specified multiple times). So you can run a rebase and have git execute a command (like running a test suite) for each commit in the branch. If any commit files, the rebase process will stop and let you amend the commit to fix the issue. > or you have to do…

Did not know about rebase with exec! I'll have to try that! Thank you for the insight.
Post reply on HN