openssl rand -base64 32

Mature revision control workflow uses some branching conventions combined with some access policies to ensure that work being done in parallel by a number of developers can proceed with a minimum of collision-caused trouble, and with maximum safety.

Jenkins topics

Maven topics

Archiva topics

JMeter topics

Gatling topics

Basic usage, cheatsheet, tips, and tricks for git

In this proposal, there are three tiers of repository:

• An off-site/archival “vault” repository
  This repo resides on a server/service where developers are allowed only read-access. No direct changes will be made to this repository.
  
• The central development “shared” repository
  This repo resides on a development server, and is where all developers will share and acquire changes to/from.
  
• Individual developer “clone” repositories
  Every developer will have one or more of these, which serve as the “working space” for code changes to be made and committed.
  

Only build/release admins will have write-access to the “vault” repository. The only route for changes into this repository is a push from the shared development repository. This will only be done per release, by a build/release admin, and can be deferred until all aspects of a release and the associated changes are fully vetted. This repository also serves as an off-site backup.

This is the repository that all developers will clone their individual working repositories from, which means it is also the repository that will receive the pushes of changes from developers. The only direct changes made in this repository will be official release merges to the master branch, performed only by a build/release admin, for the purpose of integrating changes for a release. When a release has been built, tested, and deployed successfully, it can then be pushed to the vault repository.

These are cloned from the shared development repository, and serve as working space to make, and ultimately commit, changes. When ready, changes are pushed from these, by their respective owners, to the shared central repository.

These practices and policies are implied by the structure of the repositories.

The master branch of the central shared repository is locked, allowing no changes to be pushed to it from any clones. This protects the primary change history from accidental damage. It will only be manipulated via merge from the development branch, and only by a build/release admin, at build/release/patch time. This may, at some point, be automated

There is a branch which serves as the shared change history, which is eligible to receive changes pushed from individual/developer clones. This branch has the name dev, and serves as the staging tier for all changes to be integrated and tested prior to builds/releases. Every individual/developer clone should be “switched” to the dev branch for all revision control activity. Any changes made on a clone's master branch will be rejected by the central shared repository, so diligence in correct branch usage will be in everyone's best interest.

Optionally, further branching can be done in the clones at the developer's discretion. This is encouraged, and can be helpful in keeping sets of changes isolated and organized, potentially preventing merge/collision difficulties, or even helping to resolve such difficulties once they've occurred.

• Clone from shared central repository, or update existing clone with git pull
• Clone is switched to dev branch: git checkout dev
• Iterations of change-then-commit cycles in clone working space
• Merge changes from others with a git pull from the shared repo, and resolve conflicts
• Push freshly-resolved merge to the central shared repository

• All developers commit, push, and confirm completion on the dev branch
• An integration/test release is build from the current dev branch, and deployed to the central dev environment for testing and verification
• When the release passes verification, a build/release admin merges the dev branch to the master branch in the central shared repository, and builds the production release from the master branch
• After the production release is deployed and verified, the vault repository can be updated with a push from the central shared repository

• Clone from shared central repository, or update existing clone with git pull
• Clone is switched to dev branch: git checkout dev
• Create private branch (named at developer's discretion) and switch to it
• Iterations of change-then-commit cycles in clone working space
• Update clone with git pull to see others' changes on dev branch without disturbing private branch
• Selectively merge others' changes from the dev branch into the private branch
• Further iterations of change-then-commit cycles in clone working space
• Update clone with git pull
• Switch to dev branch
• Merge changes from private branch into dev branch, resolve conflicts, and commit
• Push freshly-resolved merge to the central shared repository

The github hosting platform operates similarly to the above self-hosted scheme, with some differences that makes sense to github's free software community sensibilities.

You may want a new branch, created in upstream repo, populated into your fork of that repo and your local clone(s) of your fork of that repo, so that you can work on the new branch, or at least see it. With GitHub, this isn't as trivial as natively-stored repos.

First, you'll need to make sure your local clone of your repo fork knows about its upstream:

git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

Then, you'll need to make sure the new upstream branch is pulled into your local clone:

• Ensure your working tree is clean (commit/stash/revert any changes), then, do:
  git fetch upstream
• Create and switch to a local version of the new upstream branch (which is named newbranch in this example):
  git checkout -b newbranch upstream/newbranch
• When you're ready, push the new branch to origin:
  git push -u origin newbranch
  The -u switch sets up tracking to the specified remote (in this example, origin)

Links: Tech Info … Linux Info