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:

 1. There exists a branch that came off of `development`.
 2. Some new commits appear on `development`.
 3. 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
```

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`