Renaming Conventions: Version Control System

(zero) #1

A discussion on renaming conventions took an interesting branch into implementing a version control system. Prompted by @dirkleas I’ve set up a git repository inside my patches folder which I’m administering via Gitkraken.
I’m only just beginning to explore the possibilities - and I’m also pretty green with git anyway - but it opens up previously only dreamt of functionality.
Gitkraken is enormously over specced for a fairly straightforward git project - would be a great boon to all if some enthusiastic coder took it upon themselves to produce a GUI specifically for the task.

Yeah, I could use the terminal, but…

(zero) #2

My workflow:

Start with an empty patches folder - move old patches to a folder called old patches?

Initialise a git repo in patches.

  • make sure you’re in the MASTER branch before starting on a new or imported patch

  • start a new branch - a meaningful name is useful.

  • either

    • save a new patch
    • import an old patch from old patches
  • stage and commit this patch to the new branch

  • continue to adapt your patch

  • save, stage & commit at appropriate points

    • leave useful notes in the commit summary as you do
  • go back to any save point

  • start a new branch at any save point

(Korfuri) #3

I commit all of my patches to Git, and mirror them in a private Github repo. I don’t usually branch much, my workflow is pretty linear, so all I have is one file (or folder, if working with other assets like .wavs) per project, and I commit on top of master every time I change them. When I want to work with multiple versions of a patch, I keep 2 or more copies of the project file, but it’s quite rare for my workflow.

The main reason I have this linear workflow is that Rack patches aren’t really designed to be easy to merge in the Git way, and Rack doesn’t really have ways to copy-paste between patches like a DAW would, so if you have diverging versions of a patch it’s hard to converge them again.

(zero) #4

I don’t regard branches as candidates for merging, but as different creative directions…