Opencaching International > General discussion

Using git for opencaching

(1/3) > >>

I would like to share the "opencaching using git" experience we have gained this year.

When moving from the polish code base to the german code base we branched the german svn. We checked out the branch in git and decided to work in git and then merge our work back into svn when we have finished. This was meant as a pilot for testing out if git was a useful tool and would not have happened unless tosubo had administered it from start.

Our experience of this pilot is very interesting. The tool is less user friendly and much more complex to learn than svn, but it is much more powerful and much more suited for casual and multi-branch development than svn. This however comes at a cost.

git is desribed as a distributed version control system, but you could also describe it as a two stage checkin. The checkin is done in a local "version control server". The changeset can then be moved between other "version control servers", for example one that is public and acts as master.

The extra work involved working with git is that after checkin you need to push your changesets to "the master" and to get access to others work, you need to fetch it from "the master" and merge it into your own local "version control server".

After learning a few basic concepts this actually works very, very good. Sending around changesets and merging them works like magic.

The plan was to terminate the git-pilot and merge our changes into the german master svn, but lately we have started to think of switching to git also for the german source. If that is the descision then we need to create a group and configure a new master for this.

Here are some examples on how to collaborate using git.

What we want to accomplish is to get new and to the rest of the team unknown developers possibity to contribute without compromising security of the production code. The pull request model described above is very well suited for this.

Van de Bugger:
Hi all,

Using distributed source control is a right thing. But... project sources are in GitHub (, tracker is in Google Code (, developer forum is at (

Probably it would be better to keep all the parts in the same place?

I am not familiar with Google Code and GitHub, but Source Forge offers all the stuff: source control (either Git or Mercurial or CVS or SVN or Bazaar or ...), tracker (SF's tracker or Mantis), forums (public and closed (for developers only)). It also offers much more — stuff for wiki, blogging, mailing lists...

I am not insist on Source Forge. I am ok with either Google Code *or* GitHub, but not both.

Any thoughts?

Van de Bugger:


--- Zitat von: am 13. April 2011, 00:07:03 ---Any thoughts?
--- Ende Zitat ---

We might get trouble with the licensing requirements of sourceforge. For hosting at sourceforge, all our codes need to be GPL (or other open source license). We have several different licenses used at the moment (see doc2/license.txt).


[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln