Merge or Rebase

Git Merge

Using git merge from a feature branch will allow you to have those changes become present inside of the main branch. While this method is simple, it does cause a merge commit to be created and can have negative side-effects when working on a team. Generally speaking, it is not advised to use git merge when working with a public branch. Merging is a non-destructive way to merge two branches together and the existing branches won't be changed. But as mentioned earlier, this will lead to congestion in the git log on an active main (public) branch with many other users.

Git Rebase

Using git rebase first and foremost, should not be used on a public branch. Commits on the public branch that is rebased into your repo will have those commits put on top of your commits and continue from there. If you have a team working off of the main (public) branch and rebased it, there would be no way to track other upstream commits that are being made. Additionally, interactive rebasing allows for changes to the incoming changes to be made prior to the rebase taking effect.

git checkout feature
git rebase -i main

This will let you reorder the commits or condense a commit by using fixup on an item from the list. In order to rebase from a commit on the list:

git checkout feature git rebase -i HEAD~<id>

This will rebase from the specified commit id. If re-writing the entire feature branch is what you're looking for then the merge-base command will be the go-to.

git merge-base feature main

These methods of re-writing the commit history again should only be done within non-public branch that only you are working on, otherwise things will get a bit confusing with the other developers working on the same branch as you.