Clash Royale CLAN TAG

What's the best practice for amending a merged remote branch?

For example, I've finished a feature branch, pushed and merged it into the remote develop branch. After 3 days, I find a typo on that branch, then what's the best way to amend that branch. Create a new branch to correct that trivial mistake or re-work on the old branch? Could you please give an example with git commands for this? Thanks!

1 Answer
1

If I understand correctly, you're talking about a policy issue, not really a technical one. The technical part is the same - you'd treat it as any other change. Another branch to be merged in, if that is your workflow.

Whether or not you're committing that new typo on a new branch or the just-merged old branch doesn't matter to git, the tree looks the same in both cases.

Here's how it would look like after the merging of your minor commit:

A-B-C-D-G-H-I-J (develop, newMergedBranch or oldMergedBranch)
/ /
E-F----Typo


One place where it does matter is the merge commit itself. It would say Merged in branchName. So depending upon how you want it to look (if the merge commits aren't being edited) you can choose which branch name you want to use.

Merged in branchName

Clarification about effects of amending, in response to comment:
Whether or not amending is bad practice depends on whether people are now working off of D. If someone made commits on top of D, and then you amend an earlier commit (say F, using git rebase -i), you'd change everything downstream of it.

git rebase -i

A-B-C-D--G-H-I-J (other develop)
/
E-F D' (your develop, oldBranch)
F'/ (Typo)


To resolve this (without forced pushes - with forced updates, all of the pulls from D have to force pull, potentially losing changes if they're not aware. They'd first run into pull conflicts, even if they're doing everything right. This is the reason why history amending for exposed branches is considered bad practice), one would have to merge your develop:

A-B-C-D--G-H-I-J-K (develop, old branch)
/ /
E-F D'-------
F'/ (Typo)


To clarify, D' isn't downstream of F in this picture.

About policy:

You've committed to that code, there's no changing it now. There's no amending, no history overwriting. You'll have to live with it.

If the change to be made is critical, you would've gotten it done by now. If not, but something like a pet peeve, it now depends on what your commit policy is. Does you(r organization, team, etc. as a collective decision) want an entire commit sitting there just to correct a typo?

Most teams are fine with that. Nobody's going to be hurt or annoyed enough to bring it up. If it's likely that someone else is going to work on that area of the codebase and will come across that typo and will be annoyed, by all means fix it - no two ways about it.

If not, and it's mostly isolated, then what I'd do in your situation is to put that change on a branch somewhere, perhaps in your stash. When you next have to work with that codebase again, you can add this typo change to it as well.

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.