Universal way
One of the common way to solve such problem is to have two versions of the script - one to run, another to store in repository. It works for any version control system, and even if the script is downloaded from the web.
For example, you can have update.sh.in
(add it to repository):
#!/bin/bash
git pull
if [ update.sh.in -nt update.sh ]; then cp update.sh.in update.sh; fi
# actual work of the script
# any line here can be changed in the next version of the script
Manually copy that file into update.sh
, include it into .gitignore
. Run the update.sh
.
The trick here is that the first three lines should not be modified. As long as the copy of .sh.in
into .sh
remain in the same position of the script - it can be run without a problem.
The .in
extension is a traditional extension for various tools which generate actual script or source code from template files.
GIT hooks
Another, also common, but maybe less so, way: is to use git hooks. That is a GIT-specific approach. You can write additional scripts and put them inside .git/hooks
directory. Git will call these scripts in various points of execution.
You did not specify what exactly do you need to do beside git pull
. But probably, you can put your special work into .git/hooks/pre-rebase
or .git/hook/post-merge
. which are called automatically for git pull
.
For full list of hooks read here: https://git-scm.com/docs/githooks