I often use git in session demos, in order to show step by step software development. Until now, I defined tags for developmental milestones and I used to checkout to go from one step to another. But this is not a good idea: I sometimes want to update certain steps and the transition from a tag to another one is not always intuitive.
I found some interesting ways to try to improve things. At https://coderwall.com/p/ok-iyg, next and prev aliases are defined to facilitate navigation between steps, but these aliases are defined on commits, that does not solve the problems of updates steps. At http://www.damirscorner.com/UsingGitInSessionDemos.aspx, the steps are based on branches, which I think is a better solution to allow updates. It is possible to redefine commands like next and prev in this context, possibly using a naming convention for branches (step1, step2 ... for example).
But in order to get fully functional controls, one could ideally add some operations, such as: the possibility of an amendment to a branch and the merge with one or more other branches (either previous or next ones), or the check just before leaving a step that the working directory is clean, with a proposal to either clean or commit.
Do you know an extension / workflow / use case in this spirit that could help me to reach faster the environment I want?
Thanks in advance!
One fairly simple solution would be to create these two aliases (presuming a *nix environment):
Those will resolve into:
...where
branch
is the name of the current branch - e.g. if you're on themaster
branch and callgit next
, it'll resolve to and rungit nextmaster
. Then you can just make repo-local aliases with thoseprev
/next
names.If you want
git next
to take you fromstep1
tostep2
andgit prev
to take you fromstep2
tostep1
, then make these aliases:This turns things into a git-like system of loosely-connected nodes, connected only by named references, which are easily editable in
.git/config
under the[alias]
section, ready for use in any environment, and contained away from the files in the repo proper.Note that the config file does not travel with repos (i.e. when cloning, fetching, pushing, or pulling), so you'll need to bring the
.git
folder with you, or at least the.git/config
file, or just remake those aliases wherever you are.