Rebase
Your feature branch holds three commits, and main has moved ahead since you branched off it. You want your three sitting on top of today's main, carrying the same file changes on fresh footing.
- ▸A commit rebuilt on a new parent is a new object with a new hash, never the original moved.
- ▸Rebuilding three commits writes three new objects and leaves the three originals in
.git/objects/, reachable until garbage collection. - ▸Force-pushing a rebuilt branch strands any teammate who branched off an original commit, which is why shared history is frozen.
Your feature branch holds three commits of work, and main has moved ahead of where you started. You want your three sitting on top of the new main, the same changes, with the latest code underneath. It sounds like picking the commits up and setting them down farther along the line.
Start with just one of them: the commit that adds a line to config.json. Its change is a fixed thing. The commit records more than the change, though: a parent, and a tree that is the full snapshot of every file. Set it on a new base and both lines change, the parent because the base is new, and the tree because the new base's files are in the snapshot too. New bytes, new SHA-1, new object at a new path under .git/objects/. The original commit still exists, with its old parent and its old name; what you get on the new base is a second commit that happens to carry the same change.
So nothing is picked up and moved. A commit can only be rebuilt: its diff re-applied on top of a different parent, producing a fresh object. One diff, set on two different bases, is two commits with two names. The whole of what follows is that one fact scaled up, from a single commit to a line of them, and from one new parent to a new base for all of them.