The GIF shows "Start Review" button and "Finish your review" buttons (and a "Pending" flag), which makes me think this is more geared to the complaints that every comment sent an individual email instead of being batched when the reviewer was ready to send them out.
Edit: Indeed, from the github blog post - "You can also leave a review summary and delete, edit, or bundle comments before you submit them."
I'll be curious to see if they've made API granularity more sane.
We haven't been able to use any third party tools because our security people don't feel great about giving third parties write access to everything (including our source) for tools that don't need it. In the past, GitHub hasn't differentiated write access to issues (which many tools need) and write access to the source itself (which basically nothing should need).
Plus a million - I'm not sure how this still isn't a feature.
Considering all of the PCI-DSS / HIPAA / SOX / etc. audit points around change control (even ignoring corporate versions of the same) it's practically impossible to add external services to GH and have them be useful while still meeting compliance. Change control is required, but that also implies control of change control. As-is any service could delete all of your content, whether intentionally or inadvertently, or even worse could corrupt or otherwise alter your history.
It may be detectable and recoverable because git, but it would be infinitely easier to have code and PR be r--rw-.
EDIT: This is now a thing, according to @bhuga below. Also, GH is now publishing a roadmap for what's coming down the pipe, so we're not in the dark as to when these critically-important-why-isnt-it-out-yet features are being worked on. https://developer.github.com/early-access/platform-roadmap/
WakaTime has been bitten by this lack of granularity too... it hurts integration usage when we ask for code access when we only need commit log messages.
I can't even get permission to read from private repos without also requesting write access to the user's entire codebase on GitHub. I don't want that power.
I have been a huge pusher for GitLab, and my basic reasoning was that GitHub isn't open sourced like GitLab. GitHub was going awfully slow and no communication to its customers in new features. Looks like GitLab lit a fire underneath them. I wonder which one is "better". Nevertheless, at least there is competition now. SCM is the biggest component in any coding practices, I'm that it is finally getting attention.
The review stuff is semi similar to what I requested GitLab do and I'm surprised it's taken so long for anyone to really do it. It's a great workflow. I'm still not convinced about keeping all of your project's management in the version control system (I mean I prefer issues in there but the rest seems...wrong to me for whatever biased reason I have).
Overall looks good! When does Enterprise get these features? :)
We're glad you like it! This is the first of many Code Review enhancements we'll be providing, so stay tuned.
These features will be coming to GitHub Enterprise soon - we always aim to get new features onto the Enterprise platform on the next major release (which occurs every 3 months on average).
Very unlikely. We hope that Projects will be the best place for people to coordinate work on a GitHub repository, but that doesn't really limit Trello's value much. They'll continue to offer lots of value as a great way to coordinate work for many contexts outside GitHub repositories.
1. There was a faster and more contextual way to edit issues on a project.
2. There was a way to set up an opinionated workflow where e.g. opening a PR against an issue moves the issue to "Review"; closing said PR moves issue to "Done" and closes it; closing an issue directly moves it to "Done" and vice versa. Without this, there's way too much interaction required for even GitHub's own preferred workflow.
3. Automatic bidirectional linking between issue/PR on the project board. (Honestly haven't had a chance to see if it does this, but will on the next PR I open.)
4. Automatically pre-fill a backlog with existing issues.
5. A project could span multiple repositories (e.g. for tracking user stories which might be addressed in an API or frontend repo, or both). We also track non-dev work on our Trello board, and a project per repo doesn't support this.
6. Filtering.
Edit... Also nice to have: ability to reference a checklist item in a link from PR to issue, check it on merge, and so on.
Hi - Codetree [1] does a lot of what you're asking for (specifically 3, 5, 6) and I love the other stuff you mention, we've been thinking hard on a couple of them. Would love to quickly chat about your workflow just to learn, not to sell, if you can spare the 15 mins. If you're interested shoot me an email at arif@codetree.com.
Some nice improvements here. It appears, though, that Projects suffer from the same problem we've had with Issues: they are limited to one repo.
I know there are some tools to manage Issues across repos, but for the most part, the tools seem to assume you work on only one repo, or that milestones only affect a single repo.
I would love to see projects/milestones become more capable when dealing with cross-repo issues.
Take a look at ZenHub [1] - it lets you stay inside GitHub, but adds much more full-featured project management capabilities including multi-repo boards and advanced reporting features like estimates, issue hierarchy (epics), personal to-dos, burndown and velocity charts, etc.
We do this as well at Purple [0]. It does make issue referencing in commit messages a bit unwieldy; you have to include the full path to the issue (e.g., org-name/repo-name#34).
Yup! Using Projects will force us to maintain multiple projects for one single "real" project, as our code is split across multiple repositories. (Web app, desktop client, infrastructure, company issues, etc)
I suspect it's still a lot better than the alternative but not having org-wide Projects is a little sad.
This has been why we don't use github's issues, wikis, and why we won't use their projects. For example if the overall product has a web site repo, server repo, iOS repo and an Android repo then they need to be used as a coherent whole. An issue might be reported against iOS but the cause is in the server, so the ticket would need to be moved. Rinse and repeat for all the other interactions of piece, and that collaborators often don't know (and shouldn't need to) precisely what issues, wikis etc correspond to which repo.
The now defunct Google Code had a very good solution for this. You could create additional "sub" repositories alongside the "main" one. Github already does that for the wiki, but doesn't generalise it to allowing additional ones. I'm somewhat convinced this is because github has the whole "charge by the repository" model, which is at odds for being useful for projects that require multiple git level repos.
It would require fairly extensive changes on how they do things under the hood. Google used suffixes - eg you checked out the wiki as github.com/org/projectX.wiki and could create a git repo like github.com/org/projectX.android
Imagine you just hired a new web developer, and added him to this repo. His first local repo clone will include 3 entire projects for iOS, Android, and backend server, that he has no use for, or should even have permissions to access in the first place.
This sounds like a security nightmare, that also significantly impacts local update times and makes for a huge repo.
Issues and projects are global and not bound to a single repository. In my experience, this is the only approach that works in a company. JIRA does the same thing.
It's the closest to a fully open source Atlassian suite that you get. Phabricator has code review, repository hosting, project management and even a CI tool.
I've seen a few projects use Phabricator, but I can't seem to understand how to use it.
Github's issues, despite it's flaws, is easy enough that non-programmers can use it. Phabricator is complicated enough that it's actually caused me to not report a bug at one point.
Codetree [1] addresses the multi-repo issues problem you mention, we roll up as many repos as you want under one 'project' which you can view in either table or kanban board style.
We also add a host of project management functionality on top of GitHub issues like advanced filtering/sorting, dependency tracking, and the ability to setup your own dev/release workflow.
I'm curious as to whether you are dogfooding Projects, especially when feature work spans multiple repos. If so a "how Github uses Projects" tutorial may be worth considering.
Indeed, many teams are - the original iteration of Projects was released to staff a few months ago (as is common with many of our product releases), so we're continuing to learn how teams are using it most effectively. Yesterday's release to the public will help with that effort too.
I personally use it on my team at the moment - it's been pretty useful and we've passed along frequent feedback to the platform team responsible for it.
This. There are fewer and fewer places for single repository applications in this day and age: We break out a repo for everything to our DDL / Stored procedures and of course our API vs. Front-end code.
It sort of boggles the mind, really - and makes me feel like they did not really take the community's desires seriously.
For what it's worth, I've had success browsing issues accross repos using the https://github.com/issues page. E.g. to view all issues that are in both redux and react-redux:
This is a rough summary of what all I read in the blog post:
1. projects. replaces trello, waffle.io, zenhub and many other similar services.
2. code reviews allow approval/request changes as sunny's screenshot shows
3. reviews can be made mandatory.
4. github platform integrations is getting a roadmap
5. a graphql api to query their database
6. enforce 2fa in organizations (much love for this one)
7. summarized timeline for your contibutions
Just a few days back, at the GitLab release, I'd noticed a lot of complains about gitlab releasing useful and impactful features and github being slow on releases. Moreover, now with a public roadmap (even if it is just for platforms), it is a great start.
I'm really liking this change in pace.
mods: Can we make this the canonical discussion for this topic? Otherwise, a lot of branching will happen
Doesn't look like Projects comes close to replacing ZenHub / Waffle.. Not for proper teams anyway – real project management needs to be much more robust so I'm keeping ZenHub for now.
I'm looking at https://www.zenhub.com/product, and while it does have some extra features (filters on priority, labels), but for most people the base set provided by github is gonna be sufficient.
Sure, it won't completely replace them, but GitHub building this as a platform counts as competition.
Using ZenHub also provides additional features like time estimation, burndown charts and Epics (for issue hierarchy) - we find that for larger teams, these are must-have features to work inside GitHub.
At Waffle.io, we're all about making project management better for engineers. We believe it's awesome that GitHub is investing in this too, and we'll continue to make GitHub delicious :). More here: http://blog.waffle.io/say-hello-to-wafflebot/
Our focus is going to remain on how to integrate a full-featured project management suite within the GitHub eco-system. The GitHub projects release will make a great foundation, and ZenHub will be there to provide the more advanced features like issue hierarchy (epics), time estimation and reporting. Lots of exciting releases coming soon for ZenHub users :)
Founder of Zube here. GitHub Projects seems like a nice solution for very small teams, side projects and open source projects. However, serious teams need more powerful features like a well thought out workflow, support for multiple repos and burndown charts.
Shameless plug: Zube has all these things and more - https://zube.io :)
It looks like enforcing 2fa in an org (finally!) means anyone who doesn't have 2fa will be booted out (included whoever may be paying for it at the time) with an email explaining why. I'm afraid to tick the box because of this. :o/
Contact everyone, tell them they have a week, then tick the box. If they didn't do it within the week it's either not important to them or they'll add it right quick after you tick the box.
We have some "shared" users for things like bots, etc.. wonder how to deal with that since we don't want to enable MFA for them. Otherwise I'd be all over this..
For CI bots I think in the future you will be able to build an "integration" instead of using a user account. From the blog post
"We’re rethinking our integrations model to provide better ways for tools to extend and integrate with GitHub. We’ve added the ability for an integration to act on its own behalf instead of impersonating a user—making it a first class actor on GitHub without using a paid seat. Admins will have the ability to configure integrations directly on Organizations and control which repositories they allow access to."
Currently, we tell every new employee on joining the org to enable it, and review it a week later to ensure that they followed through.
It is the exact same with Google Apps as well (where you add the user to the 2faexceptions group and review+remove them a week later).
I was ready to flip the switch, till I realized that a third-party bot account in our organization doesn't have 2fa. Dropped them a mail, hoping to flip it by tomorrow (100% non-bot users have it enabled, so no one is getting auto-kicked).
I agree with you that the pick up in pace of Github's lacking features has been phenomenal, and I don't really quite understand all the love of GitLab except rooting for the underdog. Github is the clear industry leader, has been since essentially it's creation. It is very fast and feature-filled. It is the central location for the vast majority of code I use and see. Since the open letter to Github with the complaints of feature requests, they've really stepped up their game and made competitors really non-starters from my point of view.
The Enterprise edition features[1] are closed source, and these aren't strictly "enterprise-y" features like SAML authentication. It includes plenty of "basic" workflow features found on GitHub:
- Rebase merge requests before merge
- Use fast-forward merges when possible
- Create templates for issues and merge requests
- Display merge request status for builds on Jenkins CI
GitHub (annoyingly) can't do fast-forward merges from non-squashed PRs either.
Display merge request status for builds on Jenkins CI
GitLab implements basically the same API as GitHub for updating build status of commits from external services, or do I misunderstand what feature you mean?
But in general I agree, there are some options GitLab reserved for EE that really feel like they should be part of the CE as well.
Thanks for the admiration. If there are features that people think that should belong in the open source edition we're all ears. We've done so before https://news.ycombinator.com/item?id=10931347 A feature comparison between CE and EE can be found on about.gitlab.com/features/#compare
It seems like many posting there are not aware that this repository/bug tracker is not an official channel anymore -> maybe posting an automated comment in all issues with recent activity or locking them could help avoid confusion? If you arrive via search, you don't see the notice in the main repository description.
Take a look at Phabricator. It's a former Facebook project and been battle-tested at very large companies for years now. Huge open source projects like Blender, Haskell, Wikimedia and LLVM use it since it's the best open source code review tool and issue tracker. Wikimedia had a lengthy decision process and thoroughly vetted the alternatives.
It has many enterprise features including code ownership, issue templates, and a Gerrit like, sane code review workflow. You can fully integrate it with your CI tool and it even displays coverage results inline and such.
Ask me anything about it :) I'm not affiliated with it but am an experienced user.
I'm evaluating GitLab at work currently - primarily for its code review features and really like it. Read a lot about Phabricator yesterday as a possible alternative, and am considering testing it.
I wonder how it compares to GitLab. Is it possible to set up protected branches, where I can say, only users X and Y are allowed to push to the master branch? Can I do a code review and then finalize it when I'm finished and does the author get notified with a summary like the new GitHub code review feature? Because currently in GitLab the author does get a notification email for every line comment I make, which is also not really the perfect way of doing it.
I already know that Phabricator squashes the changes into one commit, I think I can live with that. (because it promotes small code reviews) Does Phabricator have any problems with git rebase, where I'm refreshing a feature branch with the most recent master state? What I really like about the merge/pull request workflow of GitLab is, that multiple developers can work together on one feature branch while a merge request is open and can be used as a discussion platform for the changes - is this possible with Phabricator?
Also I'm wondering how solid the issue tracking is, and if the project workboards can compete with Trello. Can it be used by non-developers without giving them access to the code?
>Is it possible to set up protected branches, where I can say, only users X and Y are allowed to push to the master branch?
Yes. I recommend (and my employer uses) a Herald rule that admits pushes to master only if the changes are in an approved Diff (unit of code review). This way you get an enforced 2-man rule, but anyone besides the author can approve the change.
This is currently impossible with Gitlab AFAIK, and is the main reason I won't use it.
You can also configure Herald rules to add blocking reviewers to other people's Diffs based on arbitrary criteria (i.e. touches X file and it's a Tuesday). A Diff cannot be considered approved until all blocking reviewers have signed off.
Reviewers can also be groups, so you could say, for example, changes that touch Y file must be reviewed by Security, but any member of Security can sign off.
>Can I do a code review and then finalize it when I'm finished and does the author get notified with a summary like the new GitHub code review feature?
Yes, everything you do on a Diff is batched and happens all at once when you click "Submit" at the bottom. Inline comments, the free-form text box, and the action all come as one email.
> What I really like about the merge/pull request workflow of GitLab is, that multiple developers can work together on one feature branch while a merge request is open and can be used as a discussion platform for the changes - is this possible with Phabricator?
A Diff is really meant to be an individual's small, well-defined contribution. Multiple people submitting code to a one diff can get messy. This would be better modeled as many diffs.
You are allowed to land diffs against branches other than Master, however this gets messy. It is not a first-class use case. My employer does not collaborate on feature branches; instead we land half-finished features into master (and production) disabled by feature flags.
It is NOT a merge/pull-request workflow. It treats Git more like Subversion; Phabricator is a very sophisticated alternative to emailing patches around before SVN committing them (basically the equivalent of landing).
>Also I'm wondering how solid the issue tracking is, and if the project workboards can compete with Trello.
Issue tracking is totally solid, very configurable. Project workboards consist of tasks/issues, which are much more expensive to create than Trello cards: you fill out a pagelong form, pick type, severity, owning team, title, description, etc. vs just free-forming a title. However, you can drag tasks around the workboard just like Trello and it looks pretty similar.
>Can it be used by non-developers without giving them access to the code?
Yes. Permissions (and approval flows, and notification rules) are very configurable. Phabricator is well suited to a large organization with rules, but this suitability doesn't carry too much overheard.
I don't think you could collaborate on issues with customers. Nontechnical people in your company, though, totally - we do that.
> It is NOT a merge/pull-request workflow. It treats Git more like Subversion; Phabricator is a very sophisticated alternative to emailing patches around before SVN committing them (basically the equivalent of landing).
Due to popular demand, they are adding some tools to allow merge/PR workflow. That being said, it was not stable last time I checked (~6 mo. ago), and it will probably take a while, if ever, for it to be as good as what's already there for Differential (the current code-review/landing system).
That being said, their existing tools are really good, and the fact that you are not married to a single VCS is really nice. You can have some legacy SVN repositories and be fine, and use the exact same interface for code-review and landing as in your shiny new git repositories. Prefer hg to git? No problem. Have some complicated gitolite setup you don't want to bother migrating? Phabricator works fine even when not hosting the repository.
I used Phabricator at a former employer, and it was one of the best software tools I've used. I'm always flabbergasted that it doesn't have more mindshare, especially when it's used internally at Facebook.
it's either self-hosted or at least $20/user/month. This alone makes it a bit of a hard ask for smaller companies at first, even for just kicking the tires.
It's worth noting that the first 30 days are free, and all 3 source control systems it offers have fairly painless synchronization, so there's low risk IMO.
On top of that it was really painless to install locally. I had it setup in under an hour, and that included my first time ever setting up my webserver with php, and first time configuring a mysql instance.
Phabricator is also pretty amusing in terms of UX (by default), which is helpful when dealing with things that tend to anger folks -- like spirited reviews. I've often wondered if the sense of humor is half fun, half intentional in terms of psychologically making tedious work better for all involved. Even if accidental it's a nice thought.
Based on my experience, Phabricator has some quirks but is quite solid, and the well-designed command line arc workflow would please folks who refuse to open a Web browser.
Phabricator is awesome. It felt like it was more for experienced developers or larger organizations when I was using it(in a good way). Something to consider depending on your team.
We already have these features, we just opted to make them EE/.com only since we think they are more relevant for organizations that have more than 100 potential users.
So, when reading the features page, I was considering 1 and 2 in terms of a feature that I use at GitHub religiously: squashed pull requests (that are automatically fast-forwarded) [1].
If I'm reading this correctly, this exists in GitLab as an enterprise feature, so I think my earlier comment isn't too far off. There also appears to be some community feedback suggesting this should be a CE feature [2].
There are 100% open source products out there, and I think it's worth distinguishing that GitLab is not one of them (as a GitLab employee adds elsewhere, it's "Open Core").
I'm not criticizing the product – they're welcome to open or not open source whatever they like. I'm just clarifying the description the parent used.
It's only kind of open source, and only partly. They call it open core, so saying open source outright is a bit misleading.
The review feature is very new in GL, and that plus all of the things you are mentioning within "everything in one spot" is available in this update (except maybe the coding env, not sure what that means anyway), if you've read the announcement. Github also has self hosting.
Thanks. I was unaware this existed. Looks like it was launched in 2011[1]. Somehow I thought that with their (presumably, from what little I've gathered over the years) complex infrastructure setup this would be hard or impossible. I wonder if they have an Enterprise team devoted to keeping up with a SaaS mainline and how much work they have to do, or if they made/make some decisions that make this (Enterprise) a fairly self-contained "it just works" sort of thing.
Hi there - GitHub Enterprise definitely has a devoted team focused on building features tailored to the needs of customers requiring/requesting an on-premise solution, as well as making it entirely self-contained. We typically release a new version of GitHub Enterprise on a quarterly basis - you can see the latest additions we shipped with GitHub Enterprise 2.7 here: https://enterprise.github.com/releases/2.7.0/notes
We have companies scaling their GitHub Enterprise instance up to 25,000 users, and we also have a dedicated Enterprise Support team available 24/5 to resolve any technical issues.
Thanks for the answer straight from the horse's mouth! I'd often heard about companies storing their code on GH and didn't understand how they could get away with using a SaaS app available on a public cloud; now I know, they can just run a self-hosted version on their own private network.
I am not your target market, FWIW, but just a curious developer.
No worries - glad to provide the additional details!
We also recognize that having a SaaS solution like GitHub Organizations meets the needs of many companies (over 75,000 at last count), and our announcement of 2FA enhancements today is an indication of our desire to continue that approach.
That's a pretty misleading characterisation. You can browse the source code, submit issues, see what's being worked on, contribute PRs, and freely download and run your own instance of GitLab. A handful of enterprise features aren't open sourced.
I agree that it is better to call ourselves an open core company and our website and communication should reflect that https://about.gitlab.com/about/#stewardship If we're still using open source to refer to the organization somewhere please let me know.
If I had unlimited money, I could hire an army of coders to write me a git platform with all the features I want, and host it on all the servers, everywhere. It's simply not feasible to talk about product features in a vacuum without considering the costs.
But the answer of self-hosting is a perfectly valid answer for "Why the love for GitLab?" when one = $0 in licensing, and the other = > $2,500/year in licensing.
Plus, not too long ago, GitHub restricted the number of free private repositories, for users and educational organizations. Although they offered educational plans for labs, it still had its limitations. Thus, free self-hosting was what attracted us to use GitLab in our lab.
GitLab's pricing model won a lot of people when GitHub's was ugly for anyone who wanted private repos (single guy at home with 10+ private repos for things like your dot files, etc? $20+ a month, for what likely amounted to under 1MB of disk space).
Here is some more competition in the form of a modular integrated tool 100% libre and open source.
With a single instance of Tuleap you can have per project wildly different configurations. One project can have a scrum dashboard with GIT and pull requests, while another can be kanban and SVN with Jenkins CI, and a third could even be setup as Waterfall with CVS or other combinations.
Issue tracking, or anything tracking really, document versioning and templates to get you started really quickly. It’s proven scalable as it’s already used by companies with more than 17 000 users with a single instance of Tuleap.
I would love some feedback as we are actively developing it with monthly releases. You can check it out at https://tuleap.org/
I think it was more the open letter to Github, which motivated both Github and GitLab (seen as an opportunity to compete).
GitLab's roadmap yesterday surely didn't motivate or spawn the "New GitHub Universe," and I wouldn't think that Github is very nervous about GitLab currently due to it's massive lead in the market. Maybe this new round of funding made some of the folks at Github look over at Gitlab, but I doubt too much else.
Ehh... dominance among open source projects, and Hacker News and Reddit thread cool points, is one thing. But in boring old terms of actually making money, how IS GitHub doing?
"Enterprise" is practically a swear word here, but that's where the meaningful paying customers are. From my anecdotal experience, Atlassian absolutely dwarfs GitHub in the enterprise world... and that's just the enterprises that are willing to host code in the cloud to begin with.
For large shops demanding an on-prem solution, GitLab seems to have a much better story than GitHub since that's really their business model bread-and-butter. For GitLab, the cloud hosting is basically just a marketing tool.
It's historically been tough to compare them to Atlassian because Atlassian has provided tons of other enterprise services like Jira and Confluence, and an 8 year lead plus going public, but I think Github is definitely working on better squeezing into the enterprise space with this current announcement.
> "Enterprise" is practically a swear word here, but that's where the meaningful paying customers are. From my anecdotal experience, Atlassian absolutely dwarfs GitHub in the enterprise world... and that's just the enterprises that are willing to host code in the cloud to begin with.
I was recently at an F1000 company and we did self-hosted GitHub Enterprise. While many services were duplicated across departments, there were a variety of other commercial VCS setups, and our GH was not highly available… there was a ton of buy-in to GitHub Enterprise. And, yeah, we did JIRA and Confluence (and SharePoint…).
I'm doing a gig for a F100 company now and, well, we've got GitLab. I dunno if I'm just more used to GitHub or if I actually prefer it to GitLab.
At a small company here, and we moved from GitHub to BitBucket because both the pricing (a couple dozen private repos) and user-management were more friendly. User management is one of those things people hand-wave away until they're the poor sap who has to manage it.
Then be a fan of of GitLab for putting the fear of competition back into GitHub ;)
(It's of course not certain they are the reason they are moving again, but GitHub looked a lot like the market leader that feels like it doesn't have to bother much anymore. And they weren't entirely wrong.)
built in CI integration is a huge draw. There are also a nontrivial amount of companies that refuse to let source code "out of the building" so they need to self host, either for real reasons or perceived.
Very fast? Maybe in the US, but rest of the world still has oceans in between of them. Adding 200msec+ of latency to every request makes it feel very sluggish.
Maybe they should start looking into global rollout like Google, Facebook and basically every serious company having world-wide audience.
I think particularly here on HN, I've seen a good deal of concern over github's social agenda and the perception that they've hired a lot of non-engineering folks to push that agenda.
The alt-right is apparently everyone's favorite new boogeyman for use in thought-free dismissal
It's always disappointing to see a self-described intellectual community give over so heavily to such an obviously broken thought process, but humans being the emotionally manipulable creatures they are, it makes sense.
The improvements to code reviews are really exciting. Having comments submit all at once instead of one at a time is a great UX change, I've definitely gotten sidetracked mid-review because somebody started responding to my initial comments when I'm neck deep. Comment threading is super useful for discussion-heavy comments like code review, and an in-UI approve/request changes is great.
Batched review and pending state have both been a long time coming.
Most of the times when I do a review it's not a single comment and right now the workflow is to let the team know on Slack that I am reviewing this.
From the Gif it's not 100% clear what the pending state does but I would want something like blocking the PR until every team member that started reviewing will "release" the PR. I also see the negative side of this of course but I think the positive outweighs the negatives.
You can block merges until there's an "approved" code review in the Protected Branches setting. I don't think it has anything like "everyone who reviewed must approve" though.
If anyone from Github reads this, a) this looks great, b) add project templates please, so we don't have to recreate the same columns every time. Thanks. <3
While I have your attention. A few thoughts on code reviews. It's be nice if 1) approvals somehow show up on the pull requests index page, 2) create a notification within GH, 3) send an email. Right now you have to go to the PR page itself to see approvals.
Edit: I saw an approval email notification on one PR, but not another.
We definitely want to get some way to surface reviews better across all PR's and/or projects. I've been bothered by that myself while we were building this. :)
+1 for seeing approvals visually on the pull request index page. I currently use a "Reviewed" label with my team, and unfortunately we still have to even with this feature.
Similar thing I'd like to see is repo templates. It seems for every repo I create in an organization, I spend time ticking the same boxes over and over. Protected branches for instance is a typical setting I have to duplicate for every repo.
d) create issue templates also, i have to currently cut and paste the same markdown into every issue
e) create user-level permissions - i work on a team where everyone would use this, but currently not everyone can have access to the code base so we have to say in trello until you can allow me the ability to turn off code access to "non-engineers"
Reviews are very exciting, but seem to be unable to fit the following use case:
I want to setup a repo such that a subset of collaborators (or organization members) can merge reviewed PRs to protected branches. I want the rest of the users to be able to create new branches and submit PRs from them, but _not_ to be able to push to protected branches. They should _only_ be able to land code in protected branches via reviewed PRs (via the merge button).
Is there a way to achieve this now that I'm missing? Gitlab's more granular user roles + permissions allow this.
Maybe I can finally get my boss to switch off of Unfuddle. Although moving 10 years of history out of a couple dozen SVN repos into git would likely be lots of fun...
There's some nice stuff here -- probably some of it that I'll use -- but most of this is targeted at organisations (and in particular, managers and administrators) rather than individual developers.
Understandable -- it's clearly companies that are paying the bills these days -- but a little disappointing given the extent to which GitHub got big by attracting lone hackers and little open source projects.
If somebody else manages to claim the small-scale end if the market it could eventually spell trouble for GitHub.
This isn't a random shift in direction for github... in the end it will make the platform so complex and irrelevant for open source teams that they will go elsewhere. I wrote an analysis of this shift some time back: http://hintjens.com/blog:111
Hey styse! You guys are doing great, don't get me wrong, every time I try you guys out, leaps and bounds. My two biggest things right now are CI docs are very very sparse and hard to figure out as they are not similar to typical CI systems, at least the ones I used (primarily Travis). And the design is very unusual, it's hard to navigate around. For example on GitHub I can click my profile and boom, all repositories right there, on gitlab, i got to go through projects, groups and all this other stuff, it's just not straight forward.
No, I'm saying that the "contribution activity" timeline thing is leaning towards information overload (hard to follow; there is a lot to look at). I felt that the last implementation (which focused on the high-level activities that one could click into) made sense.
I'm not a designer or anything so take my feedback with a grain of salt.
Got it - appreciate the feedback! We've been hearing some requests to provide flexibility over what's shown on the profile timeline, so your sentiments are being echoed.
281 comments
[ 14.3 ms ] story [ 5067 ms ] threadI like how I got downvoted for providing information...
Edit: Indeed, from the github blog post - "You can also leave a review summary and delete, edit, or bundle comments before you submit them."
We haven't been able to use any third party tools because our security people don't feel great about giving third parties write access to everything (including our source) for tools that don't need it. In the past, GitHub hasn't differentiated write access to issues (which many tools need) and write access to the source itself (which basically nothing should need).
Considering all of the PCI-DSS / HIPAA / SOX / etc. audit points around change control (even ignoring corporate versions of the same) it's practically impossible to add external services to GH and have them be useful while still meeting compliance. Change control is required, but that also implies control of change control. As-is any service could delete all of your content, whether intentionally or inadvertently, or even worse could corrupt or otherwise alter your history.
It may be detectable and recoverable because git, but it would be infinitely easier to have code and PR be r--rw-.
EDIT: This is now a thing, according to @bhuga below. Also, GH is now publishing a roadmap for what's coming down the pipe, so we're not in the dark as to when these critically-important-why-isnt-it-out-yet features are being worked on. https://developer.github.com/early-access/platform-roadmap/
The "Learn more" button on that banner is a broken link…
(It's a good thing this HN post later directed me to the blog post, as now I've learned from that.)
Overall looks good! When does Enterprise get these features? :)
These features will be coming to GitHub Enterprise soon - we always aim to get new features onto the Enterprise platform on the next major release (which occurs every 3 months on average).
Trello also has lot of features this does not, but I can see GH users using Trello jumping to this, like me.
1. There was a faster and more contextual way to edit issues on a project.
2. There was a way to set up an opinionated workflow where e.g. opening a PR against an issue moves the issue to "Review"; closing said PR moves issue to "Done" and closes it; closing an issue directly moves it to "Done" and vice versa. Without this, there's way too much interaction required for even GitHub's own preferred workflow.
3. Automatic bidirectional linking between issue/PR on the project board. (Honestly haven't had a chance to see if it does this, but will on the next PR I open.)
4. Automatically pre-fill a backlog with existing issues.
5. A project could span multiple repositories (e.g. for tracking user stories which might be addressed in an API or frontend repo, or both). We also track non-dev work on our Trello board, and a project per repo doesn't support this.
6. Filtering.
Edit... Also nice to have: ability to reference a checklist item in a link from PR to issue, check it on merge, and so on.
[1] https://codetree.com
I know there are some tools to manage Issues across repos, but for the most part, the tools seem to assume you work on only one repo, or that milestones only affect a single repo.
I would love to see projects/milestones become more capable when dealing with cross-repo issues.
[1] https://www.zenhub.com
Works pretty well, if a little awkward at first.
[0] - http://purpleapp.com
I suspect it's still a lot better than the alternative but not having org-wide Projects is a little sad.
The now defunct Google Code had a very good solution for this. You could create additional "sub" repositories alongside the "main" one. Github already does that for the wiki, but doesn't generalise it to allowing additional ones. I'm somewhat convinced this is because github has the whole "charge by the repository" model, which is at odds for being useful for projects that require multiple git level repos.
This sounds like a security nightmare, that also significantly impacts local update times and makes for a huge repo.
My view is: unless you have an inescapable security, physical or performance reason not to have a single repo, have a single repo.
Directories are for managing directories.
Version branches are for managing versions.
They are not the same thing.
Issues and projects are global and not bound to a single repository. In my experience, this is the only approach that works in a company. JIRA does the same thing.
It's the closest to a fully open source Atlassian suite that you get. Phabricator has code review, repository hosting, project management and even a CI tool.
Github's issues, despite it's flaws, is easy enough that non-programmers can use it. Phabricator is complicated enough that it's actually caused me to not report a bug at one point.
We also add a host of project management functionality on top of GitHub issues like advanced filtering/sorting, dependency tracking, and the ability to setup your own dev/release workflow.
[1] https://codetree.com
I personally use it on my team at the moment - it's been pretty useful and we've passed along frequent feedback to the platform team responsible for it.
It sort of boggles the mind, really - and makes me feel like they did not really take the community's desires seriously.
https://github.com/issues?q=repo%3Areactjs%2Fredux+repo%3Are...
1. projects. replaces trello, waffle.io, zenhub and many other similar services.
2. code reviews allow approval/request changes as sunny's screenshot shows
3. reviews can be made mandatory.
4. github platform integrations is getting a roadmap
5. a graphql api to query their database
6. enforce 2fa in organizations (much love for this one)
7. summarized timeline for your contibutions
Just a few days back, at the GitLab release, I'd noticed a lot of complains about gitlab releasing useful and impactful features and github being slow on releases. Moreover, now with a public roadmap (even if it is just for platforms), it is a great start.
I'm really liking this change in pace.
mods: Can we make this the canonical discussion for this topic? Otherwise, a lot of branching will happen
This is really not about replacing those services, it's more about building a better foundation for integrators like Waffle and ZenHub to build on.
Sure, it won't completely replace them, but GitHub building this as a platform counts as competition.
Our focus is going to remain on how to integrate a full-featured project management suite within the GitHub eco-system. The GitHub projects release will make a great foundation, and ZenHub will be there to provide the more advanced features like issue hierarchy (epics), time estimation and reporting. Lots of exciting releases coming soon for ZenHub users :)
This will inevitably force out GH's integration partners once users start to complain how feature-deficient projects are in their current state.
Shameless plug: Zube has all these things and more - https://zube.io :)
Even if I could do classes of accounts. Owners and admins, MFA required. Users (bots) that just update CI status, not required.
"We’re rethinking our integrations model to provide better ways for tools to extend and integrate with GitHub. We’ve added the ability for an integration to act on its own behalf instead of impersonating a user—making it a first class actor on GitHub without using a paid seat. Admins will have the ability to configure integrations directly on Organizations and control which repositories they allow access to."
https://developer.github.com/changes/2016-09-14-Integrations...
https://developer.github.com/early-access/integrations/
Not so different from human users who have 2FA activated and use the command line to interact with github.
https://help.github.com/articles/providing-your-2fa-authenti...
It is the exact same with Google Apps as well (where you add the user to the 2faexceptions group and review+remove them a week later).
I was ready to flip the switch, till I realized that a third-party bot account in our organization doesn't have 2fa. Dropped them a mail, hoping to flip it by tomorrow (100% non-bot users have it enabled, so no one is getting auto-kicked).
- Open Source
- Free private repos
- Free self-host (edit to add "Free")
- Everything in one spot (repos, ci, review, coding environment, etc...)
The Enterprise edition features[1] are closed source, and these aren't strictly "enterprise-y" features like SAML authentication. It includes plenty of "basic" workflow features found on GitHub:
- Rebase merge requests before merge
- Use fast-forward merges when possible
- Create templates for issues and merge requests
- Display merge request status for builds on Jenkins CI
[1] https://about.gitlab.com/features/
GitHub (annoyingly) can't do fast-forward merges from non-squashed PRs either.
Display merge request status for builds on Jenkins CI
GitLab implements basically the same API as GitHub for updating build status of commits from external services, or do I misunderstand what feature you mean?
But in general I agree, there are some options GitLab reserved for EE that really feel like they should be part of the CE as well.
And FWIW, I admire GitLab for their open source work. I just think it's worth distinguishing that it's not entirely open source.
When googling for the fast-forward feature one of the top results was this GitHub thread, which had quite a bit of activity fairly recently: https://github.com/gitlabhq/gitlabhq/issues/2324
It seems like many posting there are not aware that this repository/bug tracker is not an official channel anymore -> maybe posting an automated comment in all issues with recent activity or locking them could help avoid confusion? If you arrive via search, you don't see the notice in the main repository description.
It has many enterprise features including code ownership, issue templates, and a Gerrit like, sane code review workflow. You can fully integrate it with your CI tool and it even displays coverage results inline and such.
Ask me anything about it :) I'm not affiliated with it but am an experienced user.
I wonder how it compares to GitLab. Is it possible to set up protected branches, where I can say, only users X and Y are allowed to push to the master branch? Can I do a code review and then finalize it when I'm finished and does the author get notified with a summary like the new GitHub code review feature? Because currently in GitLab the author does get a notification email for every line comment I make, which is also not really the perfect way of doing it.
I already know that Phabricator squashes the changes into one commit, I think I can live with that. (because it promotes small code reviews) Does Phabricator have any problems with git rebase, where I'm refreshing a feature branch with the most recent master state? What I really like about the merge/pull request workflow of GitLab is, that multiple developers can work together on one feature branch while a merge request is open and can be used as a discussion platform for the changes - is this possible with Phabricator?
Also I'm wondering how solid the issue tracking is, and if the project workboards can compete with Trello. Can it be used by non-developers without giving them access to the code?
Looking forward to test Phabricator tomorrow.
Yes. I recommend (and my employer uses) a Herald rule that admits pushes to master only if the changes are in an approved Diff (unit of code review). This way you get an enforced 2-man rule, but anyone besides the author can approve the change.
This is currently impossible with Gitlab AFAIK, and is the main reason I won't use it.
You can also configure Herald rules to add blocking reviewers to other people's Diffs based on arbitrary criteria (i.e. touches X file and it's a Tuesday). A Diff cannot be considered approved until all blocking reviewers have signed off.
Reviewers can also be groups, so you could say, for example, changes that touch Y file must be reviewed by Security, but any member of Security can sign off.
>Can I do a code review and then finalize it when I'm finished and does the author get notified with a summary like the new GitHub code review feature?
Yes, everything you do on a Diff is batched and happens all at once when you click "Submit" at the bottom. Inline comments, the free-form text box, and the action all come as one email.
> What I really like about the merge/pull request workflow of GitLab is, that multiple developers can work together on one feature branch while a merge request is open and can be used as a discussion platform for the changes - is this possible with Phabricator?
A Diff is really meant to be an individual's small, well-defined contribution. Multiple people submitting code to a one diff can get messy. This would be better modeled as many diffs.
You are allowed to land diffs against branches other than Master, however this gets messy. It is not a first-class use case. My employer does not collaborate on feature branches; instead we land half-finished features into master (and production) disabled by feature flags.
It is NOT a merge/pull-request workflow. It treats Git more like Subversion; Phabricator is a very sophisticated alternative to emailing patches around before SVN committing them (basically the equivalent of landing).
>Also I'm wondering how solid the issue tracking is, and if the project workboards can compete with Trello.
Issue tracking is totally solid, very configurable. Project workboards consist of tasks/issues, which are much more expensive to create than Trello cards: you fill out a pagelong form, pick type, severity, owning team, title, description, etc. vs just free-forming a title. However, you can drag tasks around the workboard just like Trello and it looks pretty similar.
>Can it be used by non-developers without giving them access to the code?
Yes. Permissions (and approval flows, and notification rules) are very configurable. Phabricator is well suited to a large organization with rules, but this suitability doesn't carry too much overheard.
I don't think you could collaborate on issues with customers. Nontechnical people in your company, though, totally - we do that.
Due to popular demand, they are adding some tools to allow merge/PR workflow. That being said, it was not stable last time I checked (~6 mo. ago), and it will probably take a while, if ever, for it to be as good as what's already there for Differential (the current code-review/landing system).
That being said, their existing tools are really good, and the fact that you are not married to a single VCS is really nice. You can have some legacy SVN repositories and be fine, and use the exact same interface for code-review and landing as in your shiny new git repositories. Prefer hg to git? No problem. Have some complicated gitolite setup you don't want to bother migrating? Phabricator works fine even when not hosting the repository.
On top of that it was really painless to install locally. I had it setup in under an hour, and that included my first time ever setting up my webserver with php, and first time configuring a mysql instance.
https://www.phacility.com/phabricator/
Based on my experience, Phabricator has some quirks but is quite solid, and the well-designed command line arc workflow would please folks who refuse to open a Web browser.
I want to echo here what I said in https://news.ycombinator.com/item?id=12501271 "If there are features that people think that should belong in the open source edition we're all ears. We've done so before https://news.ycombinator.com/item?id=10931347 A feature comparison between CE and EE can be found on about.gitlab.com/features/#compare "
Regarding the examples please help me understand:
1. Can you rebase in the GitHub interface?
2. Does GitHub have an option to fast forward merges?
3. Please let me know if this is a feature people want open sourced. EDIT turns out that this is part of the open source edition already https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/cont... I created https://gitlab.com/gitlab-org/gitlab-ce/issues/22185 to update the docs
4. We have a commit status API in GitLab CE https://docs.gitlab.com/ce/api/commits.html#commit-status and works with the open source https://github.com/jenkinsci/gitlab-plugin We do have additional integration in EE https://docs.gitlab.com/ee/integration/jenkins.html
BTW you might be happy to learn that what you mention as an example of typical "enterprise-y" feature is available in GitLab CE https://docs.gitlab.com/ce/integration/saml.html
> 2. Does GitHub have an option to fast forward merges?
So is Gitlab's aim to just play catchup to Github?
We have a broader scope than GitHub, see our announcement broadcasted on Tuesday for more information and a demo https://about.gitlab.com/2016/09/14/gitlab-live-event-recap/
Github compromises by having a nice ecosystem of tools which you can plug in, but having it built in is always nice since the integration is tighter.
If I'm reading this correctly, this exists in GitLab as an enterprise feature, so I think my earlier comment isn't too far off. There also appears to be some community feedback suggesting this should be a CE feature [2].
[1] https://help.github.com/articles/about-pull-request-merges/ [2] https://gitlab.com/gitlab-org/gitlab-ce/issues/4106
They have to make money after all.
The 'basic' product (which is far more than basic) is open source though, which incredible.
I'm not criticizing the product – they're welcome to open or not open source whatever they like. I'm just clarifying the description the parent used.
The review feature is very new in GL, and that plus all of the things you are mentioning within "everything in one spot" is available in this update (except maybe the coding env, not sure what that means anyway), if you've read the announcement. Github also has self hosting.
CE is a very large subset of EE. But yeah, maybe "open core" is a better term.
> except maybe the coding env, not sure what that means anyway
Koding integration (I haven't tried it yet) https://about.gitlab.com/2016/07/26/koding-and-gitlab-integr...
> if you've read the announcement
I assume you meant Github's announced features? Yeah, I think they're great.
> Github also has self hosting.
Costs $, Gitlab has free self hosting (updated parent comment)
[1] https://github.com/blog/978-introducing-github-enterprise
We have companies scaling their GitHub Enterprise instance up to 25,000 users, and we also have a dedicated Enterprise Support team available 24/5 to resolve any technical issues.
I am not your target market, FWIW, but just a curious developer.
We also recognize that having a SaaS solution like GitHub Organizations meets the needs of many companies (over 75,000 at last count), and our announcement of 2FA enhancements today is an indication of our desire to continue that approach.
That's a pretty misleading characterisation. You can browse the source code, submit issues, see what's being worked on, contribute PRs, and freely download and run your own instance of GitLab. A handful of enterprise features aren't open sourced.
GitHub in contrast is a black box.
We've had code review for many years now in GitLab. The coding env probably refers to our integration with Koding, an online IDE https://about.gitlab.com/2016/07/26/koding-and-gitlab-integr...
and self-hosting :-)
Price is a feature.
But the answer of self-hosting is a perfectly valid answer for "Why the love for GitLab?" when one = $0 in licensing, and the other = > $2,500/year in licensing.
That is literally what the comment I replied to said. That "self hosting" was a reason to root for gitlab.
Similar to the "you can't use price to differentiate the two" - why not?
doesn't speak well for their business prospects.
GitLab's pricing model won a lot of people when GitHub's was ugly for anyone who wanted private repos (single guy at home with 10+ private repos for things like your dot files, etc? $20+ a month, for what likely amounted to under 1MB of disk space).
Still, most people in HN threads use it because it's free. Which is great for an open source tool, but bad for an unprofitable, VC-funded startup.
And that’s exactly why you shouldn’t use it.
> Since the open letter to Github with the complaints of feature requests,
This, and the answer from GitLab to that letter, is what made GitHub move in the first place.
You need competition for a healthy market.
Issue tracking, or anything tracking really, document versioning and templates to get you started really quickly. It’s proven scalable as it’s already used by companies with more than 17 000 users with a single instance of Tuleap. I would love some feedback as we are actively developing it with monthly releases. You can check it out at https://tuleap.org/
GitLab's roadmap yesterday surely didn't motivate or spawn the "New GitHub Universe," and I wouldn't think that Github is very nervous about GitLab currently due to it's massive lead in the market. Maybe this new round of funding made some of the folks at Github look over at Gitlab, but I doubt too much else.
Just my 2 cents, but I think they very well should be
Ehh... dominance among open source projects, and Hacker News and Reddit thread cool points, is one thing. But in boring old terms of actually making money, how IS GitHub doing?
"Enterprise" is practically a swear word here, but that's where the meaningful paying customers are. From my anecdotal experience, Atlassian absolutely dwarfs GitHub in the enterprise world... and that's just the enterprises that are willing to host code in the cloud to begin with.
For large shops demanding an on-prem solution, GitLab seems to have a much better story than GitHub since that's really their business model bread-and-butter. For GitLab, the cloud hosting is basically just a marketing tool.
https://www.quora.com/How-close-is-GitHub-to-returning-to-pr...
https://signalvnoise.com/posts/2486-bootstrapped-profitable-...
http://www.businessinsider.com/github-is-now-worth-2-billion...
It's historically been tough to compare them to Atlassian because Atlassian has provided tons of other enterprise services like Jira and Confluence, and an 8 year lead plus going public, but I think Github is definitely working on better squeezing into the enterprise space with this current announcement.
I was recently at an F1000 company and we did self-hosted GitHub Enterprise. While many services were duplicated across departments, there were a variety of other commercial VCS setups, and our GH was not highly available… there was a ton of buy-in to GitHub Enterprise. And, yeah, we did JIRA and Confluence (and SharePoint…).
I'm doing a gig for a F100 company now and, well, we've got GitLab. I dunno if I'm just more used to GitHub or if I actually prefer it to GitLab.
(It's of course not certain they are the reason they are moving again, but GitHub looked a lot like the market leader that feels like it doesn't have to bother much anymore. And they weren't entirely wrong.)
Maybe they should start looking into global rollout like Google, Facebook and basically every serious company having world-wide audience.
It's always disappointing to see a self-described intellectual community give over so heavily to such an obviously broken thought process, but humans being the emotionally manipulable creatures they are, it makes sense.
A lot of people seems to think they are smart because they belong to a powerful or politically correct group.
Also a lot of people seems to think they are smart because they are rooting for the underdog or just plain contrarian. ; )
JIRA doesn't support markdown. That seems like baby stuff to me.
Most of the times when I do a review it's not a single comment and right now the workflow is to let the team know on Slack that I am reviewing this.
From the Gif it's not 100% clear what the pending state does but I would want something like blocking the PR until every team member that started reviewing will "release" the PR. I also see the negative side of this of course but I think the positive outweighs the negatives.
Edit: I saw an approval email notification on one PR, but not another.
Thanks!
We definitely want to get some way to surface reviews better across all PR's and/or projects. I've been bothered by that myself while we were building this. :)
e) create user-level permissions - i work on a team where everyone would use this, but currently not everyone can have access to the code base so we have to say in trello until you can allow me the ability to turn off code access to "non-engineers"
I want to setup a repo such that a subset of collaborators (or organization members) can merge reviewed PRs to protected branches. I want the rest of the users to be able to create new branches and submit PRs from them, but _not_ to be able to push to protected branches. They should _only_ be able to land code in protected branches via reviewed PRs (via the merge button).
Is there a way to achieve this now that I'm missing? Gitlab's more granular user roles + permissions allow this.
Understandable -- it's clearly companies that are paying the bills these days -- but a little disappointing given the extent to which GitHub got big by attracting lone hackers and little open source projects.
If somebody else manages to claim the small-scale end if the market it could eventually spell trouble for GitHub.
I'm not a designer or anything so take my feedback with a grain of salt.
Thanks again!