GitHub and BitBucket (2011)(pocoo.org)
pocoo.org
GitHub and BitBucket (2011)
http://www.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.html
20 comments
We use Bitbucket as primary host for open source projects to avoid fragmenting access control. Proposal repositories need to be private and most coauthors prefer journal article repositories to be private. GitHub's pricing model would encourage us to consolidate these private repos, but each has a small number of different external collaborators, so that would yield undesirable granularity. Meanwhile, all of our software products are open source, with a much larger group of contributors than the union of the proposals/papers. We mirror the flagship project on GitHub, but all of our development is on Bitbucket.
To be honest I never understood the value proposal of Github. Ok, you get git repository hosting, and list of projects, and that's pretty much about it, with the ability to browse code online without cloning. Besides, that, I personally find most of the features useless. For example issue tracker is unusable, concept of forks is just a small convinience that doesn't add any real value. And about the most praised feature, like pull request, I find it just annoying and too much work. As a potential committer, it's much easier to me to clone the original repo and send a format-patch set then to bother creating my fork, cloning the fork, creating branch, pushing branch and writing an issue. As a maintainer, I also find it more convenient to just deal with format-patch set or an url to repo/branch than to deal with Github pull request system. And Linus tends to agree with me on this ;)
That all being said, I still use Github for OS projects for visibility, I just don't accept pull requests, and Bitbucket for private projects because of unlimited free private repos. And I find them both useful, just not groundbraeking.
That all being said, I still use Github for OS projects for visibility, I just don't accept pull requests, and Bitbucket for private projects because of unlimited free private repos. And I find them both useful, just not groundbraeking.
First some context - I'm by no means a Git power-user. I learnt it under duress and would have much preferred Mercurial but at that point it was obvious which way the wind was blowing.
Back in SVN days I also used to be quite fond of Google Code as it is was much cleaner and simpler than Github to my eyes (bearing in mind that a lot of Git terminology was unfamiliar to me back then).
But once I learnt enough Git to get by, I started to love Github.
My standard workflow when I need to use a 3rd party app for a project is:
1. Find the original repo on Github, 2. Browse the network to see if any of the forks are more actively maintained or have enough additions to be worth considering pulling from. 3. Fork the best fork to my own account. 4. Make the changes I need and issue pull requests if I think upstream would be interested.
I've never learnt how to use patch sets. If someone sends me a pull request, it's 2 clicks to merge it. I'm sure patch sets aren't terribly hard but I can't see how they'd be easier than that.
Back in SVN days I also used to be quite fond of Google Code as it is was much cleaner and simpler than Github to my eyes (bearing in mind that a lot of Git terminology was unfamiliar to me back then).
But once I learnt enough Git to get by, I started to love Github.
My standard workflow when I need to use a 3rd party app for a project is:
1. Find the original repo on Github, 2. Browse the network to see if any of the forks are more actively maintained or have enough additions to be worth considering pulling from. 3. Fork the best fork to my own account. 4. Make the changes I need and issue pull requests if I think upstream would be interested.
I've never learnt how to use patch sets. If someone sends me a pull request, it's 2 clicks to merge it. I'm sure patch sets aren't terribly hard but I can't see how they'd be easier than that.
> I've never learnt how to use patch sets. If someone sends me a pull request, it's 2 clicks to merge it. I'm sure patch sets aren't terribly hard but I can't see how they'd be easier than that.
It's a few clicks if all you want is just to _blindly_ accept and merge it, without having it on your own computer before merging and being able to compile it, run a test suite, or perform some non trivial modifications to patch.
For this purpose, to me is much easier to just apply the patch set in my local tree, or add a new remote and checkout branch then to deal with github pull request.
It's a few clicks if all you want is just to _blindly_ accept and merge it, without having it on your own computer before merging and being able to compile it, run a test suite, or perform some non trivial modifications to patch.
For this purpose, to me is much easier to just apply the patch set in my local tree, or add a new remote and checkout branch then to deal with github pull request.
What is this 'compile' of which you speak?
(and slightly more sadly) What is this 'test suite' of which you speak? :-(
(and slightly more sadly) What is this 'test suite' of which you speak? :-(
Well git was invented for Linux kernel development, and Linus had his workflows dialed in years before GitHub was even founded (probably before Tom & Chris even started using Ruby). With his tree of lieutenants and long-standing email based workflow of course GitHub is going to be weaksauce for him.
But as for you, I'm a bit confused as to what you really want. You say issues are unusable, which I can only assume is because they do not have the extensive feature set of proper bug tracking systems, but then you also say that pull requests are too much work. GitHub is clearly trying to do for programmers a bit of the 80/20 thing that Apple does for consumers, or what 37signals did for project management—give simplified tools and workflows that are easy to learn and use even if they aren't suitable for all use cases. If you're a long-term *nix hacker with a keyboard fetish then I can see how it might not seem that novel or useful, but for new developers coming up without the baggage, GitHub is bringing tremendous value, as demonstrated by the surging user uptake.
But as for you, I'm a bit confused as to what you really want. You say issues are unusable, which I can only assume is because they do not have the extensive feature set of proper bug tracking systems, but then you also say that pull requests are too much work. GitHub is clearly trying to do for programmers a bit of the 80/20 thing that Apple does for consumers, or what 37signals did for project management—give simplified tools and workflows that are easy to learn and use even if they aren't suitable for all use cases. If you're a long-term *nix hacker with a keyboard fetish then I can see how it might not seem that novel or useful, but for new developers coming up without the baggage, GitHub is bringing tremendous value, as demonstrated by the surging user uptake.
The only reason why I switched to BitBucket is "free unlimited private repository". GitHub is great, I used to love it as a student, it also was a great asset when applying for jobs. But now, I'm in a company that unfortunately do not allow me to do OpenSource anymore, and bitbucket was a great solution. If GitHub was to offer a few free private repos (other than if you are a student), I believe that bitbucket would be in a bad position...
Do you mean your company doesn't let you do open-source side-projects? Because if you mean repo hosting for the company, I would hope they could afford the very cheap Github subscription fee for private repos.
The problem is convincing management there is a significant advantage to paying for private GitHub repos when you could use BitBucket for free. Even if we needed to pay for BitBucket (i.e. need more than 5 users on a repo), the cost for a company like ours that might need 20 users total on a repo is pretty minimal, and the pay per private repo on GitHub quickly adds up and passes the BitBucket costs. From a pure cost analysis for private projects, I don't see how BitBucket doesn't come out on top. Maybe if you only have 1 repo and 100s of users, but in the more average company where you have multiple repos and a smallish number of developers, BitBucket is almost always going to win the price war.
How many private repos do you need? I'm also in a very cost-conscious company, but compared to other infrastructure costs, GitHub is very very inexpensive.
According to linus' talk, git's whole point is branching. The point is that cost must not be an argument not to branch.
The public-or-pay on github effectively forces one to pay for starting a project. Starting a project should be free, easy and obvious. Github satisfies none of those.
I don't agree that this is the main difference between github and bitbucket though. I would argue bitbucket is support for their other services (basecamp and whatnot), and team-based development is what you pay for.
Github's features seem directly oriented to make github's administrator's jobs easier. Anything that is a bit of a problem, or doesn't fit in the original design doesn't get made at all or gets cut (ie. file attachments, project downloads). And "darling" features, like the network graph, that are unusable due to speed and bad UI get pushed into the spotlight, despite that.
The public-or-pay on github effectively forces one to pay for starting a project. Starting a project should be free, easy and obvious. Github satisfies none of those.
I don't agree that this is the main difference between github and bitbucket though. I would argue bitbucket is support for their other services (basecamp and whatnot), and team-based development is what you pay for.
Github's features seem directly oriented to make github's administrator's jobs easier. Anything that is a bit of a problem, or doesn't fit in the original design doesn't get made at all or gets cut (ie. file attachments, project downloads). And "darling" features, like the network graph, that are unusable due to speed and bad UI get pushed into the spotlight, despite that.
Uh, there is no cost to branch on GitHub. I'll leave my critique of your comment (and it's abortive duplicate cousin) at that.
According to linus' talk, git's whole point is branching. The point is that cost must not be an argument not to branch.
The public-or-pay on github effectively forces one to pay for starting a project. Starting a project should be free, easy and obvious. Github satisfies none of those.
The public-or-pay on github effectively forces one to pay for starting a project. Starting a project should be free, easy and obvious. Github satisfies none of those.
Last year, I switched from Github to BitBucket because of the unlimited free private repositories. Shortly after, I switched back to Github for everything else Github offers.
Would you mind detailing what that everything else actually is?
We (objective-cloud.com) are using Bitbucket for our private repos as well. But once our stuff has matured a bit we open source it as frameworks on github and manage issues/documentation there.
We love open source and want to contribute back. Since most people are on github and not on bitbucket we open source our stuff on github. Just to make it easier for the community.
The missing/invisible bitbucket community is certainly a big thing... :(
We love open source and want to contribute back. Since most people are on github and not on bitbucket we open source our stuff on github. Just to make it easier for the community.
The missing/invisible bitbucket community is certainly a big thing... :(
My company uses BitBucket because of the unlimited private repositories. We are a small company with just a handful of developers, but our existing Subversion repository contains over 200 projects. Most are not really active, as in being developed. But the majority do get the occasional bugfix. Even Github's largest enterprise plan is too small to convert out Subversion repositories, because on Github you pay for the amount of private repositories. With Bitbucket we can use their cheapest $10 plan because they carge by developer, not by repository.
If I recall correctly, the author of the article linked here apologized for its tone and removed it from his blog. It seems a bit of a disservice to repost it here without mentioning that context.
[deleted]
I googled for a bit, but couldn't find an apology from this author. I do remember a different author writing a similar post, followed by an apology and removal though. I don't think it's the same author.
(edit: here's the apology we were thinking of http://schacon.github.io/bitbucket.html)
(edit: here's the apology we were thinking of http://schacon.github.io/bitbucket.html)
Yep, sounds pretty stupid and pointless to link it here :)
Well maybe he should apologise one more time and do a better job removing his post.
BitBucket - Unlimited private repos for free. I don't care of anything else.
Bitbucket: unlimited free private repos
GH: popularity
GH: popularity
Yeah that is about it. My private repos are replicated to bitbucket, with a couple of public ones. Most of my public projects are all on Github.
Github is as you say popular, and has partially become a CV/resume replacement so that it is risky to not have an active account on GH. Also project discovery and sharing on the one popular site is much more likely to happen.
No-one finds my bitbucket projects unless I tell them about it. Perhaps if github extended the fork link for a project to upstream/downstream links to external sites it would get more traffic. But that would probably not be in Github's economic interest.
This is as a person, for a company there might be different scenarios of what is important. If costs are important then bitbucket is probably a better start. However after a while Stash, Github Enterprise, Gitorious, Gitlab etc will be more suitable for day-to-day hosting.
Github is as you say popular, and has partially become a CV/resume replacement so that it is risky to not have an active account on GH. Also project discovery and sharing on the one popular site is much more likely to happen.
No-one finds my bitbucket projects unless I tell them about it. Perhaps if github extended the fork link for a project to upstream/downstream links to external sites it would get more traffic. But that would probably not be in Github's economic interest.
This is as a person, for a company there might be different scenarios of what is important. If costs are important then bitbucket is probably a better start. However after a while Stash, Github Enterprise, Gitorious, Gitlab etc will be more suitable for day-to-day hosting.
"has partially become a CV/resume replacement so that it is risky to not have an active account on GH" - LOL, where? Do people even have time to check your repos?
Obviously 'we' know that most github repos are mostly rubbish experimental garbage (at least mine are), but many startup recruiters that I have met have filtering/scoring on whether a potential candidate has a github account and even a further qualifier if that account is active or dormant.
I don't think they go beyond that as they probably don't have the skillset for that, nor do they check any other code hosting sites.
But for the anonymous early filtering to get your foot in the door it makes sense to have a semi active github account until you get reviewed by/speak to a proper technical interviewer at which point that sugaring is unnecessary.
I don't think they go beyond that as they probably don't have the skillset for that, nor do they check any other code hosting sites.
But for the anonymous early filtering to get your foot in the door it makes sense to have a semi active github account until you get reviewed by/speak to a proper technical interviewer at which point that sugaring is unnecessary.
Makes sense. I might add a phrase "I don't use GitHub because I prefer ... instead of GitHub." to improve keyword matching in my CV...
I like BitBucket because I like & use Hg. After playing around with both Git & Hg & comparing their merits, I decided, it was Hg for me. What's with all the hate on the author's part?
I'm in a weird position (although I assume I'm not the only one) that's using both services and paying Github for their first level.
There's something to be said about having all my projects in one place, which is why everything is on GH and I'm starting to duplicate private repos to BB.
Competition is fierce in the space right now, but I'd feel better if BB was charging some tiny amount for a year of unlimited private repos (like $5 or $10). I think I'd feel much more comfortable they weren't going to retire it.
There's something to be said about having all my projects in one place, which is why everything is on GH and I'm starting to duplicate private repos to BB.
Competition is fierce in the space right now, but I'd feel better if BB was charging some tiny amount for a year of unlimited private repos (like $5 or $10). I think I'd feel much more comfortable they weren't going to retire it.
How surprising that two sites for managing DVCSs look similar when presenting the same information.
If you use "Search Term" vs. "Website" you get different results, but for what it's worth: http://www.google.com.au/trends/explore#q=GitHub%2C%20BitBuc...
Fun comparison. It seems that Bitbucket was ahead of GitHub, seeing that Github's current look resembles that of Bitbucket 3 years ago.
For comparison's sake it would have been fun to see screenshots of today's products next to the old ones as well.
For comparison's sake it would have been fun to see screenshots of today's products next to the old ones as well.
There's an advantage for the end user if the layout of the sites is similar - Intuitive browsing.
Imagine if each email service provider re-invented the layout of mailbox !
Imagine if each email service provider re-invented the layout of mailbox !
Git is a product that's really replicable in any space. I for one, use gh when projects are hosted there and bb when they are there. Git makes it trivial to move things around quickly if cost becomes an issue. Also, i generally find working with git through a browser to be tenacious. I find sourcetree to be far more powerful than GH's client but still think all the thanks goes to Mr. Torvald. what a guy.
I'm surprised that somebody cares enough to post this kind of article on HN. By the way I feel really sad about BitBucket being so much less popular than Github, while having important advantages (hg + closed repos) over it. I mean I'd rather use mercurial, but I'm using git because repo on github is still so much better for PR purposes. But c'est la vie, so whatever.
As a freelance developer, GitHub is useless for me as a git hosting service, because with the number of repositories I need to keep up as remotes I would be paying a ridiculous monthly fee.
I like BitBucket's model of unlimited private repos and charging by the number of people accessing them instead.
I like BitBucket's model of unlimited private repos and charging by the number of people accessing them instead.
If you have been added to an organization, your fork of their private code—if you choose to do it that way—costs you nothing (that is, it does not add to your used private repo count).
I've only done this because I was curious and had a slot available to waste if it did cause a problem. With the organizations that I've worked with, I've just always been added to their organization and repo and just used local copies with their GitHub repo as origin.
I've only done this because I was curious and had a slot available to waste if it did cause a problem. With the organizations that I've worked with, I've just always been added to their organization and repo and just used local copies with their GitHub repo as origin.
How many of those GitHub repositories are actually 10-20 line "Ruby gems" and "JavaScript libraries"?
I hope not everyone at GitHub is so afraid of BitBucket that they need to slander it with an article. Don't they know whining gets you nowhere?
I personally didn't see any striking resemblance between any of the pages. Most have obvious content which needs to be displayed (seriously, this guy is complaining about the source code tree being shown the same way? SERIOUSLY? How else do you expect them to display it?).
Probably doesn't help that I enjoy the layout of BitBucket more, but this article has been the kick in the shins I needed to get off of GitHub for good. There's obviously something that BitBucket is doing correctly to warrant this amount of attention from the employees of Github, might as well jump ship before it sinks.
I personally didn't see any striking resemblance between any of the pages. Most have obvious content which needs to be displayed (seriously, this guy is complaining about the source code tree being shown the same way? SERIOUSLY? How else do you expect them to display it?).
Probably doesn't help that I enjoy the layout of BitBucket more, but this article has been the kick in the shins I needed to get off of GitHub for good. There's obviously something that BitBucket is doing correctly to warrant this amount of attention from the employees of Github, might as well jump ship before it sinks.
This article is from 2011 and there are pros and cons to the Github and Bitbucket interface. Back then, the similarities were much more striking and they have become a bit more distant since then. As for "obvious content" for each page, you don't actually know what you're talking about, especially when it comes to UX. What is obvious to you is only obvious in hindsight. Consider Sourceforge (especially the old one) and the current Google Code.
The article is from 2011 and the author apparently (see top comment) apologized and took it from his blog. Also look at Google Code, trac, ... there's nothing "obvious" about the layout, there are plenty alternatives.
Exactly, in 2014, Github has tons of clones. Lots more sites have reduced visual clutter nice user flows and allow for social interaction. Both in VCS and in general, what Github is doing is not innovative. In that context, yeah this seems pretty dumb.
Github was the first VCS hosting service that took design seriously and kept clutter and bullshit off of all of these different pages (or provided them all). They were the first VCS hosting that realized the power of social interactions around code, before every app under the sun had a social timeline.
Github was the first VCS hosting service that took design seriously and kept clutter and bullshit off of all of these different pages (or provided them all). They were the first VCS hosting that realized the power of social interactions around code, before every app under the sun had a social timeline.
I'm also not sure that I buy the main premise of the article, that GitHub's and BitBucket's "communities" warrant comparison. Of course they don't.
GitHub's pricing model offers you open collaboration for free, and charges you for private repos. Thus it is ideal for open source development, and open community.
BitBucket's pricing model offers you unlimited private repos for free, but charges you by the number of collaborators. It also integrates well with JIRA, a very popular task/bug tracking system in small to midsize shops. In sum, it's not really trying to be an open source "community"... it's trying to compete for the in-house business of small to midsize shops.
If you're trying to draw collaborators to your open source project, then BitBucket is a poor host. Likewise, if your company has one or two dozen developers and a large number of repos, then GitHub makes no sense as a paid host.
All of my personal projects are on GitHub, and my company is all on BitBucket. I'm not so much interested in their "innovation vs. creative bankruptcy" as I am in the choices they've made with structuring their pricing models.