|
|
|
|
|
by pjc50
2716 days ago
|
|
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...) |
|
1. Is my document saved?
2. Are the changes staged?
3. Are the changed committed?
4. Are the changes pushed to my fork on e.g. github?
5. Are the changes merged into the upstream repository on e.g. github?