DEV Community: Nowshin Alam Owishi

Watch Out for Cherry-Pick

Nowshin Alam Owishi — Sat, 09 Aug 2025 13:56:42 +0000

It’s a bit of a read, but spending a few minutes now could save you hours of pain later.

What is cherry-pick 🍒?

In many situations, you might want to copy specific code changes from one branch into another. Git offers a command for this:

git cherry-pick <commit-hash>

This command copies the content of a specific commit (by hash) and applies it to your current branch.

Keep in mind: Git applies only the changes from the commit, not the commit itself.

Applies the commit's diff as a new disconnected change
Creates duplicate commits with a different SHA hash
Maintains no relationship to the original commit

When to use it?

When you are working and testing on your branch and want to reuse one commit in other branches without merging everything.
In case of emergency fixes. Like, introducing a hotfix to a previous release.
You need a specific functionality from a branch that is not fully ready to merge yet.
Need to revive specific commits from a branch that won't be merged anymore.

Cherry-pick is a powerful tool, but it’s not a one-size-fits-all fix. While it can be convenient, it must be used with caution. This doesn’t mean cherry-picking is inherently bad or should be avoided completely, but it does carry risks. Often, issues arise not from the tool itself, but from how it’s used. These mistakes are common, which is why understanding them is crucial. I will address some of the potential risks of cherry-picking and how to dodge them.

The Hidden Dangers of Git Cherry-Picking

Situation 1: Merge Hell

Imagine you're working on the feature/dashboard branch. Halfway through, you discover a critical API bug that needs to be fixed for your upcoming feature. On the other hand, your teammate, Ahmed, is already fixing it in his bugfix/api branch with other issues, but he needs a couple of days to complete all the fixes.

What You Do

Ahmed provides the fix you need with a commit. Later, he tells you to cherry-pick that commit. So, let's say the hash is F and you cherry-pick using the specific commit hash: git cherry-pick F
The fix works! You continue developing your dashboard. Currently, the situation is like the image below:

A week later, Ahmed merges his entire bugfix/api branch to main. Remember, it also has the commit that you cherry-picked earlier.

The Surprise

Later, you find conflicts of identical changes while trying to merge your dashboard. Depending on the changes of the commits, it can be complex.

What Git sees

