in most cases, merge will always do where people use rebase. rebase is only _really_ necessary when you're trying to keep a patch series up to date with a moving upstream head. i wanted to keep the basic reference simple, just the commands that most people need most of the time.
i will add more sections to the site - probably including a workflow section that goes over rebase vs merge workflows.
This site looks like a great reference, but coming to git from subversion I found this page[1] to be clear and concise, and gave me enough understanding to start playing with git right away.
Great resource, thank you! That's definitely been bookmarked for later.
Another invaluable resource, at least for me, for learning git has been Pro Git[1]. Absolutey wonderful way to learn git even with no background in version control.
of course. That's why I want a git for the non-technical user.
non-techies also have a need for version control. They just don't have access to it.
If I had said, "I want rsync for non-technical users" a couple years back, I'm saying I wish there was something like Dropbox. You might have said "rsync isn't for non-technical users", which is besides the point.
Most non-techies actually don't need version control. At least not version control that works the same way source code version control works. Writers and digital artists already have infinite layers of undo in their authoring software which is generally good enough.
I would almost argue source control period isn't for the non-technical user, but I could see some fringe cases where training non-techies to use it would be useful.
But git is DEFINITELY not for the non-technical user.
Edit: Just to be clear, as a technical user, I love git.
But then I can sympathize that it might be a difficult thing to explain without illustration.