Hacker News new | past | comments | ask | show | jobs | submit login

What advantages do people like from Gitlab as opposed to just using git? I'm not too familiar with gitlab/github, so I'm sure it's a naive question, but I'm wondering what the main value-add that's missing from the basic tools is?

GitHub and GitLab add project management capabilities to your project.

Both come with a IssueTracker (for bugs, feature requests, ...), a Wiki (for documentation), simple user management, and webhooks for automated build platforms.

You can do things like adding an issue-id into a commit statement which displays your commit in the issue ticket for others to reproduce what exactly was changed to fix a bug or implement a new feature. This can be super helpful when someone wants to extend a feature. Or reproduce why something isn't working any more, and fixing it instead of reverting the code and reintroducing a bug that was fixed (We had exactly such a problem of a reoccurring bug because two dev's didn't understand each others commits)

I prefer using GitLab for my company and private projects, since Microsoft has acquired GitHub. For public projects I prefer GitHub because the user community is larger.

GitLab also comes with extensive project management and DevOps support, and can run on your own infrastructure.

You can run Github on your own infrastructure too, so is the only benefit of GitLab that it isn't owned by Microsoft (the largest contributor to The Linux Foundation since 2005)?

Github Enterprise is $21 per user per month, and GitLab Community Edition is free.

It is free and open source, unlike GitHub

