Bitbucket or Github?


#1

I know I’ve seen IF creators maintain online code repositories to track bugs and stuff for their games. A lot of IF people seem to use Bitbucket for a lot of things. I know of Github for open source projects, but I don’t know what the primary differences between it and Bitbucket are. Can a Github repository be private?

I was trying to sign up for an Atlassian account to use Bitbucket. Reading the terms of service, I realized that I’m totally confused and I don’t even understand what kind of thing this is.

Okay, so I just checked, and apparently Google Code shut down recently. So, that narrows it down a little.

I use git from the command line, and I want to push changes to my project from the command line. That said, I don’t really know how to use git. I pretty much only know how to commit changes. I’ve tried doing branches, but I haven’t even used git thoroughly enough to make branching very useful for me, so I just commit everything in the same branch.

The project I want to host on a repo isn’t a game. It’s the website I’ve now nearly finished making for Sunrise, the visual novel game from Spring Thing 2015. I worked with the lead writer to get some great new content, further building the alternate U.S. history/fantasy world where Sunrise takes place. I think the website will be a cool experience, a way to showcase how a world can be fully realized within the super-niche non-commercial structures of the VN and IF communities.

I need to squash some longstanding pervasive bugs, mostly JavaScript that works on some pages but not on all pages. I need to find some solutions to small UI problems that are not very aesthetically coherent right now but that I couldn’t really tweak until I had the bulk of the website more or less all together. I think using a repository will help me get organized enough to actually figure out what’s going wrong.


#2

I believe a private Github repository costs money. A private Bitbucket repository is free. Public repos (within certain limitations) are free on both sites.

The other main difference I’ve heard is that there are more people on Github, so if you want to collaborate or even just follow other people’s projects, Github has an advantage there.


#3

Github won’t let you have a private repository for free. You have to pay.
Bitbucket is okay for small private repositories (I think the limit is < 5 users for the free plan).

That’s pretty much the only difference most people care about. Bitbucket also supports Mercurial (that’s another version control system).

Personally I use GitLab (self-hosted instance). Gitlab doesn’t have any limits at all, they sell the additional features and user support.

Git is de-facto standard, so you’ll have to learn it. The branch feature is a thing you’ll want to master, it’s very useful in the long run. I recommend Git Book as a manual.


#4

Oh yeah, I forgot about that!


#5

Thanks for fast help, @blue_green and @Oreolek. I’m thinking a small private Bitbucket might be what I need, but I’ll look into GitLab too, then. :slight_smile:

Yeah, I’ve been searching the web for how to do whatever I need to do in git on the rare occasions when I need to do anything more complicated than committing the latest changes. But I do learn well from books. I should make the time to read through the Git Book, since it seems like a lot effort went into producing it to be readable. Thank you.


#6

Personally, I use Bitbucket because I prefer Mercurial for its sensible command-line interface. Git crams half a dozen unrelated functions into every command, requires arcane flags for common workflows, and exposes all sorts of low-level plumbing.

But whichever you choose, you aren’t locked into it forever. You can use hg-git to access a Git project with the Mercurial CLI, or git-remote-hg to access a Mercurial project with the Git CLI.


#7

I have a current project on Github, but that’s because it’s a public project.

For my personal stuff that I want backed up, I have local Mercurial repositories sitting in a Dropbox folder.

(Actually, my first sentence is only half right. The project is on Github, but I also have it under Mercurial in a local repository in Dropbox. Yes, I do actually submit and maintain duplicate checkins in both. I used a mercurial-to-git migration tool to get my mercurial repository into git form when I initially pushed it public.)

I tried using hg-git, but it never worked for me. I don’t remember, but it seemed to work better on Linux than Windows. (Or maybe it’s just other people instead of me. :slight_smile: )


#8

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.


#9

Git crams half a dozen unrelated functions into every command

That “Git Koans” is a highly entertaining read. :slight_smile:

A good point, too. I don’t have the motivation to learn things by brute force that don’t seem to have immediate rhyme or reason. I’ve decided to use GitLab with my current git-based website project, but before going deeper into version control for any future projects, I might consider switching to Mercurial.


#10

You’ve nailed pretty much all the relevant factors, I think. Thanks for sharing your experience and for the reassurance.

I guess I am at the do more stage, because I’ve come to see how version control and repositories can help me make real things by improving my organization and my ability to collaborate productively with other people. Organization and collaboration are both things I struggle with.


#11

Late, but having used both I have a slight preference towards Bitbucket.


#12

Pfft, that’s not late. I was late with some of my own replies on a bunch of other threads. You got nothin’ :slight_smile: .

It’s useful to try both and I know that worrying about which was best probably prevented me from just diving in. It seems like a lot of us have, by now–and without sounding too squishy, I think that’s the best way, for anyone wondering which they should use to start.

I’m happy with both–I need to use BitBucket for IFComp etc. projects, because the binary can’t be released publicly, but GitHub’s interface just works for me.


#13

I use both. BitBucket I use for work and I like to use it on any repos I want to keep private (the free private repos is nice). I do prefer GitHub though as I think it’s a bit more feature rich especially when dealing with open source where I’m accepting pull requests or doing public releases (like my work with @AndrewS on Trizbort).

There are a lot of tools that make working with Git easy, especially if you’re not using some of the advanced features, but I prefer the command line git tool. It easy enough and once you learn it (which didn’t take long to get the basics), gives you tons of power and complete control, something that’s not always easy with the GUI tools.