git-octopus
The continuous merge workflow is meant for continuous integration/delivery and is based on feature branching. git-octopus provides git commands to implement it.
Installation
Requirements
Requires git >= 1.8
You need to have a command shasum
in the path. This is the case on most unix based systems. If you're on Windows/Cygwin you may have to install it.
Homebrew
If you know and use Homebrew, you just need to do:
brew update
brew install git-octopus
RPM package manager
The packaging is temporarily hosted on Fedora copr:
dnf copr enable baitaand/git-octopus
dnf install git-octopus
From sources
Download the latest release or clone this repository. Go into the directory and type
make install
Make sure the installation works
git octopus -v
We respect semver
What you'll find
Two additionnal git commands :
git octopus
Extends git merge
with branch naming patterns. For instance
git octopus features/*
Merges all branches named features/ into the current branch. See git-octopus(1).
git conflict
Allows you to record conflicts resolutions that git octopus
can reuse.
Conflicts resolutions are standard refs so they can be pushed/fetched.
See the conflicts management section bellow and git-conflict(1).
The Continuous Merge
What is it all about ?
Feature branching and continuous integration don't live well together. The idea of this project is to reconcile those two by using the mighty power of git.
I gave a talk about why and how to use it at Devoxx France 2015, but it's in french ;) https://www.youtube.com/watch?v=8P0vyWIyAXM
The branching model
The simpliest form of the model is to have a mainline branch, let's call it master
, and feature branches on top of that master. In a continuous delivery workflow you won't need more than that.
- The
master
branch, or however you call it, is in a ready-to-ship state. Nobody commits on it. - A feature branch is a change, as small as possible, that can bring the
master
from a ready-to-ship state to an other.
This means that all the work is done in feature branches. Don't be afraid to have many, one branch per developer is fine. Keep feature branches independent from each other, that's the key for having a fluent delivery pipe.
The workflow
git octopus
allows you to merge all you feature branches together at any moment so you can have an assembly of all the work that is going on and finally do a continuous integration job on that merge. here's how it works :
A developer pushes a change on his feature branch. There is a job in your continuous integration system that will trigger and do this bash command :
git octopus origin/features/* origin/master && git push origin +HEAD:octopus
This job computes a merge with all feature branches and the master, and then pushes the result on a branch octopus
on origin.
The new merge commit on octopus
will now trigger an other job that will build and deploy this merge on your test servers etc ...
Note that the octopus merge is not kept in any history line. The next push on any feature branch will trigger the build of a new merge that will be forced push again on octopus
.
Once a feature branch is validated on your test environment, you can merge it on master.
Managing conflicts
If git-octopus
fails, it will do a diagnostic sequence to figure out the conflict precisely. It can lead to two cases :
-
A conflict has been found
-
Ask yourself if you could avoid that conflict. Rewriting the history is possible as long as you're alone working on the branch.
-
Use git-conflict to record a resolution and push it to origin. See the documentation for more details.
-
Consider to remove one of the conflicting branches from the continuous integration (I.E. rename the branch so it won't get caught in the merge) and wait for the other to be merged in
master
. Then you'll be able to update and resolve the conflict. -
Rebase one branch on top of the other (depending on which one you want to ship first). This has to be the last resort because you'll loose branches independency.
-
-
No conflict found
-
Someone else might breaks the merge, look at previous octopus job executions.
-
You felt in a complex case. There are ongoing works to prevent that from happening but for the moment this might happen. Don't hesitate to open an issue !
-
Community
We have a Google Group, feel free to come and discuss with us. You can also send an email to [email protected].