Package: gitty
gitty - a simple alternative to git flow with less rigidityThis project provides an easy way to deal with git branches in an environment with multiple parallel development streams.View download stats here:https://pypistats.org/packages/gittySome assumptions:themasterbranch is the cutting edge of new developmentrelease stabilization branches are created for each major and minor releasesemantic versioning will be used to track where we areprojects are using either maven, python, or nodejsSome sample work flows...To get started, we'll make a new empty project using node.Next, we'll walk through some common scenarios and see how to use this thing.%mkdirtest-project
%cdtest-project
%npminit--yes
%gitinit
%gitaddpackage.json
%gitcommit-m"initial commit"Now, we have a blank project with a package.json file in it and nothing else.current state of affairs (and some help)To see some useful info about your project, you can just run the gitty command.I'm assuming that you installed gitty using pip fromhttps://pypi.org/project/gitty/->%gitty
$gitrev-parse--abbrev-refHEAD
currentbranch:master
projecttype:node
currentversion:1.0.0commandname:helpavailablecommandsonbranch"master"are:

cleanup:['c','clean']# tidy up the local repository - remove obsolete branches# make sure the git repo has no outstanding changes$gitfetch--all--prune$gitpull--rebase# remove select local branches that have been merged to master...andaLOTmoreoutputhere...This is telling you what gitty thinks the state of your project is, and what you can do.new release stabilization branchLet's say that we're ready to snap a 1.0.0 release of our project. From the output above, you can see the "release"
command and it can be run using eithergitty releaseor justgitty r:->%gittyr
$gitrev-parse--abbrev-refHEAD
currentbranch:master
projecttype:node
currentversion:1.0.0commandname:r
$gitcheckout-b1.0/master
Switchedtoanewbranch'1.0/master'$gitcheckout-b1.0/releases
Switchedtoanewbranch'1.0/releases'bumpversionto1.0.0
$gitaddpackage.json
$gitcommit-m"bumped version to 1.0.0"b'On branch 1.0/releases\nnothing to commit, working tree clean\n'$gittag1.0.0
$gitcheckout1.0/master
Switchedtobranch'1.0/master'$gitmerge--strategy=ours1.0/releases
bumpversionto1.0.1
$gitaddpackage.json
$gitcommit-m"bumped version to 1.0.1"$gitcheckoutmaster
Switchedtobranch'master'$gitmerge--strategy=ours1.0/master
bumpversionto1.1.0
$gitaddpackage.json
$gitcommit-m"bumped version to 1.1.0"Wow, that's a lot of crap.That's showing you what's happening when you create a release - why all that stuff? I'll fill in more details later, but for now: Because.At the end of that, you'll be back onmasterand there will be 2 new branches:->%gitbranch1.0/master1.0/releases
*masterThose branches have purpose.The1.0/masterbranch is used to stabilize the 1.0 release; The1.0/releasesbranch is used to give us a stable
point of reference in the future for things like hot fixes, etc.There's also a new tag:->%gittag1.0.0That is on the releases branch, and specifically, on the commit where the release candidate should be built from.new task for forward developmentThis is a common thing - so it's pretty simple:->%gittytsome_new_thing_here
$gitrev-parse--abbrev-refHEAD
currentbranch:master
projecttype:node
currentversion:1.1.0commandname:t
$gitcheckout-btasks/some_new_thing_here
Switchedtoanewbranch'tasks/some_new_thing_here'Chuck some code here and commit it and push it - eventually, you'll merge it back tomasterand it'll be real code. Yay.new task for release stabilization branchYeah, this doesn't sound like a great idea, but sometimes, it's needed.->%gco1.0/master
Switchedtobranch'1.0/master'->%gittytsome_new_task_for_10
$gitrev-parse--abbrev-refHEAD
currentbranch:1.0/master
projecttype:node
currentversion:1.0.1commandname:t
$gitcheckout-b1.0/tasks/some_new_task_for_10
Switchedtoanewbranch'1.0/tasks/some_new_task_for_10'Now, you've created a branch from the1.0/masterbranch named1.0/tasks/some_new_task_for_10- the naming indicates
where it will end up (although eventually, you'll most likely want to merge it tomastertoo, for now, we'll just work on 1.0).new release candidate for 1.0To make a new RC for the stabilization branch, do this:%gco1.0/master
->%gittyr
$gitrev-parse--abbrev-refHEAD
currentbranch:1.0/master
projecttype:node
currentversion:1.0.1commandname:r
$gitcheckout1.0/releases
Switchedtobranch'1.0/releases'$gitmerge1.0/master
bumpversionto1.0.1
$gitaddpackage.json
$gitcommit-m"bumped version to 1.0.1"b'On branch 1.0/releases\nnothing to commit, working tree clean\n'$gittag1.0.1
$gitcheckout1.0/master
Switchedtobranch'1.0/master'$gitmerge1.0/releases
bumpversionto1.0.2
$gitaddpackage.json
$gitcommit-m"bumped version to 1.0.2"Again, that's a lot of output...but it's what's happening.Now, the1.0/masterbranch got merged to1.0/release, we have a new tag for the release candidate (1.0.1), and
the1.0/masterproject file reflects that we're now working toward1.0.2for the next release candidate.NOTE: Because we merge back to1.0/master, we have a single place to look for changes to be merged to version 1.1 (onmaster).wrapping up a release to prepare for the next oneOnce release 1.0 has been released and we're ready to start on the road to 1.1 (and 1.2), we'll want to get all of the 1.0 changes merged back tomaster(where 1.1 lives). There's not much to do there, so we just use git:%gitmerge1.0/master
Auto-mergingpackage.json
CONFLICT(content):Mergeconflictinpackage.json
Automaticmergefailed;fixconflictsandthencommittheresult.
%(dowhatyouneedtodotomergetheconflictshere)%gitaddpackage.json
%gitcommitCreating the next release is exactly the same as before:%gcm
%gittyrYou'll see a pile of output again, and at the end, there will be1.1/masterand1.1/releasebranches and a new1.1.0tag for the release candidate.Versioning for python projects (i.e., eating my own dog food)I'm using this tool to manage the git repository for this tool, so its versioning approach is the one that it supports.The versioning scheme is based onsemver 2.0.0, and will use a suffix of "dev0"
to indicate that a version is not a release (and partly because of how setuptools behaves).For this project, non-release builds will not be deployed to pypi - only actual releases will be deployed.This versioning will start as of version 1.2.0.dev0 (currently master).pluginsYou can now make plugins for gitty - there are samples in the oh so cleverly named "plugin_samples" directory.I'll be documenting them more in the future, unless I die or win the lottery or get busy with other things.tab completion plugin (zsh - experimental)I'm working on making this easier, but for now, to enable tab completion:install gitty 1.5 or laterdownloadhttps://raw.githubusercontent.com/lmeadors/gitty/master/plugin_samples/zsh_complete.pyto ~/.gitty/create a symlink to/usr/local/bin/gitty_completion.zshin your zsh custom directoryThis is a new feature starting with the 1.4 release. It seems to be working for me, but your mileage may vary - if
it's broken, let me know, and I'll try to make it better.