As I diligently work on my next game, it occurred to me that I’m getting a lot of value out of GitHub. Not only does it provide a source repo for a tool I’m familiar with (git), but it’s also a de facto backup of my project, available for me to use from another computer (I did some traveling recently), and has a barebones (but solid) issue tracking system to stay organized and focused.
Not shilling for GitHub! There’s other options out there.
But since IF attracts so many non-programmers, I’m curious: How many authors here use some kind of source code control for their projects? I’m asking about games, not for libraries, interpreters, compilers, engines, etc.
Like, saving source code to a cloud? I have two desktop computers, a laptop and a smartphone and access Inform 6, Inform 7 and TADS source code through a cloud. SugarSync in my case, Dropbox probably being the most popular one, individual solutions possible. You mean that? I find it super comfortable, whether I’m at home, on the train, on the beach, in a hotel room, I can work on my games. But that’s pretty standard for 2022 ent?
Well “cloud” is just a concept, but as long as your individual solution (be it commercial such as Dropbox, or self-made) allows you to access your cloud files as you would access a directory on your hard drive you’ll be fine. Beware, there’s plenty solutions that will NOT serve your needs, e.g. by not auto-sync’ing files on all connected devices. Dropbox is fine tho.
Yeah, I keep my inform stories in Dropbox through some kind of folder forwarding thing I looked up a while ago, and then occasionally email them to myself (just as plain text in an email). I also download and mail archives of twinery to myself when using that.
Keeping files in Dropbox or some other shared directory scheme is not source control. It’s network distributed storage. Of course, though, you can put a Git repository into Dropbox.
I suspect most authors with programming background would do source control if only out of habit. On the other hand, I suspect most non programmers would not do source control, if only for the fact they are not aware of it and it would add an extra layer to the tech stack.
It’s not just programmers that have a source-control background these days. If you’ve done either art or writing for a large game project, you’ve probably gotten familiar with source control of some kind. (Perhaps not git.)
However, plenty of people haven’t worked on such a project. So I agree with the general point. If you don’t have source control in your bones, you really just need some kind of backup plan. Doesn’t have to be a source control system. You definitely don’t have to learn git to write IF.
I am a programmer and I use git by habit. But the version control features of git don’t really play into my needs when I’m writing IF! I don’t branch, I don’t merge, I don’t look at revision histories. I’m pretty much just writing code and making sure the changes are pushed every night.
Source control systems allow you to work with different versions of the same file in a streamlined way. It also tracks changes (and who made the changes) to the source code. It is most useful when working with many people on the same project, but there are many advantages even for solo programmers. This is a simplification.
I use github for sure. There’s nothing nicer than being able to do a commit and know you’re current state is saved forever. Then be able to really experiment with stuff and be able to just revert to an earlier state if things go amiss.
I’m sorry, I wasn’t trying to be obscure when I posted my question. I should have included a definition or added some links to my original post.
And I agree with this:
But I also know that not everyone is going to use formal source control for their projects. Keeping a back-up of some kind is a bare minimum for safety and sanity.
I will add that some of these integrated source control services (GitHub, GitLab, some of the Subversion-based systems) offer niceties like issue tracking, that is, a fancy to-do list with features like prioritization, note fields, etc. I need that kind of organization to stay on top of the mound of work required to finish a game (or any program, for that matter). Of course, there are plenty of alternatives to issue trackers, including good ol’ pen and paper.
Yeah. I think most single-coder passion projects operate that way, games or otherwise. It’s when multiple coders are involved that the workflow grows more convoluted.
I will use branches for one reason: If I start developing a game feature and run out of steam or need to focus on something else, I’ll store my changes in a branch and return to them later. I don’t like leaving the game in a broken state. Whatever I check into main should always be runnable and workable.
I think it’s been immensely helpful to me. It’s something I’d like to write a lot more about. I really recommend it.
All my projects are at andrewschultz (Andrew Schultz) · GitHub. I used to use Bitbucket back when it had private repositories, and once GitHub got that functionality, I switched to GitHub. (Yes, you can save commits between repos! It’s not too bad! But issues get lost.)
What I really like about GitHub is the graphical interface that shows if/when you’ve recently made commits. This is a big help to remind me to get back on course. I’ve found that it’s not the super-technical features that get me organized and working, but sometimes it’s just incidental things I found that just clicked.
I also like how the issues are organized on Git. I can label them with tags, so often, if I tag one issue that needs fixing, I can check other closed issues to see what might clash.
Source control intimidated me a lot because I didn’t know where to start, but fortunately, I found ways to do a bit every day.
It’s a relief to read that you do this and don’t feel obliged to use any fancy features.
There’s a tendency to think “oh I have to use the advanced features to get what I want from it” and knowing you don’t is a huge boost that the basics work well. So I’d like to echo what Zarf said about coding for our purposes (or what I think he said) – I think you will get a lot of mileage out of several simple commands. I seriously think I’ve sent in fewer than 5 pull requests, if that, to someone else’s repo, and most of these would be typos. (In fact, I probably even just reported an issue and said “OK, it’s probably easier for you to tweak the typos.”)
As for me using source control?
my reasons for source control
I have a backup that stays if I move across computers. This was instant peace of mind for me!
I can look to see what precisely has changed when I’ve tried to fix a bug. In particular, did I get rid of debug code? Can my code be cut down in any way, or did I submit duplicate code? Are there any glaring errors in my code that are immediately obvious? While it’s best to have others do code-review, I also like being able to audit some of it by myself. Also, if I try to implement something and fail, it’s easy to do a u-turn
reading about best practices, I feel more comfortable that “only” a 5-line change is important and worthwhile. Similarly, having several of them feels like, wow, yes, I got a lot done. It’s been useful for me to structure my pushes with a succinct commit message, and if I say “lots of stuff” or something, I know I should break the commit down. It stops me from trying to do too much at once. At least partially.
I don’t read past commits much, but if a project has multiple files, I can see what changed when.
sometimes it’s just good, when I’m feeling unproductive, to pull up a repo and say “Hey! Wait! I made 200 commits! That’s a lot!”
an issue tracker is great for stuff I can’t fix right now, whether I’m on a roll and it’s too small, or I don’t have the ability to make a big change yet. And just being able to look at issues I closed feels good–and it gives me a good idea of what regression tests might be valuable and what I don’t want to break!
Often it’s not just about the code but working on test case documents or walkthroughs, etc., that lets me feel–okay, I did something today.
One thing that’s important to remember is that the 80-20/Pareto Principle rule is pretty intensely at play here with git commands. In fact it’s closer to 90-10 or 95-5. There’s so much to know, but there’s very little you have to know!
So what are the basic commands?
basic commands
git clone (your directory/your project).git
should be done first.
git add **.ni will probably be your main command for adding source code.
You can use git add --patch **.ni if you only want to add some changes. This is useful if you’re working on one feature and find a side bug that wouldn’t really fit with the main code, but you want to fix the bug and not forget about it later. git commit -m “fixed bugs from X’s transcript” will commit changes git push will push to the remote repository. I generally wait to do a push in case I discover any disastrous bugs with a commit.
These are all you strictly need for a paper trail of commits. git reset undoes changes you didn’t want to commit, and git commit --amend is useful if you forgot to slip a change into a commit and you haven’t pushed yet. git reset HEAD~1 undoes the last commit but keeps changed files.
I really recommend starting with a small project, even a sandbox one you’ll delete later, to get the hang of things, or to try experiments.
I’d add that I used these just fine for years before really drilling down into the neat things git can do. They’re fun to discover, but they are more about making things easier or finding information than just having a copy.
I’m in the habit of checking every line of code now as I change anything that’s remotely unusual. I’ve had a few instances where I’ve learned the hard way after altering a few different parts of coffee before checking and having to try and retrace my steps.
