Git merge vs git rebase - why you should avoid using Git merge to update your branches?

Piotr Nalepa — Tue, 20 Sep 2022 09:42:47 +0000

Git is a the most popular version control system in the software engineering world. Its popularity grown even bigger with the raise of Github, Gitlab, Bitbucket and similar tools. When you think about software development Git is a crucial part of it, you just can’t live without it if you’re doing it professionally.

Background

Imagine you’re working on some big feature that requires a lot of time to implement it properly. In the meantime your team members are developing their own tasks. They get reviewed and merged to to the branch: master, main, develop - you name it (I'm going to refer to it as a source branch later in the text).

At some point you realize that it would be good to update your working branch with the latest changes from the source branch. It can be tempting to do it by either running git merge <source-branch-name>.

Update with merge commit option. After doing it the list of commits is increased by a number of merge commits.

Notice, there are commits starting with Merge branch ‘develop’ into … those are the merge commits, but if you take a look at the branch history on Git it looks even more messy.

In the Github UI there are 12 commits, but when you’re looking into the Git history you can see there are 19 commits in total.

Git merge is a bad idea

You might be wondering what’s the problem there? IMO, it’s bad because it messes up your work with someone else’s work. Mixing commits leads to confusion when trying to find a specific commit that introduced a specific bug or trying to squash all your commits into one with git rebase -i HEAD~<number-of-your-commits>.

In general, your work should be always on top of the source branch commits so you can easily find out what does your work contain and, what’s more important, you can have a flat commits history in your branch. In the last picture there are 3 levels of commits caused by using git merge. Which can be problematic to read sometimes. More nesting levels mean more complex graphs to read and to understand the history of changes.

Using git rebase will help you:

To have a clear list of changes in your repository. You’ll know what change is an effect of another.
To have a linear history of changes. No nested levels of commits making it difficult to read.
To debug your code easier with git bisect. This command is really cool to find the exact commit that broke the code. With that you can mark which commits are good and which are broken. You can read more about it here: https://git-scm.com/docs/git-bisect

What can you do instead?

To learn more about what can you do instead go to the full version of this article.

Dealing with Promise.all() and a bunch of async functions

Piotr Nalepa — Thu, 02 Jul 2020 05:55:08 +0000

Recently I've been in the situation where I needed to resolve multiple async functions in paralel. The tricky part was that these functions were written using async/await approach and I was going to use Promise.all() function to resolve all of the async requests at the same time, when all of them are resolved.

I'm not going to tell you much about Promises and async/await. I assume you have already gained proper knowledge regarding how to use them in your project.

The first approach

In order to handle such situation where I had a bunch of async functions I managed to put them all into an array and use it as a param of Promise.all() function. Just like that:

Promise.all([
    await dispatch(fetchDataFromOneSource),
    await dispatch(fetchDataFromAnotherSource)
])
.then([data1, data2] => {})
.catch(error => console.log(error))

The code listing above is simplified in order to focus on the most important part.

As you can see, I'm using:

[
    await dispatch(fetchDataFromOneSource),
    await dispatch(fetchDataFromAnotherSource)
]

as an input param of Promise.all(). As we all know, async/await approach is just a syntax sugar for Promises, so I expected to have all promises resolved when data is ready. It works perfectly fine, when all promises are resolved correctly. The then() part is run and everyone is happy.

In my case, there were specific situations when one of the async functions should fail and this should prevent from running a callback of then() part. I expected that catch() will be invoked instead.
I was so wrong! All of it failed silently and except showing errors in the browser console nothing happened in the UI, while it should!

The second approach

At the time being I was rushed by the deadline and I've come up with a following solution:

Promise.all([
    await dispatch(fetchDataFromOneSource)
        .catch(handleError),
    await dispatch(fetchDataFromAnotherSource)
        .catch(handleError)
])
.then([data1, data2] => {})
.catch(handleError)

It solved my problem but it was not the most elegant solution in the world. It bothered me a lot. Duplicated error handlers for each promise was not the most optimal solution in my case.

The final approach

Finally, after thinking for hours. I realised where was the mistake and how to make the previous version more elegant:

await Promise.all([
    dispatch(fetchDataFromOneSource),
    dispatch(fetchDataFromAnotherSource)
])
.then([data1, data2] => {})
.catch(error => console.log(error))

This also worked as previously, but the final piece of code looks better and it's less hackish now.

It's worth to mention, that running await Promise.all() allows you to assign its output to a variable and maybe destructure it, if needed, and then proceed with next actions instead of running the then() callback param.

Summary

By writing this article I wanted to clarify the statement I wrote on Twitter:

TIL: If any promise in Promise.all() will fail then catch assigned to Promise.all won’t work. You have to add catch to all promises in the array of promises used a Promise.all param. #javascript
— Piotr Nalepa (@sunpietro) March 17, 2020

I was wrong then. The catch will be invoked when the array of Promises contain the Promise objects itself, not the invokations of async functions.

I hope this article clarified it and it will help you solving issues in your projects.

DEV Community: Piotr Nalepa