Git suggestions

[Thomas Leonard-3]

A few people have expressed difficulties using Git. As Git can be used
in many different ways, I'll try to summarise how I'm expecting people
to use it. There are more complex workflows used in larger projects
(see "man gitworkflows"), but this is the one I suggest for
contributions to projects I maintain.

First, a reminder of the old subversion workflow (for people familiar
with that):

1. checkout master (trunk)
2. make your changes
3. update to latest version (svn update)
4. create patch (svn diff > patch) and email it
[ maintainer applies patch, possibly with changes ]
5. update to patched version (svn update)

Steps 3 and 5 are the tricky ones, as you may have to resolve conflicts:

3) if changes elsewhere in the code conflict with your changes
5) if the maintainer changed your patch before applying it


The suggested Git workflow is very similar:

1. checkout master
2. make your changes *and commit them locally* (git commit -a)
3. update to latest version (git pull --rebase)
4. create patch (git format-patch origin/master) and email it
[ maintainer applies patch, possibly with changes ]
5. update to patched version (git pull --rebase)

As with subversion, you may get conflicts in steps 3 and 5. Git
provides better tools for dealing with this (e.g. you can easily undo
the update if it goes wrong), but essentially it's the same.

Notice that you never create any merges. Only the maintainer should be
merging things (i.e. creating commits with more than one parent). Have
a look at the history (gitk). If you see a merge commit with your name
against it, you're probably doing something wrong!

This is really a Git user interface problem; "git pull" without
--rebase defaults to merging, which is almost never what you want.
Here's what happens if you merge instead of rebasing in steps 3 and 5:

3) you end up with a patch series containing patches against multiple
different versions, which is hard to review, plus many distracting
minor merge commits.
5) instead of getting a history containing just the final commit from
the maintainer, you get three commits: your original commit, the
maintainer's fixed commit, and your commit trying to resolve the two.
Even if you fully agree with the maintainer's version, you're now on a
separate branch with its own history, which will create yet more
unnecessary merges in future.

Hope that helps,


Note: if you push changes to a repository rather than emailing, you'll
need to use "git push -f" after a rebase to "force" the update.


--
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
rox-devel mailing list
rox-devel@...
https://lists.sourceforge.net/lists/listinfo/rox-devel