So–I hope this doesn’t ramble, but basically, I’d like to show what I’ve seen and leave questions out there for what others think can be done better in general. I’m quite open to “you’re doing it wrong.” But the thing is–even if I know a few basics, they get me pretty far. And that’s a comfort.
For instance, just reporting an issue has helped me to–well, be aware of it without being suffocated by it. On Bitbucket, I can report its priority and its intensity. And that helps me decide what to do. I can add a comment if I’m stuck, or I can add test cases in the comments, or stuff I need to check that it might break elsewhere. Or I can report an issue I can’t get to right now because there are more critical ones, but I’d forget it otherwise.
That organization is huge for me, and it’s not terribly technical, because it’s easy to report issues. So I recommend using that liberally. Sometimes I’ve felt silly reporting a minor issue I think will have to wait, then fixing it five hours later. But seriously, that’s what issue tracking is for, and I “wasted” maybe only a minute writing up the issue. Just reporting issues regularly helps you prepare to accept ideas, whether they come sooner or later, of how to fix an issue or what sort of issues recur.
For works that don’t need to be private, I’m a fan of github, but it’s more for motivational reasons than technical reasons. Because the (showoff warning) personal stats page is a nice small nudge to try to do something every day. It’s been working. It’s also been neat to find other projects that are worth following. Bitbucket has that too but I never really got into it.
Bitbucket (free version anyway) doesn’t have the detailed personal stats page, but it does have the ability to divide bugs into tasks, etc., immediately, which helps. However, GitHub can label bugs and create milestones. Milestones are where a group of bugs is fixed or closed. So, for instance, in Trizbort, you might have a feature request for round-edged room shapes, another for hexagonal room shapes, and another for octagonal. Then a milestone would encompass all three and might be “new room shapes.” It’s a useful way to say, yes, I hit that goal. Or another might be to fix bugs in tester transcripts from 4 different people.
(Maybe Bitbucket has similar functionality. I’d love to read about it, because I missed it.)
I also have a cheat sheet of common commands that I refer back to, and I also have a dummy repository where I try new commands so my main one doesn’t have anything bad happen. The content there isn’t important, just that I’m able to try a new command.
Working with @harpua on Trizbort I finally got in a position where I needed to learn about branching. So I finally did so. It went something like this.
git checkout -b altfix
(make changes to files you need to)
git commit -m "#225 about: added basic stuff"
git push --set-upstream origin altfix
git checkout master
This has been a big help while I modify the documentation, which I can’t do all at once, and I don’t want to push an incomplete version. So I can change a branch to fix any minor issue I might find. In the case of a document update, I do everything above except push.
And of course it’s perfectly okay to only submit very small changes (even typos) for your first branch or whatever. Start small with project changes to learn the command.
The thing I’ve found about git (and I assume other languages) is that it’s more than okay to go with the basics until you need to do something more. You don’t need to worry about what you don’t know. And once there’s something that seems risky, you can make a project you’re going to delete anyway, to try experiments for branching, etc. I know I was worried about torching my own project until I realized this.
I know starting small with Trizbort documentation was big for me. Then I decided on a relatively simple project (Ultima IV/V mapper) for my next project. It was one I’d done before, and while it’d have been nice to recover the old code, making modifications just helped me get in a lot of repetition. And the thing about repetition is, it lets you learn a lesson, and if you’re lucky, it leaves you antsy to finally learn the stuff you shied away from before because just doing the basics can be a bit dull.
I still have a lot to learn, and so I’m quite interested in what roadblocks other people have. Sometimes just reading it finally gets me motivated to google what I need or look on stackoverflow.com, which has been a help in so many ways, for perl, python, source control or whatever.
The thing is, I have trouble learning technical stuff til I actually do it. So I recommend just going out there and doing the basics until you’re itching to do more, and it sounds like you may be at the “do more” stage now.
