5 ms·

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

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.

leni536 8y ago
> 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.
cyborgx7 8y ago
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.
- rachelmcarmena 8y ago
  Right, thanks!!
jamesb93 8y ago
It sounds stupid but something that really simplified git to me as an absolute beginner about a year ago was the fact that it doesn't exist on GitHub. Knowing that git was just something that sat in the folder on your filesystem and monitored changes took away the notion that there is some kind of sync between your remote and local. Working just on my own laptop made me realise how intuitive all the commands and strategies for solving problems were. Then came pushing, pulling etc between branches and it all just fell into place.
- benwaffle 8y ago
  I wouldn't say it monitors the directory, because there is no git daemon running. Git just looks at the changes whenever you run a git command
mcguire 8y ago
I would suggest making sure to explain why there staging step exists: to create coherent commits. Then go into "why distributed version control." How to write a Good Commit Message (https://chris.beams.io/posts/git-commit/ https://chris.beams.io/posts/git-commit/).
rachelmcarmena 8y ago
Thanks for the feedback! Right, this is only a help to have a mental map. Only some initial drawings for a mentor or trainer, not for the newbie.
- diegoperini 8y ago
  If so, I'd love to see a more elaborate, guide-like version of this model. I've tried a similar approach years ago for teaching and failed spectacularly. Eventually, my peers became comfortable when they got used to the Github Desktop Client. They compared the buttons they click with my terminal commands. We also compared our graph views on Github website to visualize the logic. It's been years and still none of them used rebase even a single time. A sad story in my teaching non-career. :(
  - rachelmcarmena 8y ago
    I drew those diagrams after reading Pro Git Book. I missed what appeared at my head, but the entire book is very useful. For me, command line is freedom. GUIs are very limited. Don't give up! For my humble experience: - Try to know your peers, how they work, what difficulties they face when using command line, ... - "I'm lost" > "git status" - "How did we solve... ? > "git log" - "This command is difficult to remember." or "This command makes no sense, I prefer this another name for that action" > "git alias"

leni536 8y ago

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

cyborgx7 8y ago

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.

rachelmcarmena 8y ago
Right, thanks!!

jamesb93 8y ago

It sounds stupid but something that really simplified git to me as an absolute beginner about a year ago was the fact that it doesn't exist on GitHub. Knowing that git was just something that sat in the folder on your filesystem and monitored changes took away the notion that there is some kind of sync between your remote and local. Working just on my own laptop made me realise how intuitive all the commands and strategies for solving problems were. Then came pushing, pulling etc between branches and it all just fell into place.

benwaffle 8y ago
I wouldn't say it monitors the directory, because there is no git daemon running. Git just looks at the changes whenever you run a git command

mcguire 8y ago

I would suggest making sure to explain why there staging step exists: to create coherent commits. Then go into "why distributed version control." How to write a Good Commit Message (https://chris.beams.io/posts/git-commit/ https://chris.beams.io/posts/git-commit/).

rachelmcarmena 8y ago

Thanks for the feedback! Right, this is only a help to have a mental map. Only some initial drawings for a mentor or trainer, not for the newbie.

diegoperini 8y ago
If so, I'd love to see a more elaborate, guide-like version of this model. I've tried a similar approach years ago for teaching and failed spectacularly. Eventually, my peers became comfortable when they got used to the Github Desktop Client. They compared the buttons they click with my terminal commands. We also compared our graph views on Github website to visualize the logic. It's been years and still none of them used rebase even a single time. A sad story in my teaching non-career. :(
- rachelmcarmena 8y ago
  I drew those diagrams after reading Pro Git Book. I missed what appeared at my head, but the entire book is very useful. For me, command line is freedom. GUIs are very limited. Don't give up! For my humble experience: - Try to know your peers, how they work, what difficulties they face when using command line, ... - "I'm lost" > "git status" - "How did we solve... ? > "git log" - "This command is difficult to remember." or "This command makes no sense, I prefer this another name for that action" > "git alias"