How Do I Make the Same Changes to All Branches at Once?


I’d like to know if there is a way to update all files in all branches at once?

In other words, let’s say that I have seven release branches, and each branch has one more file than the previous. For example, Release A has one file, Release B has two files, Release C has three files, etc… The new file is always the different one; Releases A and B share one file in common, Releases A, B, and C share two files in common, etc…

Is there a way for me to, for example, update a particular sentence in every file across all branches without manually making the change to every single one? This would add up to about 40 manual changes, all of which are the same.

This is even more relevant if I have to make several manual changes to each file in each branch.

Is it a good solution to merge one branch into another branch (which is not Master)? It doesn’t seem so. In other words, I created a branch (call it Pizza, for the sake of the argument) in the most current release (say June 2021) for changing one aspect of my documentation. Would it make sense to merge the Pizza branch into January 2021, November 2020, and August 2020 for example? Or is there a better way that GitHub already thought of?

Thank you…

Whether merging makes sense depends on what other changes the merge might bring along. If you have old release branches I assume you might not want to merge all the other changes that happened in your development since. If the Pizza branch in your example starts from the last common ancestor it might work, or it might give you trouble with conflicts, depending on your files.

git cherry-pick might sort of be what you’re looking for, it lets you apply the changes from an existing commit to another branch. Note that (because of different parent commits and committer) this creates a new commit, so if you merge the branches later you’ll end up with duplicates. Cherry-picking the same commit over a few dozen branches should just take a little scripting. Note that conflicts might still occur, if there have been incompatible changes on some branches.

Definitely this is the type of task that you can automate via some custom script. From the description of your release strategy, it seems you’re dealing with a repository that has a consistent workflow, which is good when it comes to automated solutions.

In terms of Git operations, there’s definitely no way to achieve this via a single command, but a script could handle the sequence of required commands for you.

Just be aware that automated solution can lead to unexpected results, and problems — e.g. if the automated operations fail in the middle, leaving you with a half-done job, which you’d then have to fix manually.

There are multiple ways to achieve this, but no matter which path you take, you’ll be rewriting the repository history, and altering the commits hashes, which will entail ensuring that the various branches are still synchronized correctly. So you’re most likely going to need to rebase branches after you change the history of their ancestor branches. So you’ll have also to consider how this is going to affect the public repository and its users — re-writing the history of published branches and force pushing them is usually a bad idea, especially if you have contributors to your repository who might be working in their own dev branches.

I see, so it may be a good idea to pull my sleeves up and do it manually.

Is there a way to copy an entire branch so that I can just add the new file to it at every release? I tried to find how to do this online and wasn’t successful. If I can do it on the Remote Repo that would be better, as I’m much more comfortable with that than working in the CLI.

Thank you.

What do you mean by “copy an entire branch”? You can always create a second branch that points at the same commit, but from the rest of your post I’m not sure that’s what you’re after.

Like @airtower-luna mentioned, branching is the solution you’re looking for — i.e. creating a new branch from the branch you want to copy.

Once you’ve done that, and you’re checked into the copy branch, you can simply use git checkout to bring into your work area the file(s) you want to add, by either using git checkout <branch-name> -- <files> or using a commit reference instead of a branch, if that works best in your context.

The git checkout command can also be used to extract files (or files matching a pattern) from specific branches or commits, which is an easy way to pick selected files instead of whole commits.

Then you can either add the new file to the copy branch as a new commit, or amend the last commit instead.

Instead of rewriting the history of published branches, you might consider offering some extra branches which are intended to be force-pushed (i.e. end users are aware of this and don’t rely on them for applying their changes). Like spare copies of the official Release Branches, but with all their files always updated in each release (i.e. changes being applied backward too).

If I’ve understood correctly, that was your original goal. I just suggest not doing these kind of operations in the actual release branches, but on some dedicated copies which can easily be identified by some naming convention. In this case, you could automate the process via scripts, and if something goes wrong they are only copies, so you don’t loose anything.