I am developing an automation script for Jenkins jobs. The script takes a parameter $1, makes a small change to a repository file and push the change. It simply does:
git clone repo
echo > $1
git commit -a -m 'updated'
git push
When those Jenkins jobs execute at once, git push fails very often with:
! [rejected] master -> master (non-fast-forward)
Which is totally understandable. But I would like to force the push to happen, because it is already guaranteed that each script invocation gets a different $1.
From the manual page, I have learned that:
--force
... This flag disables these checks,
and can cause the remote repository to lose commits;
use it with care.
Would the flag be appropriate for my scenario?
You should not use --force, if you cannot afford losing the other commits and subsequently the other files!
Instead use a pull to pull in the changes of the other processes and push afterwards:
git pull origin master && git push origin master
In case you want to have your repository clean of merge commits consider using pull --rebase:
git pull --rebase origin master && git push origin master
Note that there is a slight window between the pull and the push where again commits could slip in, consider repeating the command as necessary if it does not go through. But keep in mind that this could cause a hang.