GitHub Enterprise 2.6 streamlines workflows
- 27 April, 2016 04:26
If the last update to GitHub Enterprise was all about size, this one's all about speed.
GitHub Enterprise 2.6 includes a new feature mix to "create efficient, flexible, and friendly processes [for teams] at every step of their development cycles." In other words, this isn't about the speed of the application, but about streamlining how teams work with GitHub -- how they collaborate on code, merge it, manage it, and discuss it.
Many of the new changes, according to GitHub's press release, are tools for administrators managing workflows on GitHub repositories. Some of them have showed up before on GitHub's public site, such as templates for issues and pull requests.
Other new features are for use cases that show up more often with GitHub Enterprise deployments. Admins can now set up "pre-receive hooks," which enforce policies for how code is pushed before it enters the repository. Along with another enterprise-grade feature rolled out in 2.5, protected branches, admins can elect to merge outdated pull requests (e.g., if it turns out they're actually useful), and restrict branch-merging privileges to specific users or teams.
There's plenty new for the rank-and-file user, too, like the ability to add a file to a repository by simply dragging and dropping it into the GitHub interface. For those who have long had trouble with the Markdown syntax used by GitHub to style issues and comments, the editor now has tools to aid with that.
Git users have long had the ability to perform a "squash merge," where a whole batch of commits can be consolidated into a single commit. GitHub Enterprise now supports this as well. Since this cuts down on the traffic that takes place around a project, it's also a way to reduce how many notifications an admin has to wade through for the projects they oversee.
Many of the other time-saving features are little ones, like being able to find and filter files in a repository by name or extension, or being able to filter changes by commit, with GitHub suggesting this can be used "to see how a pull request has evolved through time."