I prefer Gitlab for private installs, but the community edition lacks many critical features that are only present in the paid version (export/import of issues, I'm looking at you)

Yes, but there are multiple open source tools that make this easy and they have an API for it as well. I think the need to have a large monolithic platform for issues is absurd. I probably won't be using GitLab or GitHub for my next project. It totally defeats the decentralized nature of Git.

So.. where do you keep your issue tracker? The bitcoin blockchain?

Maybe you're talking about something else but according to the features page [0], both importing and exporting issues as CSV is enabled for all versions of gitlab.

[0] https://about.gitlab.com/features/

As other users noted, this feature has recently become part of the community edition. They are currently in a rolling effort to move stuff from paid to free.

You should really check GitLab out again if the last time you used it / upgraded it was one year or so ago.

They contribute, but their repos don't take contributions themselves from outsiders, which is not exactly the spirit of Linux. They contribute to Linux because they see it as a threat they can't ignore and so are implementing stage 1 of their EEE strategy

Which repos from MS don’t accept PRs from the public?

GitHub source code is completely closed source, so of course they don't accept PR's.

There were talking about Microsoft public repos on Github.

Fair question, you shouldn't be getting downvoted for it imo.

Larger projects need a way to collect bug reports, feature requests, maintain documentation, and set up milestones and release schedules, at a minimum. Ideally you want all of this integrated into your vcs, so that when a developer decides to push a commit related to a specific bug or feature request, that commit gets attached to that bug or feature request.

When these are set up and run well, they are very powerful for mid-to-larger organizations.

I would like to second this and point out that while someone can self host and set all of this stuff up, at some points there are economies of scale for using a provider to do this because the provider's raison d'etre is to create these interfaces that make it easy for everyone to interact with git. The developers on KDE, etc. probably don't want to spend their time working on the UI for their bug/issue/feature/commit request tool when they could be working on KDE things.

Finally, there's the fact that many more users will be familiar with GitLab (or GitHub, BitBucket, and so on) than they would with each and every opensource project's flavor of bug/issue/feature/commit tracker. For instance, I know exactly how to find the "releases" section on github quickly - if KDE wrote their own bug/issue/feature/commit tracker, I'd have to find the "releases" area and remember where it is every time since I don't use that UI as often as I use github.

Actually, gitlab is open source and the majority of the features aren't pay walled off. You can self host ~70% of the gitlab features on your own hardware, without paying a dime. Or you can self host and pay a subscription to enable all the enterprise features. At work, we use this for code which is too sensitive to host outside of our infrastructure. Closed source development needs management too.

> Fair question, you shouldn't be getting downvoted for it imo.

Well, the question is pretty much answered in the actual article. From the looks of it, this seems to be responding to just the title without having actually read the page.

I would say that hosting on a centralised service like GitHub it Gitlab also reduces friction for contributors - bug reports, code, docs - as people will usually already have an account so they can make drive by contributions.

Having to find a bug tracker, create an account, log a bug is a lot of hassle for a random library or small project. I know I've given up raising bugs for some things as I couldn't be bothered with the rigmarole of sign-up, verification, etc... On Gitlab/GitHub there is much less friction because I use both regularly and and can use them for multiple projects, large and small.

Tangentially related: for my own small projects I use Artemis for bug/issue tracking (my reasoning is at http://chriswarbo.net/blog/2017-06-14-artemis.html ).

It uses maildir files in a hidden directory, which can be tracked like any other files; e.g. when committing a bug fix we can also commit the closing of the associated issue. I've also configured Emacs to make using it even smoother (opening issues/comments in a derivative of message-mode for syntax highlighting, with a C-c C-c binding to save and stage; I've partially finished a derivative of tabulated-list-mode for browsing issues interactively).

off-topic: I'm around HN for >10years and I vaguely remember a UI change where I could not see some voting counters any more. How do you know if a comment has been voted or downvoted?

When I first replied to the parent comment, it was gray text -- HN's UI for "this comment has less than one point". I couldn't tell you the comment's score right now. It doesn't look like hn.algolia.com has comment scores anymore either.

I remember that UI change. At the time HN was really starting to look like it was getting gamed, with comment scores having too much influence on popularity. HN's response to hide scores seems to have helped.

Gitlab has an opinionated (and mostly open source) toolchain and set of practices for proposing, implementing, validating, operating, and monitoring software and changes to that software built on top of Git at one end and Kubernetes at the other, with lots of configurable escape hatches to override its smart defaults when/if you need to.

I haven't really seen anything else quite like it (though it does have a long way to go still).

People try to roll their own from-scratch solutions or plug in an off the shelf tool here or there and their idea-to-production pipelines are generally worse or incomplete in comparison. Most of the architects of these things only care about their corner of the solution space and the rest are either neglected or have their own champions and their own siloed solutions.

Nothing off the shelf quite resembles it either. If you e.g. buy and use the entire Atlassian suite and train and get everyone to agree on the desired flows and practices, so much is left to you to design that no two such systems are likely to be similar, nor (in my experience) is any one such system likely to be very effective or efficient in daily use.

I'd really enjoy seeing Gitlab mature and expand, I would love to work at an org that adjusted itself to fit something like what Gitlab is trying to be, instead of trying to make their hodgepodge of tools adhere to their personal tastes and political dynamics, etc. (a Sisyphean task as those landscapes are under constant arbitrary change).

This is it. Most other answers focus on one or two things gitlab does, but the essence of Gitlab is that they provide a platform for the whole development cycle, including planning, design, deployment, monitoring, analytics, incident management, etc.

They can do this by using the best / most fitting open source software for each task and integrating it, also by focusing mostly on kubernetes while still providing enough flexibility for other options. You just don't get to use the whole feature set if you're not on kubernetes.

Git is a version control system, whereas Gitlab/Github are source-code hosting applications. You use git to interact with Gitlab/Github.

Without going too in-depth, they allow teams to set up accounts on a central website, where team members can contribute to that central git repository. There are also other project-management features baked into the tool (code review, issue tracking, etc).

Of course, this can all be done using a bare git server running on some publicly-available computer, but they offer nice UIs and very friendly onboarding so that makes them attractive for teams.

> whereas Gitlab/Github are source-code hosting applications

I would amend that to "source-code collaboration applications". The hosting is not the important part.

Pull requests are the thing they offer that is closest to Git itself but not available in the base Git. It's a code reviewing tool to use before merging branches.

Developer A has a branch that he wants to merge with the master branch. He opens a pull request for that merge, and Developer B can look at the diff online and _comment on it_. On individual lines or blocks, or on the PR as a whole. The comments can become discussions, new commits can be added to the pull request and the comments are marked as outdated if that code was updated, when everything is OK developer B can press an "Approve" button and the branch can be merged.

> Pull requests are the thing they offer that is closest to Git itself but not available in the base Git

They are available in base git. The command is called request-pull[1].

[1] https://git-scm.com/docs/git-request-pull

As far as I can tell, all this does is generate some text that you can email to someone. It doesn't offer the ability to iterate on code reviews or track line comments, so you'd have to manage all that either via email or via a separate system.

It really depends on how you define the term pull request/merge request/request pull. The end action is to merge the code in the set of commits into a local branch, which is what all three allow you to do.

The ability to discuss code changes, etc, is separate from that. In my opinion, the terms pull request and merge requests are not entirely accurate. For services like Gitlab and Github, it's essentially asking the maintainer to review your code, so it really ought to be called review or change request.

A note on terminology:

GitHub and GitLab have similar features. GitHub calls them pull requests. GitLab calls them merge requests.

Pull/Push is a nightmare for Portuguese (Portugal,Brazil) because 'puxar' (read push-ah-r) means pull................

Ah yes! It happens in English too:

"Press Enter to exit, Exit to cancel, or Cancel to continue."

Gitlab is replacing Phabricator, not Git. It's a higher level tool.

Aha. I was already thinking: what does Gitlab add next to Phabricator? And the KDE Bugzilla instance. Will that be moved over as well? KDE has many parallel systems like that unfortunately.

Gitlab is replacing Phabricator but not Bugzilla. Gitlab issues are going to be used for developer task tracking but Bugzilla will continue to be used for end-user bug tracking.

Why not Bugzilla though? Gitlab bug tracking looks much better to me. The switch worked pretty well for Mesa which was also using Bugzilla before. Bugzilla feels clunky in comparison.

* KDE has gone through CVS, SVN, Git, Redmine, ReviewBoard, Phabricator and now GitLab for various source control needs over the years, all while still using Bugzilla for bug tracking. There is a lot more intertia to overcome.

* GitLab (and GitHub etc.) are organized around code repos but the hierarchy you use to organize your code isn't necessarily the best hierarchy to organize your bugs. There are a few different "plasma" repositories but end users aren't going to know which one the bug about their panel spazzing out on leap seconds goes in. So you consolidate everything into one Plasma project. But then your code and bugs aren't living together anymore, and using GitLab for the bugs buys you very little over just having good integration with Bugzilla.

* It's a lot easier to move bugs around between projects and they keep the same identifying number.

If bugs aren't aligned with code in Bugzilla, why is that a problem in Gitlab? There can be some instructions where to file bugs.

At least for some software, I noticed bugs were also reported in Phabricator, not only Bugzilla.

Prob since KDE has an automated crash reporter system.

Why can't it be integrated with Gitlab? And if some old one is hardcoded to use Bugzilla, there can be automatic import to Gitlab as well. I.e. Bugzilla can run for those automatic reports, but not for anything else.

Most of the replies to your post are inaccurate. Yes Gitlab and Github offer a ton of value-adds like issue tracking and project management, but the core reason for using them is to get a fully managed Git server vs hosting one yourself.


If you have ssh access to a box; you have a git remote.

It’s obscenely simple, and contra to your claim the “managed” aspect is not the selling point of this software. The selling point is the project management features and integrations.

In githubs case it’s a managed service.

In gitlabs case, I can be a managed service or it can be a software suite you maintain yourself.

Not a universal truth.

Sure, so now instead of just having a source control remote, you’re now looking after a publicly accessible box in the cloud with all the security headaches that brings. Plus you’ve got to manage credentials essentially manually, make sure people have the right access permissions to repos, look after backups, etc.

I worked at a company that started out with a setup like this for the dev team. It felt like a massive burden was lifted when we moved to Github Enterprise. We weren’t using the project management features at all, just the source code hosting stuff.

Great send me a link to your code. I want to browse it real quick and look over it, before I pull it.

Oh wait, git over ssh doesn't show a web view.

This is actually an absolutely awful idea. Every time I used the code browsing and search features I was disappointed by how poorly the search is working. Lots of false positives. Usually fail to find what I'm looking for. When I git clone something and use my text editor's search feature I usually find what I'm looking for on my first try.

It's not perfect, but for a lot of smaller projects it's fine.

Also way easier to send someone a web link to something in a discussion to have them look into it, especially if it's in a different branch then they may have.

> I want to browse it real quick and look over it, before I pull it

What's wrong with fetching it, checking it out in a local branch, and browsing it using your editor? It probably is much easier to browse the code, see it in context and see the diff using your editor compared to the web interface.

The ssh host doesn't do git hosting. You have a hard time to manage ACLs and have to restrict users accordingly. Also you need to run an http server and update the git cache if you want to support anonymous requests to the repo.

There's a bit more to it ... and sure all can be done manually.

Git hosting over SSH does work. I've seen it work well. We already had ACLs set up for other reasons, and we didn't need anonymous requests. It's the simplest thing that can possibly work; don't add extra complication if it's not needed.

No offense, but if you are at a point when you don't know what a good project management system is good for, you should absolutely read this: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

Git is still what you use to manage your project's "snapshots" at any given time. But GitHub/GitLab add a plethora of tools to make it easier to manage your project and facilitate collaboration. In addition of offering the service, GitLab gives the possibility to host your own copy of their solution (it's open source).

