Is there an idiot’s guide to starting to use git with Inform 7? Or even something more generic?
I just increment the number at the end of the file/project name periodically, which isn’t ideal.
2 Likes
Here’s a previous discussion, but it’s more for how to use Git for an Inform 7 project than an intro to Git itself.
Here’s the official Git tutorial:
https://git-scm.com/docs/gittutorial
5 Likes
A key benefit of source control comes into play when you realize you made a mistake, but have no idea when or where.
4 Likes
This is an intro to git.
4 Likes
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.
8 Likes
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.
3 Likes
Yeah definitely.
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.
3 Likes
This older thread with git commands and tips may be of interest: Git (or other open-source) hints/tips?
3 Likes
I use source control for more or less everything, from config files for the home router on up. Once you get in the habit, the overhead is so minimal that it’s worth it even if the chances of needing it (to recover an old version or to identify when a particular change was made or whatever) are small.
I do end up using branching a lot in development of any programming project, game or otherwise. Basically I usually start out with a very raw prototype branch where I’ve got all the canonical “best practices” (modularity, code re-use, and so on) in the back of my mind, but I don’t sweat it too much.
Then at some point I look at what I have and can better identify what’s actually, in this particular game/project, a one-off and what’s a general case that I’m going to re-use throughout the game. And at that point I start a new branch, moving all of the “general case” stuff off into its own library (or whatever).
This is something that probably works better (in the IF authoring domain) in TADS3, which makes it easy to split things up–nearly whenever I implement a new behaviour for an object or NPC or whatever, it goes in its own source file. And this makes it easier to sorta grab a bunch of capabilities and decide that they should be living in their own library instead of in a specific NPC or whatever.
3 Likes
I’ve bookmarked the idiot’s guides above for future reference!
I’d quite like to upload the source code of my one adventure game to Github (publicly), and work on it and others using git on my computer, but have a completely separate Github account for interactive fiction than for other things. Could you recommend a further guide for that? I’ve searched the internet in the past for this but for some reason just didn’t quite understand the answers, or at least not enough to give it a go.
2 Likes
Sounds like you’re low on coffee. (snicker)
Haha yeah probably not far from the truth. Thanks for spotting that one 
It probably shouldn’t be too hard to create one git account with one gmail address and one with another. Then you could, say, log onto your work-in-progress/creativity account on Firefox and the technical one (e.g. using Python) with the other.
Though I don’t know if 2 accounts are necessary. Github’s private repositories let you keep stuff away from public view if you want, and of course, you don’t ever have to push a local repo to the web.
But on the other hand, you don’t have to write a grant proposal to have two separate Github accounts. However you want to learn about git that works best for you is how you should go about things.
Can it be set up so that you don’t need a password for both accounts. Ie it “knows” from the particular repo which user you need?
With Gitlab and Github too, you can have “groups”, which look like separate accounts as far as URLs are concerned. This is how Friends of Inform 7 · GitHub works.
It depends how you want to separate your IF stuff from your other stuff. If you’re happy for one account to be seen to be committing to both, you can just give the second account access to the first account’s repositories.
If you want no trace to link the accounts, that’s possible, but it would require setting quite a few things. You’d need to change both who is seen as authoring a commit, as well as who pushes the commits to the web repo. I’ve never tried to do that so I’m not sure how tricky it is, but probably not too tricky. Git is intended to be flexible.
I have two github accounts, one for school/work and one just for IF. It was kind of complicated to get it working and I’m honestly not sure if this would work today. And this method is probably terribly insecure. But here’s my setup on linux.
There are two lines in ~/.git-credentials:
https://<username1>:<pat1>@github.com
https://<username2>:<pat2>@github.com
where pat1 and pat2 are personal access tokens as created using these steps.
In order to associate a git repository with a specific github account, I add the following lines to .git/config within the repo’s main folder:
[user]
name = <username>
email = <email>
Also, change the [remote "origin"] url to https://<username>@github.com/....
4 Likes
Wow. thank you very much. this is what i need.
I literally save my backups for the game on Google Drive, with a .txt file detailing the most recent update.
I am starting to regret that I didn’t go down this path when I started working my way through Creating Interactive Fiction with Inform 7 this past November. Now that I’m nearing the end of the book, I’m considering the merits of creating the game a second time using git to record notes and lessons learned via the commit log.
Today I created an initial repository with a new Inform 7 project and uploaded it to my GitHub repo.
Is there a published standard .gitignore for Inform 7 users?
If not, does anyone recommend extensions or folders I can or should ignore in my Inform 7 project when I push commits to GitHub?
UPDATE ------------------------------------------------------------
Alas, I should have searched before posting. There is a thread that discusses .gitignore recommendations here.
6 Likes