Blog Open Source Git Merge 2020: a celebration of Git
March 25, 2020
6 min read

Git Merge 2020: a celebration of Git

A look at Git Merge 2020 and a look forward to the next decade of remote, async, and powerful source code management.

GitLab-sponsoring-Git-Merge.jpg

Almost 15 years ago Linus Torvalds came out of retirement and released a project – Git – that would be adopted by millions who would in turn contribute over time to what is arguably the world's most powerful distributed version control system.

Git Merge 2020 kicking off

In early March, Git was celebrated at Git Merge 2020, an event that was sponsored by GitHub, GitLab and the Software Freedom Conservancy (SFC). A fair share of GitLab team members attended and actively participated in the birthday celebration. We thought we'd share a look at what we liked most.

Happy birthday Git

Git police, stop! Open that trunk

There were lots of bad jokes like that one, but fortunately the content was much better than the jokes. Our users often say the one thing they like about GitLab is it makes Git understandable to them. It's nice to have validation every now and then and that is precisely what we felt during the talk titled The Zen of Git in which Tianyu Pu, a software developer at Booking.com, explained in beautifully crafted slides how Git's internals work. By knowing how Git works she is able to approach Git less fearfully and be more productive using it in a day-to-day workflow. Judging by the warm round of applauses received when she finished her talk, we would argue she definitely achieved her goal. The clarity with which she presented each concept was encouraging so we suggest reading through her deck.

Git 15 year life

Ed Thomson, co-maintainer of libgit2 and a GitHub employee, received some laughter from the audience the minute he was up on stage. His talk was about how lightweight, short-living branches merged fast into trunk – or master, as you wish (more terrible jokes!). He outlined great ideas to keep some sanity in your development branching model. To make this even more compelling, why not a Git workflow alignment chart?

Ed Thomson's Git workflow alignment chart

Ed suggested that pairing this pattern with continuous delivery practices would make a perfect combo. Git flow, however, didn’t get the best of Ed's talk but it is noteworthy that Git flow’s author Vincent Driessen shared some timely advice on his blog while Git Merge was taking place:

If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow instead of trying to shoehorn git-flow into your team.

But if there was a star that day, it certainly was Derrick Stolee from Microsoft. Derrick and his team have recently released Scalar. Barebones Git or Git in combination with the VFS protocol can still struggle when handling large repos like the one hosting Windows' source code. Scalar is an open source project aimed at accelerating Git's workflow regardless of the size of the repos.

I asked Derrick how he and his team combined the request from his employer Microsoft and the larger goals of the Git community which may not be in alignment. For him the answer is simple: Microsoft thinks of Scalar as a good solution for clients and internal teams. The company believes giving Scalar to Git will only make it better since most of the community members are Git veterans and will be able to improve the feature. When designing Scalar Derrick's team always had Git's architecture in mind and the plan is to contribute it to Git's client. I believe this speaks volumes about Derrick's team's ability to solve a complex problem but also at the same time care about the larger community and Git's design. This is just one example of how enterprises and the larger Git community are getting together and making Git perform better and in more use cases.

And Scalar does not only just apply to Window's repo, Office's repo or video game repos. It is having a real-world and timely impact. This repo that is collecting real-time datasets to help with the COVID-19 pandemic is getting bigger every minute thanks to the input that many, including some GitLab teams, are offering. However, it needs technology like Scalar to handle it.

At the end of our chat Derrick asked me if I knew about the Japanese principle of Ikigai:

Try to find something for your professional career that is fulfilling, something you are good at, something the world needs and something you'll get paid for.

It's true that contributing features to Git that are useful in such dire times must be a reason to be part of the Git community.

Work in the open: companies collaborating for the good of Git

Scalar isn't the only recent addition to Git – Partial Clone was contributed to Git by Jeff Hostetler from Microsoft and Jonathan Tan from Google. In Derrick's opinion, both of them came from different perspectives to solve the same problem. Had they not collaborated on their approach – even with the community's input – they wouldn't have arrived at the same successful feature that Partial Clone is now. Another very recent example of this same collaboration is some of the updates Git v2.26 comes with. And Peff from GitHub and Christian Couder from GitLab contributed changes to the way Git handles packfiles.

GitLab experts all over: to 15 more years!

Overall we found a lot of validation in GitLab's own work, not only upstream to Git with new features like the ones already mentioned, but also downstream to our users. GitLab gets better at making Git more easily usable and proposes development workflows, like GitLab Flow, that allow our users to be fast and productive while keeping a neat code base. GitLab is making Partial Clone progressively more stable across any GitLab instance. (If you are already using partial clone, or would like to help us test partial clone on a large project, please get in touch with James Ramsay, the group manager, product for Create at GitLab, me Jordi Mon or your account manager.)

GitLab team having fun

While our very own James Ramsay participated in an expert panel in last year's event, this year Zeger-Jan van de Weg was on stage for a stump the experts panel.

Mingling around with the rest of the community was hands down the best part of Git Merge 2020. It was so much fun to be part of a welcoming, inclusive community.

GitLab's team having fun

For all these reasons and more we would love our involvement to be ever-growing with Git Merge. That's why we look forward to Git Merge 2021! 15 years have passed and Git is still in its best moment.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert