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

81–90 of 273 posts

Re: How to teach Git

#81

Post by mdpopescu »

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 needed more in a number of companies.

[Yes, somewhat tongue-in-cheek and of course limited to people who use Windows and Visual Studio, but I have discovered that's a significant number.]

Re: How to teach Git

#82

Post by black-tea »

e3b0c wrote: post #49
black-tea wrote: post #39

The best way to learn git is to learn what's happening at the DAG level. That way you can think about what should happen on the DAG and then think of how you can use git to achieve that. For example, a fast-forward merge and a reset can be used to achieve the same thing. It's also very important to learn to use the reflog. When I was learning to climb they told me I'd never get really good until I'd fallen once. The…

I learned that Git stores data as DAG at the very beginning when introduced to it. But I came to get clicked until I realized that it is not only a DAG but an immutable one. That is, existing nodes of the DAG are never changed once created. The only operation supported by the system is more or less: create . Also, using the plumbings to peek into the content of the objects and refs inside the .git helps a lot as well…

Yeah, that's a very important point. Even changing the parent of a commit, that is, an edge in the graph, changes the hash of the commit. Therefore to change the parent (like in a rebase) you have to make a new commit, but the old commit doesn't go anywhere, you just can't see it because you have no reference to it any more.

Git will garbage collect these commits that can't be reached by any reference after a while, but usually that's long after you've forgotten they ever existed.

Re: How to teach Git

#83

Post by 0xffff2 »

Sir_Cmpwn wrote: post #66
collyw wrote: post #64

Earlier quoted context omitted.

That's a lot of reading for a tool that should be making life easier.

It's an engineering tool. You'll be using it all day every day for the rest of your career, the investment is worth it.

That's simply not true for many Git users. I'm a developer, so I do use Git every day, but I work with a bunch of researchers that absolutely do not need to use Git more than once a week at most. Convincing those people to care enough to learn the internals has been a constant uphill battle for me.

Re: How to teach Git

#84

Post by daosyn »

Just yesterday I attempted to explain to my colleagues (who have been mainframe developers all their life) the concept of having multiple remote repositories and different possible setups. I think I explained adding remote repositories well enough, and mentioned the use cases for such a setup -- having only read access from a repository and needing to develop in a fork while keeping up to date with the original.

Does anyone have a good analogy for this? I think they understood for the most part, but explaining things better is something I have been really trying to improve on in the workplace lately.

Re: How to teach Git

#85

Post by whorleater »

dahart wrote: post #68
JediWing wrote: post #21

Earlier quoted context omitted.

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,…

You never amend commits or rebase locally before pushing? I rebase before pushing almost every time. Git’s workflow wouldn’t even be sane without the staging area. This is what allows you to fix mistakes and make your work presentable for remotes.

judging by the atrocious management of remote history I've seen at workplaces, "making work presentable" is pretty far down the line of priorities

Re: How to teach Git

#86

Post by acemarke »

url00 wrote: post #69
aurumpotest wrote: post #36

Earlier quoted context omitted.

I use it quite a lot, especially with `git add -p` to stage only parts of a file for an atomic commit.

This has never made sense to me. I've seen others say that they commit only parts of a file. How does this scenario start? Are you working on solving one problem, but then notice some other unrelated issue and fix that too, before committing the first change?

Partly, yes. Or, I'll be working on a task overall, and have to touch multiple files in the process. Then when I'm ready to commit, I review all the modified files on disk, and look for ways to break those down into smaller discrete logical changes. I prefer to avoid "big bang" commits as much as possible, because smaller individual commits are easier to inspect, easier to back out if necessary, and provide a better "story" when inspecting a file's history sometime down the road.

Re: How to teach Git

#87

Post by mazlix »

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…

Yeah that's probably a good bare minimum amount of git knowledge. But I feel like that's making git which can be a super helpful and powerful tool nothing more than a means to an end.

Learning the functionality of git can really help you out. For example, I almost always use the `-p` flag (particularly `git add -p` which gives me a chance to manually see every change I've made, often I'll find some junk that I may have left somewhere else. Also being familiar with how to rebase series of commits onto and off of other branches can be a huge time saver.

Re: How to teach Git

#88

Post by someguy101010 »

daosyn wrote: post #84

Just yesterday I attempted to explain to my colleagues (who have been mainframe developers all their life) the concept of having multiple remote repositories and different possible setups. I think I explained adding remote repositories well enough, and mentioned the use cases for such a setup -- having only read access from a repository and needing to develop in a fork while keeping up to date with the original. Does…

I really think showing them how it works visually with a DAG is a great way to show someone how git works. Also, Linus has a great talk about git and how it works here: https://m.youtube.com/watch?v=4XpnKHJAok8

(Sorry for mobile link, I'm on my phone RN)

Re: How to teach Git

#89

Post by wtetzner »

mazlix wrote: post #87
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…

Yeah that's probably a good bare minimum amount of git knowledge. But I feel like that's making git which can be a super helpful and powerful tool nothing more than a means to an end. Learning the functionality of git can really help you out. For example, I almost always use the `-p` flag (particularly `git add -p` which gives me a chance to manually see every change I've made, often I'll find some junk that I may ha…

> But I feel like that's making git which can be a super helpful and powerful tool nothing more than a means to an end.

It also feels like a clunkier workflow than just using git from the command line. It's probably easier to get started that way, but learning the basics of git from the command line isn't too hard.

Re: How to teach Git

#90

Post by u801e »

Mirioron wrote: post #67
Sir_Cmpwn wrote: post #38

I disagree with this idea. The best way to learn git is to read the git book, in this order: chapters 1, 10, 2, 3, and the rest at your discretion. This way teaches you about the internals first, and if you understand the internals the rest of git is pretty intuitive. https://git-scm.com/book/en/v2

Great idea. This kind of culture is why there are a lot of people that don't and probably never will use git.

There's something to be said about reading documentation rather than relying on stackoverflow answers or possibly inaccurate tutorials.

Substitute C, Java, Python, etc for git. You can probably do something with those languages, but you aren't going to get very far without reading some sort of documentation.

Post reply on HN