I like to explain it as “advanced undo-redo.” Most people who use computers have an intuitive understanding of undo-redo. You can ctrl-z all the way back to when the document was empty, and ctrl-y all the way forward to where you were. The difference with git is that you have to manually create those checkpoints with a commit.
But what if you ctrl-z a few times, and then type something? Most people know that all the changes they just ctrl-z’ed are gone. This is git’s first advanced feature: branching. Git allows you to maintain alternate ‘timelines’ for your file(s), which you can hop between at will. This is also what makes it a powerful collaboration tool: everyone on the team can maintain their own personal branches.
That last capability becomes extremely powerful with the next advanced feature: merging. Git has a number of very nice tools to assist in merging timelines back together, identifying conflicts when needed. This allows teams to set up one “true” branch that is the main (we used to use a different word) timeline. That way, each developer isn’t undoing and redoing on the same set of files, they can make their changes in isolation, and when a change is ready, it can be merged back into the main timeline. The proposed changes can be easily seen using git’s diff tool, and can be reviewed by the team, further refined, and finally merged with the main timeline. After this operation, the two histories have been joined and everyone else can pull in and start using that change.
I find that’s enough to get a new user conceptually oriented. That is, they have a good idea of what they need to do, if not the exact git commands to do it. But that’s the easy part, just a quick glance at the man page is all that’s needed.
I like to explain it as “advanced undo-redo.” Most people who use computers have an intuitive understanding of undo-redo. You can ctrl-z all the way back to when the document was empty, and ctrl-y all the way forward to where you were. The difference with git is that you have to manually create those checkpoints with a commit.
But what if you ctrl-z a few times, and then type something? Most people know that all the changes they just ctrl-z’ed are gone. This is git’s first advanced feature: branching. Git allows you to maintain alternate ‘timelines’ for your file(s), which you can hop between at will. This is also what makes it a powerful collaboration tool: everyone on the team can maintain their own personal branches.
That last capability becomes extremely powerful with the next advanced feature: merging. Git has a number of very nice tools to assist in merging timelines back together, identifying conflicts when needed. This allows teams to set up one “true” branch that is the main (we used to use a different word) timeline. That way, each developer isn’t undoing and redoing on the same set of files, they can make their changes in isolation, and when a change is ready, it can be merged back into the main timeline. The proposed changes can be easily seen using git’s diff tool, and can be reviewed by the team, further refined, and finally merged with the main timeline. After this operation, the two histories have been joined and everyone else can pull in and start using that change.
I find that’s enough to get a new user conceptually oriented. That is, they have a good idea of what they need to do, if not the exact git commands to do it. But that’s the easy part, just a quick glance at the man page is all that’s needed.