Skip to end of metadata
Go to start of metadata

Below is a proposal for how we could set up our Git infrastructure and the process of using it.

The aim is to improve on this further and, if useful, incorporate it into the Software Development Guidelines.


Important Difference Between Subversion and Git


Typically, in Subversion, there would be one centralised repository for all projects/components/modules to live in, with a (typically) trunk/branches/tags structure.

This is not the case with Git!

Because of Git's decentralised nature, repositories are generally much more self-contained and portable, and the granularity is different. It's common to have multiple repositories, one for each discrete project/component/module.

It is up to us to decide the granularity and stick to it. The important point is that we are going from one centralised repository to many decentralised repositories, where cloning, pushing and pulling between locations (or servers) is very common.

  • Git location or server - a location or server for storing, accessing and updating multiple Git repositories. GitHub would be one example.
  • Git repository - a single Git-powered repository. Essentially a directory with a .git directory within it that houses the repository (which includes branches and so on). Repositories exist in locations or servers and can be cloned, pushed and pulled between these locations and repositories.
  • Git clone - the act of copying a whole Git-powered repository from one location or server to another. Typically copying from a "master" location (not to be confused with "master" branches) to your local machine, for development purposes.
  • Git pull - the act of pulling in and merging any latest changes from a repository that is marked as a "remote".
  • Git push - the act of pushing latest changes to a repository that is marked as a "remote" (often this is the "origin" repository that was cloned from).

Check out for more info. Try for a quick-start guide.


  • We will be working with many Git repositories (maybe one per project/component/module).

The Proposal

The diagram believe shows the general pipeline we will be working with:



This diagram is NOT intended to depict the whole process of development - it is missing key parts like requirements gathering and design. It only shows the parts of the pipeline that are relevant to the Git infrastructure.

The diagram below shows the overall flow that is being proposed:

  • Developers work with their own set of repositories locally, cloned from the master repositories at GitHub (from:
  • Developers can code, break, fix, and test code locally and branch/commit to their local repositories.
  • Developers regularly push updates back to GitHub.
  • Code integration (between branches) can be pushed on to the GitHub repositories.
  • (Possibly) automated builds should be carried out for each repository in GitHub, to ensure that the invidual pieces work together (NOTE: this will depend on the architecture so can be changed). The existing infrastructure at Poznan should be used for this.
  • When individual projects/components/modules are ready for an iterative release, a tag should be pushed to the relevant GitHub repository for the Poznan repository to pick up. Once this tag is created, the developer should notify the maintainer, who will kick start the final "release" process at Poznan.
  • At Poznan, the relevant repository(-ies) should be pulled from GitHub and then any final system integration, automated builds, quality assurance, acceptance testing, versioning, packaging and deployment should be carried out.
  • The public facing repositories (to the world) should be the GitHub ones, since GitHub provides all the infrastructure for forking, commenting, pull requests and so on.
  • We will use the Poznan Crucible and Fisheye installations for internal reviewing and browsing - these will pull repositories both from GitHub (for day-to-day feedback) and from Poznan (for the system-level integration)

Key Points

  • It is important that only a one way sync is maintained between the Poznan Git repositories and the GitHub repositories. To ensure that we don't have merge/sync issues between Poznan and GitHub.
  • GitHub is where we can store, publicise and share all code, even if it isn't 100% stable.
  • Poznan is where the business happens - putting all the code together and releasing it. Poznan also acts as a backup for the repositories.


  • What about remote branches? Should individuals push their (longer-lived) branches to the common repository under - or fork the repository under their git user?
  • The "Git way" of doing things is one repository for one module or component. Should we follow this?
  • What projects/components/modules are there going to be? (ongoing as part of architecture discussions I guess)
  • Who will be the maintainer/integrator at Poznan? One per module? Not necessarily staff at Poznan!
  • No labels

1 Comment

  1. Unknown User (soiland-reyes)

    This should also be good inspiration:
    The plugin Git Flow makes it easy to follow this pattern.