This is the example of how hard it can be for companies, especially successful companies, to alter their course even slightly.
Github success was about making code repositories pretty and social. But this is no longer enough to keep evolving as a company of their size. Yet the internal product DNA still revolves around repos, so as a result, issues, wikis and now Projects (!) live under a single repository.
This is backward.
A project is a way to group resources to achieve a predefined goal. Those resources include multiple people, multiple issues and multiple repositories. Sticking a project under a repository makes no sense.
In fact, a code repository in most organizations is a fairly small and an insignificant asset, just another way to organize code, i.e. function -> module -> directory -> repository, etc. It's quite awkward to think of what your company is doing in terms of repositories, so anything Github adds to repos feels out of place by default.
Another example of repository-centric thinking is the homepage of https://github.com itself when a user is logged in. It's the most important page of all, yet nothing on it has any relevance to me: just a list of people I like starring random repos. Same thing for the organization home page, just a list of repos, again.
The Project idea is great. It had the potential to solve all of these issues by giving me a tool to organize digital assets in a way that's important to me. But sticking it under a repository killed it.
[EDIT] It's easy to be me and be posting a comment like this, telling successful people what to do. But it's enormously hard to have a large team of PMs, developers and designers, all of whom are smart and ambitious individuals, to actually do something that falls outside of the settled way of doing things. Kudos to Github founders and employees for getting it this far and congratulations on dealing with big company problems ;)
Thanks Chris. It is a tricky balance not being too noisy (I understand the sentiment of https://news.ycombinator.com/item?id=12502468 ) but I tried to add to the conversation by by sharing our thoughts about the project <=> repo dilemma.
I'm in no way affiliated with gitlab, but I do like the product.
But the facts are such:
1) GitLab is a YCombinator incubated company.
2) GitLab and GitHub are direct competitors
3) It's almost always relevant to the discussion, in this case; "How could it be done differently, how /has/ it been done differently"
In this case I think it's fair to bring up the direct comparison of github and gitlab. The only thing I would say could improve the situation was having github representation on here too.
I enjoy threads like these; this is how healthy competition looks like. GitLab peoples' comments are relevant, and their discuss technical issues and merits of their solution, instead of comparing to GitHub ("we're better than the competitor!").
If this is how all marketing would always look like, I wouldn't hate it like I now do.
YMMV, but I find sytse so hugely overbearing that I actively don't want to use GitLab because I don't want to encourage what I see as tacky, bad behavior. He and other GitLab staff can do as they like, but I'm not rewarding it.
I don't have a strong opinion but my gut feeling is that the GitLab staff is always asking HN what to do, which kind of makes me question the integrity of the company's own ability to decide.
Of course it fits with the model of an open source company, but it still makes me skeptical intuitively. (I say this less as a criticism and more as feedback on how one random HN user perceives their presence.)
Thats fair comment, but how do you define the middle ground between sitting in an ivory tower and wondering what the next feature should be, between asking people who actually use your product in ways you wouldn't expect?
I release computer games, which are developed largely in secret and when they hit the market after 4-7 years people find all kinds of warts and issues that we never even thought of.
GitLab seems to be of the idea, "ask people what they need, make small incremental movements into making that happen and release those increments often so that people don't get jarred by changes"
I can support that, and I don't think it bears negatively on their integrity.
I'm not sure. Maybe I would try to integrate the product suggestions into the product more, along with just reaching out to users directly and generally conducting the product in a typical open source fashion.
What bugs me a bit is mostly the constant presence on the Hacker News forum, with this somewhat aimlessly customer-pleasing tone: "What can we do better? How can we improve your experience?" etc.
It seems like a premeditated PR/marketing strategy, which might be working well, but it's still off-putting to me.
Objectively, that's such an odd thing to be unsettled about.
Have we reached a point where all pleasing tones are considered marketing and PR? That we distrust people for acting earnestly?
It's in gitlabs best interests to be a superior product, right now they're an underdog, and their ubiquity on hackernews is not a coincidence, they're a YCombinator backed start-up.
Talking directly to people tends to focus the conversation too much without allowing outside perspective, you might want all of gitlab to be focused on CI, but I may think a casual CI integration would be more reasonable and likely a good solution is a middle ground- also, who do you ask? people rarely talk about their VCS unless it's relevant to discussion.
Asking what to do doesn't mean doing what they are asked. Turning suggestions into software features requires a lot of skillful software design and marketing work.
There's nothing wrong with deciding, among countless incompatible options, to evolve the product in ways that appears likely to increase revenue, while not seeking feedback would be an actual bad sign about GitLab's ability to decide (and improve).
That's interesting, it's not how I read their interactions at all.
Asking the community for opinions is a great thing to do - you might get some good suggestions and the community then feel valued. That doesn't mean you need to do exactly what the community tells you, but taking it into account in the design process may help build something that the community actually wants to use.
> In BitBucket you have multiple repositories under one project
however, unless i'm missing something, a "project" in bitbucket is basically just a folder to group your repositories in. there's no real features associated with it. A github project is project management tools based on a repository.
If GitHub had called their feature something else, (for example, call it "the board") and nobody would be expecting it to be anything other than per-repo.
That's correct, right now projects in Bitbucket help to organise your repositories into projects. With the raise of microservices, it's quite common that a project or product is made up of many repositories.
In the future you will see us adding more capabilities to projects, such as permission management [1] or settings on a project level, which already exist in Bitbucket Server.
It would be nice if there were a taxonomy of different organisational approaches so that we could have a common terminology to discuss the pros and cons of each.
E.g. I come at things from the intersection of (embedded) product line engineering and continuous integration, which leads me towards a different place than somebody coming at things from (e.g.) consulting or web services ... but it is difficult to have a meaningful discussion about the pros & cons of each approach without the language / terminology that we need.
I disagree, I have zero problems with these new features, which cost no extra money to me. These are all extra features, that I can choose to use or not use, that github rolled out for its users. I personally treat repositories as a single self contained code project, and I find that a lot of other people do too. The home page makes me feel less lonely. It's all good for me. Yeah a repo-centric trello board won't serve a whole corporation, but is it really that important? Github isn't trying to kill trello.com, it's just rolling out a nice little feature that the average hacker appreciates. I can see how a bigger team would lump multiple repos under one project but for that why not just use trello.com, after all it's a specialized tool created for such a task.
You've summarized my thoughts perfectly. Projects often span multiple repos.
I hope Github rethinks their design and places Projects under user and organization profiles, rather than repos. It's a very useful feature that's sadly trapped in a single repo.
One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry.
Some people are eager to divide their project into multiple repos in spite of git being a distributed version control system. Having many teams doesn't mean you should have many repos. Why not just let your team work on one small directory inside the repo?
> One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry.
I think this depends on your job function. At Codetree we have a bunch of customers who need to see a project that spans multiple GitHub repos. The person who needs this view is the person responsible for delivery - usually a project manager, a product manager, or a dev manager.
A common example is a project that spans an API repo, a front end repo, and a mobile repo. If you're responsible for delivery, you want to be able to answer questions like "How much work is left to deliver the FooBar feature", or "Show me all the tickets assigned to Joe". To answer these, you must see issues from multiple repos rolled up into a single view.
I suggest you use one repo with sub directories, one directory for API part, one directory for front end part, one for the server part ...
Then, when you change the API, you don't have to create 3 pull requests across 3 repos, just ONE pull request and teams can review all the changes together.
And your problem of searching for issues assigned to one person across multiple repos is not a problem any more.
There are already many good examples of managing multiple modules inside one repo:
I think such cases call for a more professional / serious project management tool. I mean, GitHub projects is just a webapp, one that lets you move some rectangles around with a mouse. I'll be happily using it to manage issues on my small open-source projects (that incidentally are usually self-contained within a single repo), but for anything bigger / more serious, I'd rather use an external tool.
Reusable and reused components span multiple projects and even companies. A quite reasonable scenario is when a project includes a component library that's loosely coupled, open-sourced and used by others (so it pretty much has to be in a separate), but it's not just an included dependency but being actively worked on in a project - e.g. a single small new feature would require commits to both the library and the repository that's using it.
Spinnaker is comprised of a bunch of quasi-independent microservices, designed to work together. I don't think it would necessarily make sense to have them all in the same repo, when they could be swapped out or even used separately in another project.
Although there will still be lots of projects (e.g. `an open source project with one repo`, `some company with a huge monolithic repo`) that will be able to use per-repo Projects profitably.
But yes, someone, please make something that kills JIRA as soon as possible.
I think they could iterate on this to a place where projects are repository-specific, but still useful for high-level organization and planning.
For example, if they allowed repo projects to reference issues in other repos, that would you get you 99% of the way there. You could start a single meta-repository that referenced as many repo-specific issues as you cared to consider.
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
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
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 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.
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.
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.
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].
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.
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.
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.
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.
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.
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.)
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.
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.
> "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.
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.
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).
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.
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.
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/
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 :)
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/
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.
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).
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.
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.
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.
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.
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
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.
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.
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).
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.
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.
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:
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'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/
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.
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’m not sure if the name “project” is a good choice here.
For one, GitHub still has some pages that refer to the idea of creating projects on GitHub, except those aren’t referring to these new kinds of “projects” (they actually are referring to new repositories or new accounts or something).
And, there are literally over a million repositories that have the name Project or Project somewhere in their name[1] so you can now create projects within things that are already called Projects (except the “projects” act more like issues, or tasks, or something).
Naming is important, there’s a reason why engineers devote so much time to it.
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.
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
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).
My team and I played around with Projects for a little bit and these are things that were blockers / annoyances for us from moving away from trello. I'm posting because I know some GH people are reading these comments.
- Mobile support: Trello mobile app is great, projects web doesn't even resize for mobile.
- Slack support: Card Created notifications
- Easier “card” preview: Projects requires you to go to a new page to view a card
- Projects (1): This little "1" will always be 1. At least with PRs and Issues it means something (pending tasks, etc).
- Limited to one repo
I also found it funny that they call it "notes" as in "add note" "delete note" etc, but there is a menu item on each card that says "Copy Card URL". Maybe they renamed from "cards" to "notes" mid development? :)
I'd really like it if the Pull Requests page would denote which PRs I've already approved. That is one thing I really liked from Bitbucket, it makes it easy to skip over what I've already approved. It would become slightly more complex though, because then you'd probably want to see something for PRs you've approved but had subsequent changes on.
Thank you! Can I make one more request? I'd love to be able to see merge conflicts from the diff page (also like BB does).
Knowing the conflict is just db/schema version instead of something more problematic-- that is especially handy when used in conjunction with various target branches.
i.e. I know <another-feature> branch is about to be merged before right before <my-branch> gets merged. Then, I can know what I'm going to have to fix quickly without having to go back to terminal, fetch <another-feature>, merge <my-branch>, just to find the conflicts. Yes, I have to do that with master after it's merged anyways, but I find it great to see quickly and at a glance beforehand.
Certainly - thanks for that! I've included it here.
We're aiming to monitor this board as much as possible, but if there other feature asks that come up, feel free to connect with our Support team - they're also available to take your feature asks and report them to our Engineering team.
A couple days ago I noticed that the status box on the PR page now includes a list of conflicted files. Not sure if that was in any way related to my request here, but wanted to thank you if it was. That is very helpful.
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
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.
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.
+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.
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. :)
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"
I'm actually really interested in the tech stack they used to make these new features. Specifically Projects. No latest and greatest framework or anything of that caliber. Just plain PJAX which is what everything else they have done uses. That's pretty cool to me. Looks like a pretty strong engineering culture of using stuff that works, instead of the shiniest object at the moment in time.
The inconsistent and non-sensical font and white space on the new profile pages is giving me an indescribable form of anxiety. If anybody out from the GH design team is out there, please put it back to how it was. :(.
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.
Another Discourse forum. I was sceptical that the Discourse style of forum would become popular. Too complex and heavy, specially for mobile. I must admit that it's looking very good and is very usable.
If anyone from GitHub reads this, it would be great if you could use Task Lists [1] within Notes, e.g.
Note Title.
- [ ] Some subtask.
- [x] Another subtask.
You could then group subtasks within a single note and tick them off as you go without having to edit the note every time. Cheers and thank you for the fantastic new features!
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 anybody from GitHub is here, I have a feedback on the new Reviews feature.
When the Review approval is missing or required, please make it clear in the "Pull Requests" list-view by updating the color of the little dot and it's popup description.
Right now the colored dot and its description are only including "Checks" but not "Reviews". It would be nice to have a clear indicator of which Pull Requests are missing a review just by looking at the list.
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.
Code reviews currently do not seem to come through on the webhooks at all.
Our in-house automation suites depend on it, so this is a big do not use for us.
I really wish their APIs weren't second class citizens. It takes weeks or months for new features to show up in the API - if at all. I wish there was 1-1 parity with the API.
We definitely have plans to get full support into the API around pull request reviews.
Given how much iteration we do after an initial ship like this, especially one with as much feedback as code review, we prefer shipping the API after things have solidified and settled down after the wide release.
How about diffs on pull request? The biggest gripe I have with github is the inability to compare my feature branch with the branch I'm merging too. The diff you see is comparing the feature branch with the "base" branch which would be stale when working on a dev team.
- Two feature branches were created based on master at the same time.
- Branch1: committed a change to readme and it's pulled into master via PR.
- Branch2: committed a change to readme, raised a pull request (PR#3), and the diff doesn't show the line that was added with the branch1 pull request.
In this example, the PR is telling me there's a conflict and I need to merge master with the PR branch (this is good). What it doesn't tell me is where the conflict is.
Solution, merge the base branch into the interim PR branch. The result will show you the conflict and properly represents what would happen if this PR is accepted. (Bitbucket does this)
I think their recent change to per user pricing plays into this nicely. These features look really cool, but I can see it being costly to an organization when you have to give managers, project managers, etc. access to Github just so they can manage issues.
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.
Hmm.. So was there a workflow where I could say "I'd like for this not to be pushed until I've approved it", even if the patch is assigned to be reviewed by someone else? Of course, I could just comment with that on the issue, but it would be nicer if the issue would pop up somehow after the other reviewer has reviewed it, and it would be obvious to everyone that it's waiting for my approval.
What I really wonder right now: When reviewing my own PR on my own repo, I cannot select that the things I proposed must be resolved before the PR can be merged - why is that? Am I not allowed to keep myself from merging things I considered changeworthy or what?
I just hope Github doesn't pivot in a direction that makes them no longer a safe place to archive open source code. We've had two failures already - Google Code (shut down) and Sourceforge (started putting adware on the executables of others.)
Not even close. Trello has way more features for cards. Project notes are really just a blob of text (Markdown?) and that's it. No title, description, checklists, attachments, or comments. One can imagine them coming though and with the Projects API on the roadmap you would then be able to do an import.
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."
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...
The updated Code Review 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).
Thanks, our team was literally lamenting about lacking specific reviewers when migrating from phabricator to github enterprise last week. Looking forward to it!
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.
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.
Github success was about making code repositories pretty and social. But this is no longer enough to keep evolving as a company of their size. Yet the internal product DNA still revolves around repos, so as a result, issues, wikis and now Projects (!) live under a single repository.
This is backward.
A project is a way to group resources to achieve a predefined goal. Those resources include multiple people, multiple issues and multiple repositories. Sticking a project under a repository makes no sense.
In fact, a code repository in most organizations is a fairly small and an insignificant asset, just another way to organize code, i.e. function -> module -> directory -> repository, etc. It's quite awkward to think of what your company is doing in terms of repositories, so anything Github adds to repos feels out of place by default.
Another example of repository-centric thinking is the homepage of https://github.com itself when a user is logged in. It's the most important page of all, yet nothing on it has any relevance to me: just a list of people I like starring random repos. Same thing for the organization home page, just a list of repos, again.
The Project idea is great. It had the potential to solve all of these issues by giving me a tool to organize digital assets in a way that's important to me. But sticking it under a repository killed it.
[EDIT] It's easy to be me and be posting a comment like this, telling successful people what to do. But it's enormously hard to have a large team of PMs, developers and designers, all of whom are smart and ambitious individuals, to actually do something that falls outside of the settled way of doing things. Kudos to Github founders and employees for getting it this far and congratulations on dealing with big company problems ;)