The original fix (from Ahmed's merge)
Your cherry-picked version (same changes, different commit hash)
Treats them as conflicting changes Now it hurts because you're forced to manually resolve conflicts that shouldn't exist, wasting hours on what should have been a clean merge. The situation can be described as in the image below.

Situation 2: Disappearing Changes

Now, imagine you're fixing a security issue with login notifications, in your bugfix/login branch. You need to disable the feature temporarily while you fix the underlying problem.

Your Steps

Create a temporary fix in a new commit that disables notifications: NOTIFICATIONS_ENABLED = false in your bugfix/login branch.
Cherry-pick that commit into the production branch as an emergency patch.
In your bugfix/login branch, you fix the root issue. After thorough testing, you re-enable notifications (NOTIFICATIONS_ENABLED = true) and merge your bugfix/login branch to production branch. Everything seems fine, no conflicts.

The Silent Disaster

Users report notifications are still off, and you don't know why. I have added an image so that you can get the situation. I've shown the value of NOTIFICATIONS_ENABLED at the top of each commit bubble.

What Happened?

Git will compare by the 3-way comparison of Git merge:

The value that the base commit has, which is true. Since the cherry-picked branch has a changed hash, it won't be considered the common base commit.
The latest value of the bugfix/login branch is true, so Git thinks there were no changes.
The latest value of the production branch is false, so Git thinks there was a change made later, and without showing any conflict, it replaces the value with false.

Situation 3: The Extra Changes

Suppose your feature.js on main branch has a method named isFeatureEnabled(), that is modified in bugfix/user-access branch, and now you wanna cherry-pick the latest changes made to that method onto the main branch. Let's say the commit is C. After running git cherry-pick C, you are seeing extra changes that were not in the commit you have picked.
I have shown the changes of feature.js across commits and branches.

The Hidden Problem

When you cherry-pick a commit, Git calculates the diff between that commit and its parent, and tries to apply that diff onto your current HEAD. This diff includes not only the changed lines, but also context lines (unchanged lines around the change). Git uses context to figure out where in your codebase the patch should be applied. If the context doesn't match because your branch has diverged significantly, Git can't put the patch cleanly and will throw a conflict, prompting you to resolve it manually. That’s why you might see lines from earlier commits (B) appear again during a cherry-pick of commit C, especially when commit C was built on top of changes you don't have in your branch.

How to Fix?

Situation 1: Merge Hell

Abort the merge, rebase your source branch onto the target branch. Test your changes thoroughly and review the diffs to ensure everything looks right. It might take extra time, but it's better than dealing with a broken merge later.

Situation 2: Disappearing Changes

This one’s tricky since Git won’t show conflicts. If you've already merged and pushed, you'll need to either drop the bad commit or manually fix the logic. Then again, rebase your source branch onto the target branch and carefully review git diff before merging.

Situation 3: The Extra Changes

Be careful while fixing conflicts. Be aware of your changes, and perform a thorough review.

So, rebase or/and git diff with thorough review is my ultimate solution.

How to Avoid These Situations?

Always review the difference after cherry-picking, then push to the remote, even if Git shows no conflicts at all. Do git diff HEAD^ HEAD, or git show. This ensures the commit didn’t smuggle in unrelated changes due to contextual patching.
Avoid cherry-picking someone else's commit unless necessary. If needed, create a patch branch and merge it into other branches. This preserves the original commit hash and avoids duplication. If cherry-picking is unavoidable, communicate clearly with your team and track which commits were moved.
Use -x to track cherry-picked commits.

git cherry-pick -x <commit-hash>

This appends the source commit hash to the message. You can see the commit message using git log -1:

commit aa334sss (HEAD -> temp-commit)
Author: iamauthor <author@gmail.com>
Date:   Wed Aug 6 16:47:06 2025 +0600

    test: try cherry

    (cherry picked from <commit-hash>)

Isn't There a Better Way to Solve?

There are plenty of ways to fix cherry-pick issues, but I stick to what I’m comfortable with. cherry-pick is just a tool, and like any tool, it can make life easier if used properly. Git doesn’t know how your code works, so while it automates a lot, it still needs your attention. That’s why I am mentioning thorough reviews. And sure, technical tools help, but nothing beats solid team communication and regularly syncing with the branches you’re merging into. Take the time to understand Git and use it carefully, instead of picking up a bunch of complex tricks only to forget them later.

See you next with Danger: You lost work or rewrote authorship after squash and force-push!

The Message is the Bug

Nowshin Alam Owishi — Fri, 25 Jul 2025 17:25:49 +0000

Git isn't something we study every day, yet we use it daily. Most of the time, we cycle through the same handful of commands, such as fetch, add, commit, and rebase, like muscle memory. It's ironic how something so essential remains so frustratingly complex.

I'll be writing about some of the lessons I've learned from Git. To make things more readable, I'll be writing in separate blogs. I hope that it will help you avoid the disasters I once walked straight into.

Let's start.

Lazy Messages Can Come Back to Wreck You

Using git blame
- You are in a hurry, office time ends in 2 minutes, you wanna commit with messages like "asdf" or "fixed bug", thinking you’ll finish it after the weekend, why spend so much time thinking about it?
- But somehow that weekend passes, and fast-forwarding two months later, you re-opened that project at 2 AM, or a teammate inherits your code. Suddenly, git blame points to "asdf" and the author has your name. Now everyone hates you, including yourself.
Using git bisect
- Suppose the production failed, and you need to know which commit failed. You are using git bisect and find out that a commit with 55 file changes, and a commit message as "fixes", has caused the issue.
- Now, good luck first finding what the fixes were, then finding the one that introduced the bug.
- A good, well-written commit message may let you skip the first one. You would already know what the changes were and focus on finding the bug.

What Went Wrong?

You wrote commit messages for yourself, not for:

The developer who joins next year
Your sleep-deprived future self
The debugger team
Or any other person who wants to read and review your code

What Should You Do Then?

Think of what you have done: Find out the core and crucial changes in your commit. Have multiple fixes in a single commit? Write with comments.
Think of the audience: Write messages so that anyone engaged in that project can decode them in 10 seconds.

Here are some examples of proper commit messages.

# Commit message 1 (with comments)- 
fix(auth): resolve critical security issues

- Handle null case in session timeout logic
- Fix authentication bypass in dashboard

# Commit message 2
feat(ui): implement dark mode toggle [WIP]

Write What Matters

Clarity beats rules, everything else is secondary. The first and foremost thing in a commit message is that it should be understandable. The 50/72 rule won't be helpful if the commit message is ambiguous.
Aim for precision first, add description when the impact or fix isn’t obvious. Long commit messages are often a symptom that maybe your commit includes too many unrelated changes. Each commit should ideally represent a single logical unit of work, and its message should reflect that.

You can find resources online on how to write proper commit messages. You'll get incredible guides on commit messages online; the internet has perfected this art far better than I could summarize here.

How to Add a New Commit Message

Single-line Commit Message

git commit -m "Add login validation"

# Or

git commit --message="Add login validation"

Multi-line Commit Message

git commit -m "Add login validation" -m "Added frontend and backend validation for login" -m "Closes #123"

Editor-based Commit Message

git commit

An editor will open, and write your commit there. However, you will have an advantage here. If you wanna break down your commit message into bullet points, leave an empty line after the subject, then start each line with a - for better readability (just like markdown).

fix: handle session timeouts

- added null check for expired tokens # bullet point 1
- ensured redirect to login page # bullet point 2

You can view your commit history, including the commit message, using git log.

How to Alter Previous Commit Messages

Change the Latest Commit Message

git commit --amend

This opens your editor. Update the message, then save and close.

Change an Older Commit Message

You will need to use interactive rebase for this.

git rebase -i HEAD~3 # 3 is the position of the commit relative to the HEAD
# Or
git rebase -i abcd1234^ #abcd1234 is the hash of the commit that you wanna change

This will open a list of the last 3 commits in your default editor:

pick abcd1234 message you wanna change
pick aswd1235 other commit
pick iucd2234 other commit

Change pick to reword (or r) for the commit you want to edit:

reword abcd1234 message you wanna change
pick aswd1235 other commit
pick iucd2234 other commit

Then save & close.

Git will open another editor window where you can change the message. Modify and save again, and you're done!

⚠️ Heads-up

git amend and git rebase rewrite history; they change the commit hash. If you’re editing an older commit (not the latest), rebase will also modify the hashes of all commits that come after it. Be careful when force-pushing, especially on shared branches, you might overwrite others' work.

I chose this simplest yet crucial topic to give a good start to the series. Meet you in the next part with a more complicated topic - cherry-pick 🍒!

Key Aspects to Consider in Software-Based Competitions

Nowshin Alam Owishi — Thu, 25 Apr 2024 21:46:10 +0000

My experience during my undergraduate years was filled with ups and downs. I participated in three software development-based competitions during my undergrad and was fortunate to place in each, despite feeling like I was on the verge of failure many times. However, I believe now is the perfect opportunity to share my thoughts. I'll only focus on weeks or month-long competitions where you will have enough time for careful planning, coding, and execution. Let's delve deeper.

Get a supportive teammate

You should focus on exploration and learning, rather than just winning prize money. You may not be interested in every aspect of a project. For example, you might excel in coding, but you lack in presentation or design. Get a partner who can fill up your limitations. Collaborating with others can also help enhance your skills.

Leverage Existing Resources

It's crucial to prioritize your efforts to make the most of your time and learn how to code effectively. Instead of spending time on tasks that can be easily found online, you can visit GitHub to explore existing codes, see how they work, and reuse them. If you lack in designs, visit the UI templates-related websites. Use ChatGPT, Bard or any resources that can speed up your project. Merge your thoughts with the resources. Instead of copy-paste, try to understand the code. Put more effort into the core features that prove the unique characteristics of your app.

Let me tell you my experience. In Therap Javafest 2023, my teammate and I wanted to create games for children using p5.js. We started by researching existing games available on the internet and drawing inspiration from them. Then, we delved into p5.js implementations to gain more knowledge. We came up with some ideas that were both feasible and entertaining. Meanwhile, we took a straightforward approach to the chatbot and grammar fixing. We utilized the ChatGPT API and some prompt engineering only.

Focus on Tech Implementation

When participating in a competition, we tend to focus on finding the most unique idea possible. However, the key to success lies in the idea's implementation using existing technologies. Remember, your innovation should involve exploring and learning while keeping an eye on winning the prize. If your idea doesn't have an interesting perspective from a technological standpoint, it may not have much impact.

Read blogs and research about technologies to ensure that you use the most efficient and exciting technology. Make a stack of potential technologies and tools, then generate an idea that covers everything. It's necessary to challenge yourself, but it's equally important to be aware of your capabilities. Don't put yourself in a situation where you suffocate in an ocean of challenges later.

For example, to learn how to implement any specific feature, start by establishing the basic development stack. Next, take some time to find an inspirational example and take note of these. Discuss with your partner to determine a feasible implementation plan. Then decide on the specific features you want to include and add your unique touch. Find some more features like that. Include 1-2 extra features in your initial planning as additional options. Don't go overboard with too many fancy features. It just makes it too much to handle. Additionally, basic features such as email verification during sign-up help to build a good foundation. These features are usually easy to implement.

Push Yourself to the Limit

Make sure that the time you spend on something has a positive outcome. If you're working on a project, make sure it's something you can show off later and that you learn something from it. Agile development can be stressful for software engineers, but it is also an opportunity for growth and learning. Try to challenge yourself and learn new things. Instead of using more and more similar frameworks, use frameworks to serve different purposes. You might not understand everything you're trying to learn, but your effort will still help you improve your skills.

Adopt Best Practices

Always remember that you can build a project even overnight. Everything you need is available on the internet. If you can't find something, don't worry - you don't know the right keywords yet (this line is for beginners only). Even if you are a beginner in the development field, try to implement good practices. For example, start with good naming conventions, and later work on structuring your frontend and backend. This will make your codebase more appealing to the judges.

Develop Soft Skills

Presentation is a crucial aspect of any competition. You may have an excellent project with many tools, but your presentation will display the value. Getting up on stage and improvising a speech is not going to work always.

To ensure a successful presentation, practice as much as you need to. Don't just display your code, as it may not be easily readable on a big screen. Instead, use diagrams and structures with a fluent speech that will help you connect with the audience. Show how well your project performs rather than just demonstrating that it works. For instance, if you have a chatbot for children, rather than asking a simple question like "How are you?", ask something more captivating that only children may ask, like "Can birds swim in chocolate?" If you handled it perfectly, the answer will showcase your effort gloriously.

Keep in mind that grabbing the attention of an audience is not an easy task. Practising your presentation will help you overcome the fear.

Accept Imperfections Gracefully

Sometimes, despite your best efforts, a project may not turn out as expected. If this happens, don't get frustrated. Instead, take a step back and identify what went wrong. Start by listing the things that didn't go according to plan. It is acceptable to acknowledge logical flaws or limitations while highlighting positive aspects. For example, you can mention if you're facing issues with some public APIs that are not working as expected. Using paid tools won't make a significant difference in the competition. Your primary focus should be on the main feature of your project. It could be the structure, scalability, or implementation - anything you put your heart into. So explain the reasons to the judges and put pride in your efforts.

Always keep two things in mind: firstly, no matter how much you prepare, you can never be fully ready. Attend the competitions with whatever you have. Secondly, regardless of your position, there will always be someone better than you in the competition in any aspect. That's why keep an eye on others, communicate with them, and learn from their techniques. If you can master this approach, you can make the most of any competition you participate in.

There are many points to note down. Take your time to accomplish them. Starting is better than nothing.

My teammate @shikarisohan and I placed first on Therap Javafest 2023. I have attached the GitHub link below.

Happy coding!

ShikariSohan / kiwi

Kiwi

An AI Powered Digital Playground Where Education Meets Imagination

Overview

The Kiwi is a solution that uses AI to transform children's digital experiences, enhancing learning and creativity. It stands as a beacon of hope, showcasing how AI can be harnessed to address the complex relationship between children and technology in today's digital age.

Key points of Kiwi :

Conventional Learning: Old learning but with new technologies
Creative Learning: Learning with innovations
Play & Fun: Games for learning
Scalable Structure: Microservice in Java

Watch a demo presentation of the app here.
A PDF generated by our app is shown here.

Features

Learning & Fun
- Draw n Learn: Word Writing Practice Through Drawing
- Grammar Guru: Sentence Creation and Error Correction
Creative Corner
- Magical Story: Give Prompts and Generate Graphical Storybook PDFs
- Talky Pal: Interact with an Avatar Bot for Learning and Conversations
- Chat Buddy: Engage in Personalized Chats with…

View on GitHub