On Fri, Apr 5, 2013 at 10:27 AM, Gordon Smith <gosm...@adobe.com> wrote:
> 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 > > +1 to everything you said :-) The key here is that there are people here with varying level of expertise with Git. Expecting a newbie to learn and understand the uber commands is not reasonable. Let us roll with the KISS strategy, let everyone get onboard with the Git philosophy. All the advanced commands can be learned as needed. Thanks, Om
