This is a solid primer on git rebase and the many ways it’s useful.
In Git, a rebase is a very versatile and useful tool to rework commits. Use it to achieve a workflow with high-quality changes proposed in high-quality commits and merge requests. It makes your developers and reviewers more efficient. Code reviews and debugging also become easier and more effective.
GitLab’s Sid Sijbrandij shares 12 strategies managers can use to support their team and prevent burnout. One of his standout strategies that I doubt rarely gets put into use is reduce the number of hours worked by agreeing to reduce effort
GitLab’s compensation structure is known to spark controversy.
Aricka Flowers writes on the GitLab blog to give an update on their latest iteration on salaries.
Our compensation calculator is a regular hot topic on places like Hacker News – pretty much any thread about GitLab has a comment about us paying local rates. As with everything GitLab does, we continue to iterate on our compensation model, and implemented a number of changes at the start of 2019. In addition to adjusting the salaries of backend developers, which were raised considerably so that we are “at or above market,” according to GitLab CEO Sid Sijbrandij, the location factor was also revised to better reflect the respective areas covered.
But first, let’s take a step back to see how we got to here…
The part about standard pay eating away at production and personnel was pretty interesting to me. In the end, this is a world problem, not a business problem. Too much pressure gets put on businesses to solve problems they just can’t solve.
Sid Sijbrandij and the team at GitLab compared GitLab CI with the three Jenkins variants. Here’s what they learned…
The many plugin combinations for Jenkins has made Legacy Jenkins hard to configure and brittle when updating. Cloudbees is introducing two new versions of Jenkins to remedy the problem: Cloud Native Jenkins will start from scratch, while Jenkins Evergreen will focus on a set of essential plugins. GitLab CI adds new functionality in the main code base, avoiding the need for needless configuration and ensuring everything still works when updating.
Also to note — according to a recent Forrester report GitLab CI and Jenkins/Cloudbees are two of the four leading products for CI.
A deep dive into the process of turning the idea for an integrated web IDE into a reality. Looks like a great start!
After explaining why it all matters, Kushal Pandya covers four common situations that you might face while working with Git:
- I need to change the most recent commit
- I need to change a specific commit
- I need to add, remove, or combine commits
- My commit history doesn’t make sense, I need a fresh start!
No other details were shared in this tweet, but this image from the stage of WWDC says all it needs to.
In a post-Microsoft + GitHub world — it has been a crazy 24 hours for GitLab.
More than 2,000 people tweeted about #movingtogitlab. We imported over 100,000 repositories, and we’ve seen a 7x increase in orders. We went live on Bloomberg TV. And on top of that, Apple announced an Xcode integration with GitLab.
Here’s an interesting exchange between Emily Chang and Sid Sijbrandij on Bloomberg Technology:
Emily: I spoke with Satya Nadella earlier today, and he said “he promises to put developers first.” Do you not believe him, or do you think it’s not possible for a company with so many objectives to really put developers first?
Sid: I believe him. Microsoft has shown that it is the new Microsoft, and they’ve done great. The new CEO, Nat Friedman, shows he really understands developers. So I believe him when he says they are going to be good maintainers of GitHub.
Emily: So, then what’s so bad about GitHub?
Sid: There’s nothing bad about GitHub.
Emily: What’s so much better about GitLab?
Sid: It’s a fundamentally different product. It’s open core, so a lot of it is open source. You can host it yourself. But second and I think most importantly, it’s not just code hosting. With GitHub you host your code. GitLab is the entire DevOps lifecycle. So all the way from planning something to rolling it out, container registries, monitoring — all in a single product. That allows you to get the whole organization on the same page. And that’s why people are flocking to it.
They go on to talk about being a sustainable business, financials, etc.
Erica Lindberg, writes on the GitLab blog about preventing burnout:
Set clear boundaries between work and home — I’m trying to limit how many days I allow myself to work over eight hours by either scheduling other activities in the evening with friends or my partner (it works better when you’ve committed to someone so they can help hold you accountable. These things can be anything from rock climbing to dinner or watching a movie) or simply blocking out my calendar and setting reminders for when it’s time to shut off. And when it is time to shut off I’m come up with a “ritual” of shutting down my computer, turning off my keyboard, monitor, and light in my office – this makes it harder to come back to “just finish up one last thing”
I really needed to be reminded of this. It’s a shame when you know what to do, but you choose not to, and allow yourself to creep closer to burnout.
Hazel Yang, on the GitLab blog shares insights about her last two years working at GitLab:
- Show gratitude
- Learn from failure
- Trust your team and grow with them
- Befriend managers and colleagues
- Embrace diversity
I’m a HUGE fan of the concept of a “retrospective” which is most known by developers as a practice of agile software development. It is important to look back and review what’s going well, what’s not going well, and what needs to change or be stopped all together. This post is a product of that type of discipline.
