GitLab is a single application, so for convenience we organize by DevOps stages. The Create stage of the DevOps lifecycle is about creating code, and includes Git repositories, merge requests, code review, the Web IDE, wikis, and snippets.
Managing source code is at the heart of GitLab – it's in our name and it powers your applications. This year we've shipped many important improvements to make it easier to go from idea to production. The Web IDE makes it easy for anyone to contribute, and faster to work with merge requests. Squash and Merge, and Rebase and Fast-forward Merge are available in GitLab CE. File locking is integrated with Git LFS. Maintainers can push to forks. And there is much more to come this year, like batch comments for merge requests, and suggested approvers based on code owners.
Here are some of the things we're thinking about for 2019:
As our plans are always in draft, we'd love to hear your thoughts, and any suggestions.
Collaboration
Git's distributed design made new collaborative workflows possible, and forking has made collaboration even easier. Forking is the workflow of choice for open source, and for the same reasons it is also great for private organizations. We want to remove the barriers to collaboration and inner sourcing, but also make it easier to collaborate with external open source projects too.
The distributed capabilities of Git aren't limited to a single server. Open source software is used extensively in commercial applications of all kinds, but collaboration between open source projects and commercial is difficult. Features and bug fixes to open source projects can sit in stale forks in private Git repositories for lack of tools and process. Distributed merge requests will make it easy publish a patch from a private GitLab instance to a public upstream server, be it GitLab, GitHub or Bitbucket. Teams will be able to work on a patch privately following internal processes, but instead of merging the reviewed and tested change privately, it can be published to a new public merge request upstream. Contributing fixes and features upstream isn't only good for the community, but it also makes commercial sense by eliminating the costly task of keeping a stale, private fork up to date. We want to make it easy for everyone to contribute to open source software, as individuals and as companies!
We'll also be improving simpler forking workflows too with important quality-of-life improvements. To make it easy to see how far behind or diverged your fork is, we will make it possible to compare branches across forks and cherry pick changes directly from the upstream project into your fork. Forks of private projects will also inherit permissions from the upstream project, making it possible for upstream maintainers to rebase stale merge requests and help contributors. This will allow teams to adopt forking workflows without needing to make every project public to the world or to the organization.
Code review and approvals
Merge requests are key to the workflows that allow teams to iterate rapidly and ship amazing products quickly, by bringing together all the important information in a single place. Critical to this workflow is the code review, and we want GitLab to be the best tool for doing code reviews.
Automatic code quality and linting tools can prevent code reviews becoming simple code style reviews, but without the inline feedback a reviewer can't be sure which problems have been automatically detected. A new API for line by line code quality feedback will allow output from tools to be rendered natively in GitLab in the merge request diff. Merge request authors will have a single source of truth, and code reviewers can confidently focus on important structural feedback.
Code review feedback cannot truly be resolved and the merge request approved until the reviewer checks the feedback was correctly addressed. This step prevents feedback from being misunderstood or overlooked, but it is currently difficult and time consuming. We are going to streamline this important step by allowing you to review changes since code review and making merge request diffs smarter. When the change is straightforward, we're going to make it possible to simply propose a change as easily as leaving a comment that can be applied with a single click – no more copying and pasting sed one liners! And we're going to make it easier to view and add comments to commits at any time.
In the real world, complex features often require large, complex merge requests. We will support these situations better with commit by commit code review, autosquashing fixup! and squash! commits, and allowing you to preview the resultant squashed commits.
Complex real-world changes also need good commit messages, but commit messages are too easily neglected. Without good commit messages, debugging a regression, or modifying an important existing function is painful and error prone. To help teams adopt best practice commit hygiene, we will make commit messages part of code review by allowing comments on commit messages, improving the visibility of commit messages, and making squash and merge smarter. GitLab should celebrate great commit messages and amplify their benefits to make it easier for teams to adopt best practices.
Web IDE
In 2018 we're building a strong foundation for a cloud development environment with client side evaluation and server side evaluation powered live previews, and server side evaluation will also enable a web terminal to test your changes in real time. IDEs are also very personal and should support customization, to make it easy to move between your local IDE and GitLab IDE. Please share your feedback, and consider contributing – I'd love to see support for dark syntax themes and vim keybindings!
The Web IDE makes it easier than ever to resolve code review feedback, reducing the need to switch context in your local development environment, but we can make it even better. Addressing a comprehensive code review still requires switching backwards and forwards between the merge request and the Web IDE. Line by line code quality feedback available in the merge request diff will also be available in the Web IDE as will live linting feedback powered by server side evaluation so to help prevent new code styling problems being created while resolving feedback.
We are also considering integrating merge request discussions so that code review comments can be addressed without needing to continually switch between tabs. We don't think the Web IDE should replace the merge request, nor should every feature be duplicated into it, but do think the Web IDE can further simplify the process for resolving code review feedback so teams can iterate faster.
Summing up
Writing, reviewing, and merging code is where the rubber hits the road when taking your app from idea to production, and in 2019 we want it to be better than ever before!
The GitLab product vision is public so you can read up on what we're thinking about at any time, about every part of the product. Please join the conversation and share your feedback on these ideas, and offer ideas of your own! Your contributions – idea or code – are welcomed and appreciated so that we can all work together to make GitLab the best application to build and ship your next great idea.
