flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <gosm...@adobe.com>
Subject Git needs a KISS
Date Fri, 05 Apr 2013 17:27:56 GMT
KISS = Keep It Simple, Stupid

We've gotten ourselves in a hole where contributors are overwhelmed by the complexity of our
recommended Git workflows and command lines. We need to dig ourselves out, and quickly, before
we lose momentum.

I don't think we should move back to Subversion, but I think we accept that many people would
prefer a radically simpler approach to Git which is more like the one we were used to in Subversion.

I think we made a serious mistake by pushing the nvie branching model (http://nvie.com/posts/a-successful-git-branching-model/)
Just looking at the first diagram makes me want to close the page. This is overkill if all
you're doing is fixing a bug or adding a test or something simple. The only part of nvie that
should be mandatory is "Don't' do any work on the 'master' branch". It should be fine for
most contributors to check out the 'develop' branch and do all their work there.

Most contributors shouldn't need to worry about using Git's "stage" or "index". They can just
"commit all". You only need to stage things when you DON'T want to commit everything you've
done. How often is that?

We SHOULD NOT CARE if there are extra merge commits in the log. That's the way Git naturally
works. Using obscure and controversial command line options to "keep the log clean" is not
worth it, especially if it makes it harder for people to use visual Git clients. Many people,
including me, do not enjoy working on the command line (although that's how I'm currently
using Git).

With a KISS approach, what most people need to know to use Git each day, after they've cloned
the repo and checked out the develop branch, can be really simple:

1. Edit your files. No Git command required.
2. Merge in other people's work with 'git pull'.
3. If there a merge conflicts, fix them by editing. No Git command required.
4. See what files you've changed or added with 'git status'.
5. See what you've changed in a file with 'git diff <file>'.
6. Commit (to your local repo) what you've done with 'git commit -a'.
7. Share what you've done (in the public repo) with 'git push'.

Note: There are only 7 steps. It's lore in cognitive science that people can remember 7 things
but not necessarily more.

Note: The only command-line option is -a to commit all your changes. All of these commands
are probably available through any Git GUI.

If you are working on a significant feature with a group of people over a period of time,
then learning more about Git so that you can work together on a separate branch makes sense.
 But many contributors just want to make small changes, and the above workflow should suffice.

If this KISS approach resonates, I'd like to have a poll on it.

- Gordon

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message