I created this bash script to make it easy to publish your files to a GitHub repository.


echo "Welcome to the GitHub File Publishing Tool (GHFP for short)"
read -p "Continue? " yn

case $yn in
[Yy]* ) echo "Continuing the program...";;
[Nn]* ) echo "Stopping the program"; exit;;

echo "Your remote will be shown below."

git remote

read -p "What is the remote of your repository? See above for the remote. " REMOTE

echo "Your main branch will be shown below."

git remote show $REMOTE | sed -n '/HEAD branch/s/.*: //p'

read -p "What branch would you like to write changes to? For example, enter master for main/default branch. " BRANCH

echo "The number of commits for branch" $BRANCH "will show below."

git rev-list --count $BRANCH

git add .

read -r -p "Commit name/number/identifier: " NUM

git commit -m $NUM

git push

Can anyone provide some ideas for improvement?

Below is the output of the file (running for a repository with no new changes)

bash gitpush.sh
Welcome to the GitHub File Publishing Tool (GHFP for short)
Continue? y
Continuing the program...
Your remote will be shown below.
What is the remote of your repository? See above for the remote. upstream
Your main branch will be shown below.
What branch would you like to write changes to? For example, enter master for main/default branch. master
The number of commits for branch master will show below.
Commit name/number/identifier: 19
On branch master
Your branch is up to date with 'upstream/master'.

nothing to commit, working tree clean
Everything up-to-date

4 Answers 4


Rather than make it interactive

read -p "Continue? " yn

I would make this more like other command line tools. You have default values and allow specialization via flags (or error out if required parameters are not provided).

The point of scripts is to automate an action. If your script is interactive then it does not help in automation.

Now you can have a script that collects information interactively. But then calls you script proving all the parameters.

Checking for errors in your commands is also a good idea. So that you can exit out. Couple of ways to do that:

// Change the first line to this.
// Forces the script to exit if there are any errors.
#!/bin/bash -e


// Use the "||" which executes the second  command if the
// first command does not succeed.
git remote || echo "Fail";exit 1

In response to comment:Do you know how to set a default variable?

The simplest technique would be to set a variable with a default value. Then if a flag exists you overwrite the value.

if [[ "$1" = "-b" ]] then
  • \$\begingroup\$ You are saying that, in order to make it automatic, one would have to not include user prompts, correct? \$\endgroup\$
    – Logan
    Jun 24, 2022 at 19:56
  • 4
    \$\begingroup\$ You could have an option to ask for user input. But by default you should provide all the parameters on the command line to the script. \$\endgroup\$ Jun 24, 2022 at 20:10
  • \$\begingroup\$ Also, I have not really done a whole lot with bash scripts... Do you know how to set a default variable? \$\endgroup\$
    – Logan
    Jun 24, 2022 at 20:19
  • \$\begingroup\$ Depending on common invocation patterns, #!/bin/bash -e might not be a good idea if you want to (to some extent) enforce the -e flag, as it's just bypassed if the script is invoked with bash ./script.sh. Use set -e on the following line may be better. \$\endgroup\$
    – iBug
    Jun 25, 2022 at 15:04

If you're going to keep your script interactive, I'd reorder these lines:

git add .

read -r -p "Commit name/number/identifier: " NUM


read -r -p "Commit name/number/identifier: " NUM

git add .

This way the user can Ctrl-C without having their index modified for no reason. The idea is to make changes all at once; the same principle applies to file io, for example, where you can avoid data corruption by outputting everything in one shot instead of dragging it out over multiple prompts and having more opportunities for something to go wrong.


Do you really expect the user to type in REMOTE and BRANCH, copying the output of the previous commands? What if the user makes a typo? Why bothering the user at all?

Instead of

git remote

read -p "What is the remote of your repository? See above for the remote. " REMOTE

just do a REMOTE=$(git remote)

and, in the same way,

BRANCH=$(git remote show $REMOTE | sed -n '/HEAD branch/s/.*: //p')

basically, put the command that produces the output into $( ), and assign it to the variable.

The prompt for the branch name is confusing anyway; it asks for the "branch to write changes to". However, entering a different branch from the current one won't work, as that would need something like git checkout -b <branch> which you don't do; so there's really not a point in asking at all.

And on a side note, which has little to do with shell programming, you shouldn't blindly do a git add . as that will clutter your repository with everything that happens to be in your workspace, needed or not. If you really don't want users to think about what to commit and what not, do a git add -u, as this will add everything that has changed, but files that weren't in the repo before won't be added by that.

  • \$\begingroup\$ Or just use git commit -a as that does git add -u automatically. \$\endgroup\$
    – Neil
    Jun 26, 2022 at 20:17

Add a default in your case, take into account that the user could press any key besides y an n.
schrodingerscatcuriosity, CC BY-SA 4.0, 2022-06-24 22:18:07

  • 2
    \$\begingroup\$ If you are the OP and want to get reputation for your insight feel free to post a new answer. Then please notify a moderator to delete this answer by flagging this answer. \$\endgroup\$
    – Peilonrayz
    Jun 25, 2022 at 14:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.