3 ms·

When I need to explain git to someone for the first time I always start with the 'imagine you are copy/pasting your project folder, and you have multiple folder

When I need to explain git to someone for the first time I always start with the 'imagine you are copy/pasting your project folder, and you have multiple folders tagged with some details. Each folder is a commit'. People understand very easily how to keep copies of their work at a given time by simply coping the full folder (probably we all did this before using git). So yes, a commit is just a snapshot, a copy, it is simply saved in a much more efficient way. The issue is that some advanced (and not so advanced) commands, like a merge, aren't easily explainable with this metaphor, and that's when the 'commits are also diffs', or better 'commits can be seen as diffs' is needed.

rualca 6y ago
> So yes, a commit is just a snapshot, a copy, it is simply saved in a much more efficient way. Not really. Although it might be helpful to explain to someone entirely new to git that a commit marks a revision, and a revision is kind of a copy of a project folder, that mental model has no bearing to what a revision control does or helps you accomplish. I mean, as soon as you talk about diffs and branches and cherry picks and merges then thinking about copies of a folder spread around does not explain what's happening. And what's the point of git if not to track and manage diffs?
- globular-toast 6y ago
  > that mental model has no bearing to what a revision control does or helps you accomplish. It's exactly what revision control does and helps you to accomplish. What do you think revision control is for if not that?
globular-toast 6y ago
Yeah. That's a perfectly valid form of version control. You could tell them to imagine renaming the directory each time with an incrementing number. That's the version number, hence version control. Merge can be explained too. Say you send the folder to your friend and that night you both make a new version. If you want to consolidate your changes you have to merge them together. I don't see why this requires commits to be seen as diffs. Rebase is a bit more tricky. Maybe that's what you were thinking of?
- TrianguloY 6y ago
  In a merge without conflicts (for example you edit one file and your friend edit another) a merge could be explained as simply pasting one folder into the other, but then you need to be careful to override only one of the two files. Merging folders is not easy if you don't know what changed, but if you do know because your friend told you 'I simply modified this file' then you know how to merge them. But this information is a diff. In this particular example you need the new folder and the what changed information. That's what I was referring to. Rebasing...is far more advanced to explain, yes. Edit: or you can paste your folder into theirs, but still you need to know what you changed, your diff, so it's the same.
  - globular-toast 6y ago
    Well you just say you compare both of your new versions to the common previous version and work out how to merge them. Seeing the differences between two snapshots is something easily grasped in my experience. If you can see John changed file A and Jane changed file B then it's obvious how to merge them. When I teach git I try to convince people that such a system of keeping snapshots is a useful thing to do. Then I introduce diffing which lets you to merges. Then show how git does that automatically.

rualca 6y ago

> So yes, a commit is just a snapshot, a copy, it is simply saved in a much more efficient way. Not really. Although it might be helpful to explain to someone entirely new to git that a commit marks a revision, and a revision is kind of a copy of a project folder, that mental model has no bearing to what a revision control does or helps you accomplish. I mean, as soon as you talk about diffs and branches and cherry picks and merges then thinking about copies of a folder spread around does not explain what's happening. And what's the point of git if not to track and manage diffs?

globular-toast 6y ago
> that mental model has no bearing to what a revision control does or helps you accomplish. It's exactly what revision control does and helps you to accomplish. What do you think revision control is for if not that?

globular-toast 6y ago

Yeah. That's a perfectly valid form of version control. You could tell them to imagine renaming the directory each time with an incrementing number. That's the version number, hence version control. Merge can be explained too. Say you send the folder to your friend and that night you both make a new version. If you want to consolidate your changes you have to merge them together. I don't see why this requires commits to be seen as diffs. Rebase is a bit more tricky. Maybe that's what you were thinking of?

TrianguloY 6y ago
In a merge without conflicts (for example you edit one file and your friend edit another) a merge could be explained as simply pasting one folder into the other, but then you need to be careful to override only one of the two files. Merging folders is not easy if you don't know what changed, but if you do know because your friend told you 'I simply modified this file' then you know how to merge them. But this information is a diff. In this particular example you need the new folder and the what changed information. That's what I was referring to. Rebasing...is far more advanced to explain, yes. Edit: or you can paste your folder into theirs, but still you need to know what you changed, your diff, so it's the same.
- globular-toast 6y ago
  Well you just say you compare both of your new versions to the common previous version and work out how to merge them. Seeing the differences between two snapshots is something easily grasped in my experience. If you can see John changed file A and Jane changed file B then it's obvious how to merge them. When I teach git I try to convince people that such a system of keeping snapshots is a useful thing to do. Then I introduce diffing which lets you to merges. Then show how git does that automatically.