DEV Community: Lucas Rocha

That’s why I love interactive rebase

Lucas Rocha — Thu, 09 Nov 2023 19:51:17 +0000

You probably already struggled to change a specific commit, rename it, remove it, and anything else. I’m glad to welcome you to the interactive rebase power!

What is interactive rebase?

In my words, interactive rebasing allows you to manage anything you want to your commits. You can navigate through the history, pick the commit, and change it as you wish.

Here’s everything you can do to every single commit:

It lets you choose between the options (aka rebase commands) and perform the desired action without running many git commands manually, so you’ll have less work and headache.

My top ones are:

fixup (similar to squash)
reword
drop
edit
pick

You can also change history by changing the order of the commits!

Putting into practice

Given this highly complex javascript code:

function foo() {
  console.log('Foo')
}

function math() {
  console.log(5 / 1)
}

function year() {
  console.log(new Date().getFullYear())
}

And the following commits for each function:

# git log --oneline

eaefd90 (HEAD -> main) add year
f576984 add math
1e2458e add foo

I want to:

Edit the math function
Rename the year function commit

Firstly, we must tell the rebase command the range of commits we want to pick from the HEAD. There are various ways, but I’ll use the command I most use

Range from the top (but the initial)

git rebase -i HEAD~2

~X is the count of commits from the latest one

Result:

pick 7d0bb76 add math
pick 6227988 add year

Do you remember the rebase commands from the screenshot? Let’s use them now. Rename the pick by the option you want to apply to a specific commit:

edit 7d0bb76 add math
reword 6227988 add year

Now save, edit your math commit changes, commit again, and continue the rebase

git add .
git commit --amend
git rebase --continue

A new prompt will open, asking you to insert the update for the add year commit message.

lucasgrocha.com

Risk of data loss

Since everything has pros and cons, It wouldn’t be different with interactive rebase, but don’t worry!

There’s a chance to break the commit history and lose all of your changes. No problem, though. Let's continue using the git power to help us in this case. I have already failed thousands of times doing this, and here are my takeaways:

If you are unsure about your rebase, create a backup branch before changing your working one
Save the commit hash you will change (copy it into a text file, etc.)
Push your changes to the remote (GitHub, Git Lab, etc…)
Be aware of git reflog superpower. With this fantastic tool, you can track all of your changes in your git branch and pull them easily by git cherry-pick <<COMMIT HASH>>

Conclusion

Interactive rebase has way more functions and utilities than this example. Create your experimental repository, play with all the commands from there, and start using it daily.

Also, don’t be afraid of losing any work. The git tracks ALL the things for you, and the only thing you’ll need to do for a worst-case scenario is figure out how to pull your commit again (git reflog is the best starting point).

Commits are malleable, git provides all the tooling, and we are in the ChatGPT age, so why not try out new things? We have countless sources for research and learning.

Feel free to search and learn more about this fantastic tool! ✨

Better Code QA - Benefit of Unit Testing

Lucas Rocha — Tue, 07 Nov 2023 21:28:28 +0000

Did you already find yourself trying to understand a complete rabbit hole code, or do you want to test your brand new bug fix without running a bunch of flows and business rules that may involve third-party endpoint calls?

Let's try tasting small pieces instead of eating the whole pie.

Why? What's the benefit?

I already spent countless hours of my day just trying to prove that my code works by running the step-by-step to reproduce the issue, and in the end, I found myself very stressed because most of the time, you'll miss setting some attributes that will conditionally trigger your fix. V*oila,* stress level increased.

In my personal experience, the benefits are these:

Faster development/comprehensibility
Faster QA
Faster CI/CD
It is more straightforward to track down a flow throughout the codebase

The painful process

I need to create a new user, set their config to this, update this row, update this other thing, and make sure the payload is that… And while you are thinking through all of this, you have to answer some DM's, monitor logs, etc.

There may be a more straightforward way to test your code that doesn't require all these painful steps.

Let's play with some code

Consider this concise ruby class that calculates the BMI number and returns true/false if the user is underweight (you just added this functionality).

class User
  def initialize(weight:, height:)
    @weight = weight
    @height = height
  end

  def bmi
    (@weight / (@height * @height)).round(2)
  end

  def underweight?
    bmi < 18.5
  end
end

Here are the unit tests:

Test if the BMI amount is the expected one for the given weight and height
Test if the given weight and height is underweight or not

class TestUser < Test::Unit::TestCase
  def test_bmi
    assert_equal(15.43, User.new(weight: 50, height: 1.80).bmi)
  end

  def test_underweight?
    assert_equal(true, User.new(weight: 50, height: 1.80).underweight?)
    assert_equal(false, User.new(weight: 80, height: 1.80).underweight?)
  end
end

So, how can I prove that this #underweight? method work as expected? Someone may say: "It's easy. I know exactly the inputs I need to give to test that method, and I know the output value by calling the #bmi method.” Yes, you're completely right, It’s already known all the business rules and the flow as well:

user = User.new(weight: 50, height: 1.80)

user.bmi
#> 15.43
user.underweight? # 15.43 is less than 18.5
#> true

Let's forget about the #bmi for a brief moment so that it doesn't exist anymore. Now, we are entirely blind about what the calculation is. So, how can you prove the #underweight? method works?

Take It Easy

We don't need to know the math behind the BMI calculation. We only need to know the conditions that make the #underweight? respond precisely to what we want. If the BMI is 15, the expected output is true since you have this condition: x < 18.5 .

We already know this condition, so we can hard-code the BMI amount and test our method again:

def underweight?
  15 < 18.5
end

That looks simple, and it is what it is supposed to be, though. It’s the essence of unit testing: mocking values and method’s responses to make the other X method respond to what our automated tests are looking for, and at the end, everything is tested by attacking small pieces per time.

Now we just have proven that #underweight? the method works without having to instance the class, providing the right inputs, learning the calculation behind it, and so on. Get the target condition and hard-code the expected information to see Its desired behavior.

Either 15 or < 18.5 could be a completely different condition that could call a lot of methods in the chain, and you would need to know precisely the inputs, Their formats, and conditions behind the scenes.

Conclusion

I've been doing this practice for a long time whenever I need to, and since I got this insight, I try to use this approach in my tickets as much as possible. It's effortless and helps me to have an general view depending on the case because I can keep iterating the perspective like:

Understanding the small pieces
Take a step further and understand the small pieces from a different part
Comprehend the whole thing without needing to run the entire thing at once