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?
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 should really check GitLab out again if the last time you used it / upgraded it was one year or so ago.
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.
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.
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.
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.
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).
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.
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).
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.
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.
I would amend that to "source-code collaboration applications". The hosting is not the important part.
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.
GitHub and GitLab have similar features. GitHub calls them pull requests. GitLab calls them merge requests.
"Press Enter to exit, Exit to cancel, or Cancel to continue."
They are available in base git. The command is called request-pull[1].
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.
* 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 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.
There's a bit more to it ... and sure all can be done manually.
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.
Oh wait, git over ssh doesn't show a web view.
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.
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.
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.
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.
Not really. It can be done via email using standard git commands like git format-patch, git send-email, and git am.
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.
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.
What advantage does that have over the standard hooks[1] that git itself comes with?
Someone mentioned online that Gitlab has a richer markdown format. I haven’t really investigated but I found this a moment ago:
free GitLab account has no edit history. I think it's a important feature for private development
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!
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.
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.