CI, issue tracker, pull requests, etc.

Git itself doesn't offer things like merge requests, issues, permission management, etc.

Think of "Linux" and "Ubuntu". The kernel is necessary, but so is all the user-space on top of it. That's git and GitLab respectively.

You _can_ use only git but you get into several problems if you are in a team larger than one.

Sharing code requires the git server and open network ports on your development computer. With non-static IP you can't point to your peer's computer without needing to change the remote settings every time you sync.

Basically, for convenience, you will need a git server accessible to your team to sync up code in a 1-many fashion instead of the many-many raw git. Github/gitlab provide exactly that with added features on top. They differentiate by the added features only.

> Sharing code requires the git server and open network ports on your development computer.

Not really. It can be done via email using standard git commands like git format-patch, git send-email, and git am.

With the usual caveats applied to embedding and extracting patches from emails.

I don't find email-git much more convenient unless I've been living under a rock and it got much easier using the free email providers for git in the last few years.

> With the usual caveats applied to embedding and extracting patches from emails.

Which are? The settings in git format-patch and git send-email will handle embedding and sending. Also, as long as your email client can save emails to disk, git am can do the rest.

> I don't find email-git much more convenient unless I've been living under a rock and it got much easier using the free email providers for git in the last few years.

I've tested it with my ISP email (Comcast) and Gmail. Other than having to enable "insecure" access for Gmail, there wer e no problems at all. Hotmail/Live on the other hand, would mangle the email message.

