I believe you're over-thinking this. Don't worry about the fact that you only need one file updated; just update everything. If you had waited a little longer before creating the branch you would have started with the updated everything anyway. So, what you have described is pretty much the same thing nearly all teams deal with daily, mainly:
- There exists a branch that came off of
development. - Some new commits appear on
development. - I want those already created branches to be updated with the latest
development.
The answer boils down to simply updating the branches. There are multiple ways to do this, but the most popular are:
# Update via rebase
git fetch
git switch unique-customization-test-branch
git rebase origin/development
git push --force-with-lease # I assume you want to push here?
# Update via merge
git fetch
git switch unique-customization-test-branch
git merge origin/development
git push # I assume you want to push here?
I usually prefer rebase over merge for my own branches, but in your case it will likely depend on what you are doing with the already pushed test branches. If they are used elsewhere in the system, I'd probably just use merge so you don't have to force push. (With rebase the resulting history is "cleaner" but you have to force push previously pushed branches, whereas with merge you can just do a regular push.) If you're willing to force push though, it opens the door of another option:
git fetch
git switch unique-customization-test-branch
git reset --hard origin/development # your branch looks like you just created it
# Now repeat the rest of your script starting with "magic code stuffs"
# If you do this, your push step would have to change to force push
Note you could consider updating your test runners to do any of the 3 options automatically.
Side Note: you may have noticed that I used remote tracking branches instead of local branches (e.g. origin/development instead of development). This is simply more efficient so you don't have to check out local copies of shared branches. I'd suggest you do this in your initial creation of branches as well, for example your first 3 steps could be:
git fetch
git switch -c unique-customization-test-branch origin/development --no-track
I also use "switch" which is the newer syntax for this usage of "checkout". In this case git switch -c is synonymous with git checkout -b.
BTW, your usage of both meanings of checkout in the question highlights the reason the new Git commands of switch and restore were created to replace the command checkout. The equivalent new usage of your command:
git checkout origin/development -- FooBar.groovy
would be
git restore --source origin/development FooBar.groovy
or more concise:
git restore -s origin/development FooBar.groovy