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.

Glossary

• 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).

Assumptions

• 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:

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: https://github.com/wf4ever).
• 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.

Questions

• What about remote branches? Should individuals push their (longer-lived) branches to the common repository under https://github.com/wf4ever - 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!