I recently inherited some PHP code that was a mess. It had harcoded paths and URLs all over the place, which I had to change every time I move the code from my test server to the production server. I ended up creating a new "production" branch separated from the "master" one, where I changed all the hardcoded paths and URLS to the ones used in the production server. In other words:
A - B - C
\
\-D - E
C is the master branch where I work. In it, the URLs and paths correspond to my test server. I created a new "production" branch (D and E), where I changed the paths to the production server.
Now I have added some new features to the master branch:
A - B - C - F - G - H
\
\-D - E
And I want to apply those D and E commits where I changed the paths and URLs to the latest changes, to H.
From what I read, rebase seems like the exact feature for this, but:
The docs I read suggest that it's a bad idea to rebase branches that have already been pushed to the remote server, which is exactly what I've done.
In my case, the "production" branch has two commits (because there were so many paths to change that I forgot some of them at first), so I don't know exactly if I can take all of them and rebase them entirely.
I am using Sourcetree on Windows and Mac, although I can handle the command line too.
Use git rebase in this case. There could be chances that some code conflicts can occur, but those can be solved manually, provided the conflicting files are textual files - code files, json files, etc.
Used it plenty of times, and if used rightly, no issues occur and the child branches can be then merged easily into main branch.
As a rule-of-thumb for me, I squash commits on the child branch into one commit using git rebase -i HEAD~<no.of.commits.to.be.squashed>, so then if any rebase conflicts occur, I can resolve them for one commit only.