How I Prepare Merge Requests

My workflow with gitlab is a bit different from other developers.

In this post I show the trick I use to code more effeciently.

This is especially good for part-time developers, or if you work on multiple tasks at the same time.

My name is Till Carlos and I run an agency for insurance and AI projects. I document the trainings for my team, so that we can all improve.

And today we look into how to write good merge requests / pull requests.

Backstory

Some people like to only submit code that’s already working perfectly.

My brain has the --verbose flag set - all the time. That’s how it goes:

• I say what I am about to do
• Then I do it
• Then I tell my team what I just did.

The reason why I do this is: project managers love it. And I’m managing some projects myself. Therefore I make this video. It’s for my team and for you to forward to your developer.

And today we are looking at how a good merge request flow looks like:

Step 1: Create the Merge request with a first commit.

Begin by creating a merge request with your first commit, regardless of its size or completeness. This action opens up GitLab’s “new” feature, providing immediate visibility to your team about ongoing work.

Rule of thumb: Commit code after each logical change, aiming for at least one commit per hour.

Caveat: yes, we need to learn rebasing for that. Learn it now, search for “Till Carlos - Git Rebase” on youtube.

Step 2: Write the MR description

Elements of a good MR:

• State the current situation
• State the desired outcome
• Make a checklist of what needs to get done
• Add some optional tasks, things found / things to improve.

Side note: you should always have the link to an issue tracker / project management system as well.

Step 3: Tick all the boxes and implement

While I code I now have a checklist I can work against.

I know, this is a small and almost obvious thing to do - but I know many people are not doing it.

If you want to see the feature I’m currently building, have a look at my channel in the next few days.

Spoiler: it looks like this:

Pushing a lot of code requires rebasing.

If you want to learn how to do that, watch my video on git rebase.

Watch the full video tutorial on Youtube