Essential Git Commands to Use on Your Linux VPS

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

Use Git on a Linux VPS as a controlled deployment tool, not as a text editor. Before changing anything, verify the directory, branch, working-tree state, and remote. Fetch remote history before deciding whether to fast-forward, merge, or rebase; review staged changes before every commit; and record the exact commit that is running in production.

Start with a safe VPS checkout

Run Git as a dedicated, unprivileged deployment account that owns the application checkout. Avoid using root for routine repository operations: root-owned files can prevent the service account from updating releases, and a mistaken command can affect unrelated parts of the server. Keep production-only configuration and secrets outside the repository, preferably in environment files or a secret manager that is excluded by .gitignore.

#	Preview	Product	Price
1		Pro Git		Buy on Amazon
2		Pro Git (Expert's Voice in Software Development)	$37.07	Buy on Amazon
3		Professional Git	$24.79	Buy on Amazon
4		Pro Git 1st (first) edition Text Only	$83.26	Buy on Amazon
5		Git: Github Programming, In 8 Hours, For Beginners, Learn Coding Fast: Git Github Language, Crash...	$2.99	Buy on Amazon

From the shell, establish exactly where you are and what Git believes about the checkout:

pwd
git status --short --branch
git branch --show-current
git remote -v

• pwd confirms the absolute directory. A surprising path is a reason to stop before running a pull or reset.
• git status --short --branch shows the current branch and any staged, unstaged, or untracked files.
• git branch --show-current confirms the branch that a deployment process is expected to use.
• git remote -v verifies the fetch and push URLs. Check the repository and host, not just the remote name.

Do not overwrite local changes you do not understand. A clean status is easiest to reason about, but a deliberately retained configuration file can be acceptable when your deployment design documents it.

#1 Best Overall

Sale

Pro Git

Buy on Amazon

Clone a repository or correct its remote

Clone into the application path

For a new checkout, clone the repository directly into the directory used by the deployment process:

git clone git@github.com:ORG/REPO.git /srv/app
cd /srv/app

The conventional remote name is origin. If a repository already exists without a remote, add one; if the URL is wrong, replace it:

git remote add origin git@github.com:ORG/REPO.git
git remote set-url origin git@github.com:ORG/REPO.git

GitHub documents both HTTPS and SSH remote forms and describes SSH as a secure way to deploy code to production servers. SSH requires a key pair and repository permissions. Use a deploy key or service identity with the narrowest practical access, and verify that the server account can authenticate before scheduling unattended deployments.

Choose SSH or HTTPS deliberately

Check the remote immediately before a release. A correctly named origin can still point to the wrong repository or fork.

Inspect branches and recent history before integrating

List local and remote-tracking branches, move to the branch expected by the application, and inspect recent commits:

Rank #2

Sale

Pro Git (Expert's Voice in Software Development)

$37.07

Buy on Amazon

git branch -a
git switch main
git switch -c feature/name
git log --oneline --decorate --graph -n 20
git show --stat --oneline HEAD

git switch main changes to an existing local branch. git switch -c feature/name creates and checks out a new branch. Keep the production checkout on the branch your release procedure specifies; do not deploy a feature branch simply because it happens to be checked out.

The graph view helps reveal whether a branch is ahead, behind, or diverged. git show --stat --oneline HEAD gives a compact view of the commit currently checked out, useful before and after a release.

Stage and commit only the change you intend to publish

Separate inspection, staging, and recording into explicit steps:

git diff
git add path/to/file
git diff --cached
git commit -m "Describe the change"

1. Use git diff to inspect unstaged edits.
2. Use git add path/to/file for selected paths rather than staging unrelated work accidentally.
3. Use git diff --cached to review the exact snapshot that the next commit will contain.
4. Commit with a message that identifies the change and its purpose.

GitHub’s Git overview describes staged files as becoming part of the snapshot created by a commit. On a VPS, the staged-diff review is also a secrets check: look for tokens, private keys, database dumps, and local configuration before committing. If a file should never be tracked, remove it from the snapshot and add an appropriate ignore rule before continuing.

Fetch first, then choose how to update the VPS

What git fetch changes

git fetch downloads new objects and updates remote-tracking references without merging them into the checked-out branch or changing its files:

Rank #3

Sale

Professional Git

$24.79

Buy on Amazon

git fetch origin
git log --oneline HEAD..origin/main
git diff HEAD...origin/main

The log lists commits reachable from origin/main but not from the current HEAD. The three-dot diff compares the branch tips through their common ancestor, making it useful for reviewing what an update would introduce. This inspection step is safer than immediately pulling production code.

What git pull does

A pull normally fetches and then integrates the selected remote branch. Make the integration policy explicit:

git pull --ff-only origin main
# or, when the project policy allows a merge:
git pull --no-rebase origin main
# or, when the project policy requires rebasing:
git pull --rebase origin main

Git supports persistent settings such as pull.rebase=false for merge behavior and pull.rebase=true for rebase behavior. Configure a policy deliberately rather than depending on an implicit default, and make sure the setting matches the team’s documented release process.

Pull the latest code with a production-safe procedure

1. Change to the application directory and run git status --short --branch.
2. Confirm the expected branch with git branch --show-current.
3. Verify the remote with git remote -v.
4. If the working tree contains unexplained edits, stop and investigate rather than hiding them with a reset.
5. Run git fetch origin and review git log --oneline HEAD..origin/main and git diff HEAD...origin/main.
6. Use git pull --ff-only origin main when a fast-forward-only release is required. Choose an explicit merge or rebase command only when that is the project policy.
7. Run the application’s documented tests, migrations, build, and service restart steps after Git has updated the files. Git itself does not verify that the application is healthy.
8. Record the deployed revision:

git rev-parse --short HEAD

Keep that short commit ID in the release log or deployment output so an operator can identify exactly what is running.

Push branches and establish upstream tracking

For a new local branch, set its upstream on the first push:

Rank #4

Pro Git 1st (first) edition Text Only

$83.26

Buy on Amazon

git push -u origin main
git push
git push origin feature/name

git push -u origin main associates the local main branch with origin/main. Later, argument-less git push can use that upstream. The explicit git push origin feature/name form publishes a named branch without changing which branch is checked out.

On a production VPS, pushes are usually less common than fetch-and-deploy operations. If the server must push tags or emergency fixes, ensure the deployment identity has only the permissions it needs and that the destination branch is protected by the team’s review rules.

Fix a non-fast-forward push rejection

A non-fast-forward rejection means the remote branch contains commits that the local branch does not. Do not immediately force-push a shared production branch. First fetch and compare both sides:

git fetch origin
git log --oneline --left-right HEAD...origin/main
git rebase origin/main   # or merge, according to project policy
# resolve conflicts, then:
git add <resolved-files>
git rebase --continue    # if rebasing
git push

The left-right log marks commits unique to each side, which helps you understand what would be integrated. During a rebase, resolve each conflict, stage the resolved files, and continue. If the project uses a merge policy, merge the remote branch instead and complete the merge commit according to its review requirements.

Force-pushing can discard commits and disrupt other operators. Treat it as an exceptional, explicitly reviewed action on a branch where rewriting history is permitted; never use it as the routine response to a production rejection.

Best Value

Git: Github Programming, In 8 Hours, For Beginners, Learn Coding Fast: Git Github Language, Crash Course Textbook & Exercises (Textbooks in 8 Hours 3)

$2.99

Buy on Amazon

Tag releases and remove obsolete remote branches carefully

Annotated tags make release points easier to identify:

git tag -a v1.2.0 -m "Release v1.2.0"
git push origin v1.2.0
git push origin --tags

The first push publishes one tag; --tags publishes all local tags that are not already on the remote. Decide which form your release policy permits before running it, because the latter may publish more than the release you just created.

GitHub documents the colon syntax for deleting a remote branch:

git push origin :old-branch

Branch deletion and release tagging are controlled operations. Confirm the exact name, check whether another deployment or pull request still depends on it, and preserve release artifacts or references needed for rollback.

Recover from mistakes without guessing

Inspect before discarding

git diff
git diff --cached
git reflog
git clean -nd

• git diff shows edits not staged.
• git diff --cached shows staged edits.
• git reflog records previous positions of HEAD, often allowing you to locate a commit after a mistaken reset, checkout, or rebase.
• git clean -nd performs a dry run that lists untracked files and directories that a clean operation would remove.

Discard deliberately

git restore path/to/file
git reset --hard HEAD

git restore path/to/file discards unstaged edits in the specified path. git reset --hard HEAD discards all local tracked edits in the checkout and is destructive; it does not preserve a convenient undo for work you meant to keep. Review status and diffs first, and retain backups or deployment artifacts when the checkout contains production-only configuration.

Use a deployment design that stays repeatable

Manual edits in a live checkout followed by an unreviewed pull create an ambiguous state: Git can no longer tell which files came from the repository and which were changed on the server. Prefer a bare repository with a deployment hook, or a pull-based deployment script that performs the same checks every time. A script can enforce the account, directory, branch, clean-tree requirement, fetch policy, tests, service restart, and commit logging in one reviewed procedure.

Quick Recap

SaleBestseller No. 1

Pro Git

SaleBestseller No. 2

Pro Git (Expert's Voice in Software Development)

$37.07

SaleBestseller No. 3

Professional Git

$24.79

Bestseller No. 4

Pro Git 1st (first) edition Text Only

$83.26

Bestseller No. 5

Git: Github Programming, In 8 Hours, For Beginners, Learn Coding Fast: Git Github Language, Crash Course Textbook & Exercises (Textbooks in 8 Hours 3)

$2.99

• Keep secrets out of commits and inspect git diff --cached before every commit.
• Use filesystem ownership that lets the deployment account update the checkout without elevated privileges.
• Verify the remote URL and branch immediately before deployment.
• Use git fetch to inspect incoming history, then select fast-forward-only, merge, or rebase behavior explicitly.
• Make rollback possible by retaining release artifacts or a known-good commit reference.
• Record git rev-parse --short HEAD for every deployment.

Linux VPS Git command quick reference

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.