When Feedback Turns Comical (But not in a good way)

We’ve all been there. The long-awaited moment when your code goes under the microscope, and you get gems like:

• “This is garbage.”
• “Sh*t code!”
• “Do you even know how to code?”
• “You must be joking with this pull request.”
• “This looks like spaghetti code thrown against a wall.”
• “You’ve just set the project back by weeks.”

Decoding “It’s Sh*t Code”

When faced with such cryptic feedback as “It’s Sh*t Code”, a developer might wonder:

• Lack of Guidance: This phrase doesn’t illuminate the problem, nor does it suggest ways to rectify it.
• Morale Impact: Sharp criticisms can sap motivation, leading to dwindling enthusiasm for the task at hand.
• Clarity Concerns: “Sh*t” refers to…? Without context, it’s hard to pinpoint what “sh*t” refers to. Is it about the structure, the logic, or something else?
• Professionalism: Using crude language is unprofessional and can degrade the team culture and trust.

The Gentle Art of “Not Making Your Colleague Cry”

Ideal feedback during a code review should be:

• Explicit: Less “What is this mess?” More “This section could use a comment for clarity.”
• Neutral-Toned: Keep the focus on the code, separating it from the coder.
• Solution-Oriented: Instead of just highlighting a problem, suggest a potential fix.

The Beauty of Constructive Zingers

Constructive feedback not only points out issues but also guides towards improvement:

• Instead of: “This code is messy.”
  Suggest: “Consider breaking this function into smaller ones to improve readability and maintainability.”
• Instead of: “This section seems off.”
  Suggest: “Maybe we can modularize this part for better clarity.”
• Instead of: “The chosen algorithm seems slow.”
  Suggest: “Given our requirements, perhaps [algorithm] might offer faster performance.”
• Instead of: “I can’t follow this logic.” or “This part is confusing.”
  Suggest: “Maybe we can modularize this part for better clarity.”

Embracing the Benefits of Thoughtful Feedback

• Elevated Code Standards: Better feedback, better code, better coffee breaks.
• Positive Team Environment: Less side-eye, more high-fives.
• Personal Growth: We’re all here to level up, right?

Share Your Hall of Fame… or Shame

What’s the most “creative” feedback you’ve received? The funnier, the better. Let’s laugh (or cry) together and create a more constructive code review culture.

To Infinity and Beyond

Code reviews: the final frontier in a developer’s journey. Let’s make it less about surviving and more about thriving, one constructive comment at a time.

The post The Art of Constructive Code Review: Why “It’s Sh*t Code” Doesn’t Cut It🎨💻🔍🚫 first appeared on forceUnwrap.

However, it’s not uncommon for developers to forget to rebase their feature branch and end up with multiple conflicts. So, what should you do in such a situation?

Here are the steps to rebase and skip conflict-solving in every conflicting commit:

Step 1: Ensure Your Local Develop Branch is Up-to-Date

Before starting, make sure that your local develop branch is up-to-date with the remote repository’s develop branch by using the following commands:

git checkout develop
git pull

This ensures that you have the latest changes made to the main/develop branch on your local machine.

Step 2: Reset the Feature Branch

Next, you need to reset your feature branch to a single commit, which will make the rebase process simpler. You can use the following command to reset your feature branch:

git checkout feature/newFeature
git reset --soft HEAD~<n>

Here, <n> is the number of commits you want to squash into a single commit. For example, if you want to squash the last 21 commits into a single commit, you can use git reset --soft HEAD~21.

Step 3: Create a New Commit

After resetting the branch, you can now create a new commit that represents all the changes made in the previous commits. You can use the following command to create a new commit:

git commit -m "New feature implementation"

Here, the commit message can be anything that describes the changes made in the feature branch.

Step 4: Rebase the Feature Branch

Now that you have a single commit representing all the changes made in the feature branch, you can rebase it onto the main/develop branch. Use the following command to do this:

git rebase develop

This will apply the changes made in the main/develop branch onto your feature branch.

Step 5: Resolve Conflicts

If there are any conflicts during the rebase process, Git will pause and prompt you to resolve them. However, since you have squashed all the changes into a single commit, you will only need to resolve conflicts once, instead of resolving conflicts in every conflicting commit.

Once you have resolved the conflicts, use the following command to continue the rebase process:

git rebase --continue

Step 6: Push Changes

After completing the rebase process, you can now push your changes to the remote repository. Use the following command to do this:

git push --force

The --force flag is required because you have rewritten the history of your feature branch.

In conclusion, by following these steps, you can rebase your feature branch and squash all the changes into a single commit, which will simplify the rebase process and help you avoid resolving conflicts in every conflicting commit. Remember to regularly update your feature branch with the changes made in the main/develop branch to.

The post Undo the most recent local commits in Git first appeared on forceUnwrap.