For what it’s worth, it sounds like you’re now doing manually many things that version control does automatically. That doesn’t mean you have to use a version control tool, of course: it sounds like you have a system that works for you! But I personally find the level of discipline you describe around these things very daunting, so I feel lucky that I’ve already gone through the effort of learning a tool that manages that stuff for me.
9 Likes
I used to use Git, but now I just save releases in separate folders. I don’t want to overcomplicate something that doesn’t need it. Besides, I don’t want to turn creativity into a job. If I need to compare versions I will use the diff command. If someone wants to send me their changes they can use the patch utility.
Given how much command line Git is like a procedurally-generated parser adventure, it is surprising that so many people in this forum find it off-putting. You’d think people here would be used to unwinnable situations and a bit of guess-the-verb.
8 Likes
the real trouble of git(1) is that forces me (and I guess, also other Linux users…) to rename git(6) in gitif(6)…
Best regards from Italy,
dott. Piergiorgio.
2 Likes
This morning (in France), in a quiet moment, I took about an hour to learn the basics of using GitHub Desktop locally. Since there are many people on this forum whose opinions I regularly find very valuable, I didn’t want to miss out on something important due to a lack of knowledge or overconfidence.
As suggested by some on this thread, I’m working with a single branch and making regular commits to establish and maintain a history of changes. I admit it’s much more convenient than what I was doing, and those who advocate using version control tools are right in my specific case, even for a simple project like mine. And to tie in with what’s been mentioned, this will also allow me to clearly separate what concerns backup and retention from what concerns version control.
So, once again, a lot of relevant advice from you, as usual.
7 Likes
I take a different approach to Inform and Twine projects. When creating a new Inform game, I also create a new repository and do version control from the start.
For Twine projects, I’ll typically create small stories in the browser, and after each substantial change, I save the entire library and, at the end of the session I email it to myself. Once the project is unified in one story object and has a name, I’ll create the git repo.
I feel putting a Twine project into version control has a locking effect on it. Usually I do it when I believe the rest of the changes will be incremental (no multiple prototypes in different stories or alternate implementations). I could use branches for this, or commit the whole Twine library, but I have this " one story per repo" rule I like to follow.
1 Like
That gives me PTSD lol. One of my classmates didn’t understand the cloud file system we had at our school and each time she had to do a presentation, she mailed the file to herself instead of just putting it into storage (because we had time at school to work on it and at home). I was completely horrified by this experience.
But yeah, Twine games are a bit awkward to save if you don’t use a local twee compiler. I made a small compiler and VSCode plugin for hot reload and preview for Twine stories before I dropped Twine for custom stuff.
2 Likes
For single-author projects, most of the time git doesn’t do anything you wouldn’t accomplish anyway just using an online backup of your project directory. But every couple of years I run into the situation where something I thought I had finished working on months ago and hadn’t touched since then suddenly turns out not to be working any more, and it’s absolutely worth the twenty minutes it takes to reread the documentation and figure out how git bisect works, because even with a project that’s had hundreds of commits over a year or more, you can pretty quickly pin it down to “oh, it broke when I changed those lines of code”.
8 Likes
This discussion made me wonder if there’s a correlation between how useful an IF author finds git and how closely their development process resembles traditional fiction writing. Using myself as an example, I develop software as a profession, I make games as a hobby, and I write fiction on the side. Using git in my game development process seemed like a natural fit; but maintaining a fiction manuscript in a git repo has absolutely never occurred to me. Even for novel-length fiction, where I can at least imagine version control being useful in theory, I’ve never done it in practice.
3 Likes
What you’re saying is very relevant; I’ve been practicing role-playing games for 30-35 years, and it would never occur to me to program an interactive story without using worldbuilding methods and software that pose hundreds of questions and generate dozens of pages, even though barely 5% of that work will be perceived by the player. Alongside that, making commits in a main branch using GitHub Desktop might seem like a formality, and yet it took quite a few people here explaining just how important it is. So and thanks to others, I persisted in testing the tool despite my initial mistaken judgment. It’s probably one of the great benefits of this forum to enable experience sharing from different cultures.
5 Likes
For what it’s worth, I have started using version control for long-form technical articles in the last two years and I’m reasonably happy with it. That sort of writing is different from traditional fiction writing in some ways, but closer to it than to software development. However, I think writing in a “plain text”-based format like LaTeX or Markdown as opposed to a graphical editor like Word is a prerequisite for getting much use out of tools like git. That’s common for certain kinds of technical writing and also applies to some IF authoring systems, but it’s not as universal as for general software development.
5 Likes
One thing that helps here is making frequent small commits over large complicated ones. In this case you could still commit your edits in a series of smaller updates, then narrow down the problem.
Of course it is important to note GitHub isn’t git. GitHub is just Microsoft. I’m not a fan of two-factor auth, especially the limited forms usually offered - mobile device, or closed source authenticator app.
3 Likes
Yeah, I use Bitbucket instead of Github because I find it less hostile.
1 Like
it’s incredible useful for more than code. you can add pretty much anything to a repository.
that game map you keep updating?
those test files you keep making changes to?
that big word .doc with all the beautifully polished text of your game?
you can throw it all in and have a chronological snapshot of any and all changes. plus you can install the desktop client on multiple machines and have everything available and updated everywhere.
now i have to check out bitbucket because draconis is very smart
7 Likes
I would rename this topic to version control rather than GitHub. If you are making a short and simple text game by yourself then sure, you don’t need version control, but also in that case the usage of the version control system isn’t going to be complicated either. People have already mentioned a lot of the benefits of using version control - including messages for all changes, bisection. And not only bisection, you can get a list of changes for a particular file. You can easily revert the state of your working directory to a previous state. The repository is going to use far less storage space than backups. You can commit every tiny change you make if you want to, which is not going to work with backups.
4 Likes
Mercurial is better for this.
except if you want to easily keep a history of how your work developed and so on.
This is also useful for non-programming purposes, if you want to track changes across LaTeX documents/poetry/fiction/etc you happen to be writing.
How so? If you decide to rewrite parts of it, don’t you want to keep records of the previous iteration?
This is also obviously useful for regular writing. After all, trying to maintain versioned backups would essentially be reinventing the wheel of version control badly and by hand.
1 Like
I can annotate and track changes to a manuscript well enough without Git. Most of Git’s other benefits would be lost on me because I typically write my manuscripts with Microsoft Word. Git treats Word documents like opaque binaries. I could keep a history of versions, but I couldn’t diff, branch, and merge changes like I can with source code. (Word provides its own tools that aren’t as robust as a dvcs, but good enough for my purposes.)
1 Like