| One of the reasons that there's not a "nice easy wrapper" that you refer to is that the workflow of using git is very, very different depending on what your role in a project is. When most people talk about the git workflow, they are thinking of the workflow of a feature developer - which is one of the simpler use cases. Let's think about git, however, as a tool for automating existing workflows, though: Person #1 is a developer. His workflow looks something like "git fetch public; git checkout -b new-branch public/master; $EDITOR; git commit; git push incoming new-branch". His 'incoming' remote goes to a repository of everyone's unreviewed feature branches, and each feature is parented from the last commit that was in the public repository. Person #2 is a reviewer. He has two remotes, "incoming" and "reviewed". His workflow is "git fetch incoming; git checkout incoming/branch-to-review; git log --stat; $VIEWER; git push reviewed branch-to-review" Person #3 is an integrator who's responsible for the state of the 'master' branch on the 'public' repository which is visible to everyone. He only wants to merge reviewed branches. His workflow is "git fetch reviewed; git checkout master; git merge reviewed/branch1 reviewed/branch2 reviewed/branch3; $BUILD_AND_TEST; git push public master". This is the sort of real-world use of Git that goes on in large organizations. It's actually harder to think about using Git in a single-developer project, because one person is playing the role of developer/reviewer/integrator, and typically doesn't think consciously about what role he's in at any one point in time: so his workflow is sort of a mix of all of the above, which ends up being overly complex. Tools like SourceTree really don't help the situation either, because they try to give you a graphical interface to git commands in general (since they don't have any insight into the development process for a particular project). |