On Mon, 2011-01-24 at 06:05 -0800, Jonathan M Davis wrote: [ . . . ] > Well, it's going to be a bit of a learning curve for most of us I think. I've > used git a fair bit, but only on my person stuff. I've never collaborated > with it > (aside from using git-svn to communicate with an svn repository), and I've > never > used github. But from the comments thus far, I get the impression that most > people around here don't even have that much experience with it. So, we've > all > got a bit of learning to do. It should be a big improvement though, once > we've > got the kinks sorted out.
With the Gant and GPars projects, we found life became so much easier using Git than Subversion, even though people had to learn not only a new command set but a whole new way of thinking about version control. If using Eclipse or IntelliJ IDEA then the Git plugins are very good. I don't know about Code::Blocks. As long as people just say to themselves "we have made the change, don't look back" you'll find everything shakes out quickly and things become better. A few thoughts stemming from our experiences -- I don't think any are contentious but . . . : Use remote tracking branches -- they are Git's greatest contribution to DVCS. Remember your repository is your fork of the project, you do not have a checkout of trunk. If your repository seems to get incomprehensibly broken, don't try and fix it, get a new clone of the central master repository. Don't rely on GitHub, use GitHub as needed. Personally I just use GitHub as a place to put a mirror of my repository for a project. Only commit to the central master repository finished changesets that everyone agrees on, never put feature branch stuff into the central master. The central master should at all times be a pristine repository that by definition is the agreed state of the project. Some of the commands of Git are highly complex, always remember they are and don't try and treat them as simple. Some of the parameter syntax can get very perlesque. Git's "index" is weird compared to other DVCS. Use gitg, gitk, gitgui, git-cola, qgit. Personally I am a bit of a gitg addict. The point is that you have a whole repository with an increasing number of branches and you need to visualize them. Get into the habit of using feature branches. Create a branch for every new bit of work. When the work is ready, merge into your publishing branch and announce a pull request. Other people can then pick up your change and integrate it into their repository as they see fit. Working with feature branches allows people to experiment collaboratively because everyone can work on the same changesets. Keep your named branches that are tracking branches of the central repository pristine so that you have a local mirror of the current agreed state of the project. I could go on, but it will probably get boring. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
