Git Push Bash script

Question

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

#!/bin/bash
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;;
esac
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.
upstream
What is the remote of your repository? See above for the remote. upstream
Your main branch will be shown below.
master
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.
18
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

Answer 1

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

Or

// 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.

branch=master
if [[ "1ドル" = "-b" ]] then
 branch=2ドル
fi

• Logan: You are saying that, in order to make it automatic, one would have to not include user prompts, correct?
• Loki Astari: 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.
• Logan: Also, I have not really done a whole lot with bash scripts... Do you know how to set a default variable?
• iBug: 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.

Answer 2

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

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

to

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.

Answer 3

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.

• Neil: Or just use git commit -a as that does git add -u automatically.

Answer 4

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

• Peilonrayz: 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.