First level of value is simply a hosted, reliable git hosting for any size of team. Second, is the pull or merge request workflow which really makes coordinating development a lot easier. Third, is automation - webhooks and such make it really easy to connect different tools to your repo (i.e. analysis, linters, CI/build or even deployment scripts. Fourth, there's all the documentation and project management.

> webhooks and such make it really easy to connect different tools to your repo (i.e. analysis, linters, CI/build or even deployment scripts.

What advantage does that have over the standard hooks[1] that git itself comes with?

[1] https://git-scm.com/docs/githooks

I’d like to know also. Gitlab appears to have a free account too; I do pay for Github. Do people use both?

Someone mentioned online that Gitlab has a richer markdown format. I haven’t really investigated but I found this a moment ago:


linkbreak in GitLab is a headcahe for our users https://docs.gitlab.com/ee/user/markdown.html#line-breaks

free GitLab account has no edit history. I think it's a important feature for private development

What specifically about line breaks is a headache? Would you prefer that pressing "Enter" automatically inserted a line break?

As for edit history, I'm assuming you are talking about the description edit history. If so, we had an open conversation (https://gitlab.com/gitlab-org/gitlab/-/issues/10103#note_206...) about why we placed the feature in Starter and above. If you'd like to continue the convo, please open a new issue with your proposal. If you are talking about a different edit history, please clarify so I can better understand your perspective. Thank you for the feedback!

Yes, I perferred "Enter" for linebreak. Double "Enter" just not the best for us. Sometimes, we drafted the comment or description somehwere before copy into Gitlab. All lose! Some of our customers given up to fix the format and post screenshot PHOTO directly. It's very frustrating.

Regarding the edit history,

both description & comments edit history are important to me. We can only afford our freequent customers and one time projects. You know, many projects holding for months and no earning at all but you can't cut it.

Thanks for your feedback! Please open an issue with your proposal: https://gitlab.com/gitlab-org/gitlab/-/issues

When those projects started, not much. They offered Git storage and an issue list, pretty much.

Then they started to grow, specially GitLab in the beginning, and now try to be a single centralized solution for all software development needs like Atlassian, IBM and others had always been selling.

I think postgres uses plain-old git for their repos.


Is this a serious question?

no master->main renaming bullshit

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact