Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Add post about git workflow and fix syntax error

  • Loading branch information...
commit 8108fb485c2d12543710fb9fd8c44969ad48180a 1 parent fcd1e74
@mrscotty mrscotty authored
8 _posts/
@@ -21,10 +21,10 @@ A couple of the advantages of Jekyll, and in our case Jekyll-Bootstrap, are:
* Ease of deploying updates (just "git push" and the pages are automatically
-For those interested in creating content, just clone
-and take a look at the
-[](Jekyll Quick Start)
+For those interested in creating content, just clone the
+repository on github and take a look at the
+["Jekyll Quick Start"](
for a couple of tips and tricks.
One important note for contributors: in contrast to the code repository, where
59 _posts/
@@ -0,0 +1,59 @@
+layout: post
+title: "Git Workflow"
+category: developer
+tags: [git, developer]
+{% include JB/setup %}
+The new workflow model for Git commits follows the model presented with
+[git-flow]( As mentioned on the mailling
+list, there are two primary branches with the authoritive repository on
+: The stable, production branch containing officially-released versions
+: The unstable, development branch that may or may not work
+These branches are managed by the OpenXPKI team members that have the role
+"integrator". More on this in a moment.
+In addition to the above branches, the developers should use their own
+branches for active development and push the commits to their personal
+repositories on github. They then send a "pull request" to the project and
+an integrator will pull the commits and merge them into the "develop" and "master"
+branches, as appropriate.
+To simplify communications among team members, we suggest the following naming
+conventions (these happen to also be the defaults in git-flow):
+: Development commits regarding a specific commit -- branch gets merged to develop
+: Last-minute fixes for a pending official release -- branch gets merged to master
+: Bug fix needed outside of regular development workflow -- merged to master
+The idea here is that when the developer is working on a new feature, the
+first step is to branch from "develop" to a new "feature/*name*" branch. When
+complete, the developer pushes the results to github and sends a pull request
+to the integrators.
+The integrator has the task of pulling the feature commits and merging them to
+the develop branch. Then, when it is time for an official release, the integrator
+branches from "master" to a new "release/*version*" branch, merges the commits
+from "develop" and, after QA testing and bugfixes, merges the results back to
+The added step of the integrator may seem like overhead and it does add a step,
+but it also helps stabilize and formalize the release process.
+The "hotfix/*name*" works similarly to the "feature/" and "release/" branches,
+but allows us to apply bug fixes to the master branch without having to
+worry about the status of the "develop" branch.
Please sign in to comment.
Something went wrong with that request. Please try again.