https://www.bit-101.com/blog/2021/08/creative-code-management/ BIT-101 Bill Gates touched my Mac Book Pro. Menu Skip to content * Home * About Me * Recent Creative Code Management tutorial One of the things that's plagued me since I've been doing creative coding is managing the code I use to create images and animations (or whatever else). Of course, standard source control management comes into it in a big way. I've been using git for ages. I remember having arguments with coworkers who refused to see how git was better than SVN (at least they had moved off of CVS). So yeah, you put your code in a repo and you check in your changes, etc. But most source control workflows are really made for building applications. You decide on a feature, you make a branch, you do the work over a few hours or days or whatever, and you merge your code in. Or the same for a bug. In creative coding though, the update/render cycle is a few orders of magnitude faster than that. * Change a variable, render. * Change it a bit more, render. * Change another variable, render. * Put the first one back to where it was, render. * Ah! I like that one. Publish the image to twitter, or a website or wherever. * Change some other variables around, render a bunch of times. * Find another one you like, publish that image. * Repeat several times. * Done for the day, check in the code to git. The problem is, tomorrow or next week or six months from now, you want to recreate that first image you published. What were the exact variable values you used to create it? Who knows? Even if you didn't change the code, it might be nearly impossible to rediscover the exact parameters to recreate a specific image. Git branches are too cumbersome for this fast workflow. You can make a new branch when you find some parameters you like, but as soon as you change some other values, that branch no longer represents that first image. There are ways to work around this, but again, it gets cumbersome. But I finally figured out a good solution, along with a custom shortcut that I'm really happy with: Tags. A git tag is a permanent, unchanging reference to a specific point in time of your code base. Tag your code at a certain point and you can always get back to that exact point. It's never going to change unless you delete the tag and create a new tag with the same name. So, when you come up with an image that you want to save and publish, you do the following: 1. git add . to add all the changed files. 2. git commit -m to commit those changes. 3. git tag to create the tag to that exact commit. 4. git push to push it to the main repo (if you have one). 5. git push --tags to push the tags to the main repo. All good, but that's still five steps. Still a bit cumbersome. So I made a bash script that does all this in one shot: #!/bin/bash git add . git commit -m $1 git tag $1 git push git push --tags I named this file tagit, made it executable (chmod +x tagit) and put it in my path. If you're not totally up on shell syntax, $1 stands for the first argument given when the script is called. So now, when I want to save the state of my work, I jump to a shell and type tagit coolpicture or whatever tag name I want to give it. This adds the files, commits them using coolpicture as a commit message, tags the commit with the same label and pushes to the main repo, and then pushes the tags to the main repo. Now, six months from now when you want to see the settings you used for that cool picture, you just say git checkout coolpicture and there you are. Obviously, you want to name your tags something a bit more memorable. Some kind of timestamp or sequence is a good idea. I usually name the image or animation file the same as the tag name, so 210801a.png is the image that was created in the tag 210801a. You could even automate this if you wanted, to generate that image/tag name and rename the image when it creates the tag. One other point that I know someone will ask. Can't you just say: git push --tags and ignore the git push ? You can if you want. It will push the current code that is in this tag to the main repo. But it will not push the current code in the current branch to that remote branch. So your remote master branch (or whatever branch you are on) will not line up with your local branch. But your tag will still be saved as expected. It's up to you which behavior you want. Maybe you only want to push the tag, not commit to the branch at that point. Or maybe you want to save to the branch and the tag every time. Also, you could change: git push --tags to: git push origin $1 This will only push the specific tag you just created. There might be slight advantage to this in terms of speed. I suspect not. But, if you have other local tags hanging around that maybe you don't want to push, you should go this route. Anyway, use this script as is, or change it to fit your needs. Hopefully it saves you some time and frustration one day. Related August 1, 2021 keith Leave a comment Leave a Reply Cancel reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment [ ] Name * [ ] Email * [ ] Website [ ] [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] Post navigation - Inoreader Widgets I don't do any of that NFT stuff, but if you want to support what I do here and elsewhere, I'll happily send you a randomly generated token, and moreover be extremely grateful. https://www.paypal.com/ paypalme/bit101 Search for: [ ] [Search] Recent Posts * Creative Code Management * Inoreader * AweGif 2021 * Technology Update * The Noise Series Recent Comments * Josh Tynjala on Inoreader * Technology Update - BIT-101 on Catalina VM * The Noise Series - BIT-101 on Noise: 2d vs 3d, Perlin and Simplex * The Noise Series - BIT-101 on Mapping Perlin Noise to Angles * Curl Noise, Demystified - BIT-101 on Not Curl Noise Archives * August 2021 * July 2021 * June 2021 * May 2021 * April 2021 * February 2021 * January 2021 * December 2020 * October 2020 * September 2020 * August 2020 * July 2020 * June 2020 * April 2020 * January 2020 * August 2019 * March 2019 * January 2019 * April 2018 * March 2018 * January 2018 * December 2017 * November 2017 * October 2017 Categories * 7 days of code * experiments * minicomps * minimalcomps * misc * tutorial Meta * Log in * Entries feed * Comments feed * WordPress.org Proudly powered by WordPress | Theme: Illustratr by WordPress.com.