Git commands, with examples

git config --global user.name "Your Name"

Records the name and email address that Git attaches to every commit you make.

Set both values once per computer before your first commit, otherwise Git either guesses from your system account or stops and asks you to set them. Use the same email as your hosting account if you want commits linked to your profile there. Leaving out --global stores the value for the current repository only, which is a simple way to keep work and personal identities separate.

git config --global user.name "Ada Lovelace"

git config --global user.email "ada@example.com"

git config user.email "ada@work.example.com"

git config user.name

--global

Write to your personal config file, which applies to all your repositories.

--local

Write to this repository's .git/config file; this is already the default when setting a value.

git config --global init.defaultBranch main

Chooses the name of the first branch in repositories you create from now on.

Without this setting the starting branch name depends on your Git version, with older releases using master, so setting it explicitly keeps new repositories consistent across machines. It has no effect on repositories that already exist. The setting has been available since Git 2.28.

git config --global init.defaultBranch main

git config --global --get init.defaultBranch

git config --list --show-origin

git init

Turns the current folder into a new, empty Git repository.

It creates a hidden .git folder that will hold all history and settings, while your existing files stay where they are and remain untracked until you add and commit them. Running it again inside an existing repository is harmless and does not erase anything.

git init

git init my-project

git init -b main

-b <name>

Pick the name of the initial branch for this repository.

--bare

Create a repository with no working files, typically used as a central copy that others push to.

git clone <url>

Downloads a complete copy of an existing repository, history included, into a new folder.

Cloning also sets up a remote named origin that points back at the source and checks out its default branch, so you can start working straight away. A shallow clone made with --depth is faster for large projects, but log, blame, and similar commands can only see the commits you actually downloaded.

git clone https://github.com/example/project.git

git clone https://github.com/example/project.git my-copy

git clone --depth 1 https://github.com/example/project.git

git clone -b develop https://github.com/example/project.git

--depth <n>

Fetch only the most recent n commits.

-b <branch>

Check out this branch once the clone finishes.

--recurse-submodules

Also clone and check out any submodules the project depends on.

git status

Reports which files are modified, staged, or untracked, and which branch you are on.

It changes nothing, so it is safe to run before and after any other command to confirm what happened. In the middle of a merge, rebase, or cherry-pick it also explains the current state and how to continue or back out.

git status

git status -s

git status -sb

-s

Short output where the left column is the staged state and the right column is the working copy.

-b

Include branch and tracking details, mainly useful alongside -s.

--ignored

Also list files that .gitignore is hiding.

git add <path>

Stages changes so that they will be part of the next commit.

Staging copies a file's content as it is right now, so if you edit the file again afterwards, those newer edits stay unstaged until you add it again. Adding a folder stages everything inside it, including new and deleted files.

git add index.html

git add src/

git add .

git add -A

-A

Stage new, modified, and deleted files across the entire working tree.

-u

Stage changes and deletions to files Git already tracks, but skip new files.

-n

Dry run that lists what would be staged without staging it.

git add -p

Steps through your changes chunk by chunk so you can stage only some of them.

Reach for it when one file holds two unrelated edits that belong in separate commits. At each prompt, y stages the chunk, n skips it, s splits it into smaller pieces, e lets you edit the lines by hand, q stops, and ? lists every choice. Brand-new files are not offered until Git knows about them, which you can arrange with git add -N first.

git add -p

git add -p src/app.ts

git add -N notes.md

git diff

Shows the line-by-line edits in your working files that are not staged yet.

Plain git diff compares your files with the staging area, so a change drops out of this output as soon as you stage it, which can look as though it vanished. Use git diff --staged to see staged changes, or git diff HEAD to see staged and unstaged together.

git diff

git diff README.md

git diff HEAD

git diff main..feature

--stat

Summarise as a list of files with counts of changed lines.

--name-only

List just the names of the changed files.

-w

Ignore differences that are only whitespace.

--word-diff

Mark changed words inside a line instead of whole lines.

git diff --staged

Shows the changes you have staged, which is exactly what your next commit will contain.

Run it right before committing to confirm nothing unexpected is included. The option --cached means the same thing and appears in older guides.

git diff --staged

git diff --staged --stat

git diff --cached src/app.ts

git commit -m "message"

Saves the staged changes as a new commit, labelled with a message describing them.

Only staged changes go in; anything you edited but did not add is left out. If you leave off -m, Git opens your editor so you can write a longer message, with a short summary on the first line and a blank line before any further explanation.

git commit -m "Fix broken link in footer"

git commit

git commit -am "Update pricing page copy"

-m <message>

Use this text as the message; repeating -m adds extra paragraphs.

-a

Stage changes to tracked files before committing; new files are not included.

-v

Show the diff in the editor while you write the message.

git commit --amend

Replaces your latest commit with a new one that includes any staged changes and, if you like, a new message.

Useful for fixing a typo in the last message or adding a file you forgot to stage. Although it feels like editing, Git actually builds a brand-new commit with a different ID and drops the old one from your branch.

Careful: Amending rewrites the last commit. If it has already been pushed, anyone who pulled it now has a commit your branch no longer contains, and publishing the fix requires a force push. Only amend commits that exist solely on your machine.

git commit --amend -m "Fix broken link in footer"

git commit --amend --no-edit

--no-edit

Keep the existing commit message unchanged.

--reset-author

Record yourself as the author and refresh the timestamp.

git restore <file>

Discards uncommitted edits to a file and puts back its last staged or committed version.

Git 2.23 introduced restore so that recovering files and switching branches would no longer share one command; it replaces git checkout -- <file>. With --source you can bring back a file's content from any commit without moving your branch.

Careful: Edits that were never staged or committed exist only in your file, so once restore overwrites them Git has no copy to bring back.

git restore src/app.ts

git restore .

git restore --source=HEAD~2 src/app.ts

git restore -p src/app.ts

--source=<commit>

Take the content from this commit instead of the staging area.

--staged

Unstage the file rather than touching your working copy (see the Undo section).

-p

Pick the chunks to restore one at a time.

git rm <file>

Deletes a file from your working folder and stages the deletion.

It does the same as deleting the file yourself and then staging that change, and it refuses to remove a file that has uncommitted modifications. With --cached, Git stops tracking the file but leaves it on disk, which suits an accidentally committed .env file; add it to .gitignore too, and remember it still exists in earlier commits.

git rm old-script.js

git rm --cached .env

git rm -r build/

--cached

Remove the file from the staging area only.

-r

Allow removing folders and everything inside them.

-n

List what would be removed without removing it.

git mv <old> <new>

Renames or moves a tracked file and stages that change in one step.

Git does not store renames directly; it works them out later by comparing file contents, so moving a file some other way and staging both sides ends up the same. It is also the straightforward way to change only the capitalisation of a filename on case-insensitive file systems such as the Windows and macOS defaults.

git mv utils.js helpers.js

git mv helpers.js src/lib/

git mv readme.md README.md

-n

Show what would be moved without moving anything.

git branch

Lists your local branches and marks the one you currently have checked out.

Add -a to include remote-tracking branches, which reflect the remote as of your last fetch rather than its live state. The same command renames branches with -m.

git branch

git branch -a

git branch -vv

git branch --merged main

-a

Include remote-tracking branches.

-vv

Add the last commit, upstream branch, and ahead/behind counts.

-m <old> <new>

Rename a branch.

--merged / --no-merged

Show only branches that are, or are not, merged into the given commit.

git branch <name>

Creates a new branch at the current commit without switching to it.

You remain on your current branch afterwards, which is easy to forget if you commit straight away. To create a branch and move onto it together, use git switch -c instead. Naming a commit, tag, or branch after the new name starts the branch from there.

git branch feature/login

git branch hotfix v1.2.0

git branch experiment a1b2c3d

git branch -d <name>

Deletes a local branch, but only when its work is already merged.

Git checks that the branch is merged into its upstream, or into your current branch if it has no upstream, and refuses otherwise, which protects commits that exist nowhere else. It never touches the copy of the branch on a remote, and you cannot delete the branch you are currently on.

git branch -d feature/login

git branch -d feature/login feature/signup

git branch -D <name>

Deletes a local branch even when its commits are not merged anywhere.

It is shorthand for --delete --force and skips the merge check that -d performs. Use it for abandoned experiments you are certain you no longer need.

Careful: Commits that lived only on that branch stop being reachable from any branch. If you had them checked out recently, git reflog can usually help you find and restore them, but they vanish from normal history and are eventually cleaned up for good.

git branch -D spike/old-idea

git switch <branch>

Moves you onto another existing branch and updates your files to match it.

Uncommitted changes come along when they do not clash with the target branch; if they would be overwritten, Git refuses, so commit or stash first. When a branch exists only on the remote, switching to its name creates a local branch that tracks it, as long as exactly one remote has a branch by that name.

git switch main

git switch -

git switch --detach v1.0.0

-c <new-branch>

Create the branch first, then switch to it.

--detach

Check out a commit or tag directly instead of a branch.

git switch -c <new-branch>

Creates a new branch and switches to it in a single step.

The branch starts at your current commit unless you give a different starting point. Uncommitted changes move across with you, which helps when you realise halfway through an edit that the work deserves its own branch. The older equivalent is git checkout -b.

git switch -c feature/search

git switch -c hotfix origin/main

git checkout <branch>

Switches branches or restores files, handling both jobs that newer Git splits between switch and restore.

Because one command covered unrelated tasks, Git 2.23 added git switch for branches and git restore for files; checkout still works and is common in older tutorials and scripts. Given a commit ID it puts you in detached HEAD mode, where new commits belong to no branch until you create one.

Careful: When you pass a file path, as in git checkout -- file, it overwrites your uncommitted edits to that file without asking, and those edits cannot be recovered.

git checkout main

git checkout -b feature/search

git checkout -- src/app.ts

git checkout a1b2c3d

git merge <branch>

Brings the commits from another branch into the branch you are on.

If your branch has not moved since the other one split off, Git just slides your branch forward (a fast-forward); otherwise it creates a merge commit with two parents. When both sides changed the same lines it stops with conflicts, which you fix, stage, and finish with git commit or git merge --continue.

git merge feature/search

git merge --no-ff feature/search

git merge --abort

--no-ff

Record a merge commit even if a fast-forward would work.

--ff-only

Refuse to merge unless it can be a fast-forward.

--squash

Stage the combined changes without creating a merge commit, leaving you to commit them as one.

--abort

Cancel a merge that stopped because of conflicts.

git rebase <base>

Replays your branch's commits on top of another commit so that history forms a straight line.

Reach for it to bring a feature branch up to date with main without adding a merge commit. Every replayed commit receives a new ID. The interactive form, git rebase -i, lets you reorder, reword, squash, or drop commits along the way.

Careful: Rebasing replaces commits with rewritten copies. Do not rebase commits other people have already pulled, such as a shared main or a branch teammates are building on, because their history will no longer match yours and they will have to untangle duplicate commits. Keep it to commits only you have, or agree on it with your team before force-pushing.

git rebase main

git rebase -i HEAD~3

git rebase --continue

git rebase --abort

-i

Open a to-do list in your editor to pick, reword, squash, fixup, or drop each commit.

--onto <newbase>

Move a range of commits onto a different base than the one they grew from.

--autosquash

Place commits made with git commit --fixup next to the commits they correct.

--skip

Leave out the commit that is causing a conflict and continue.

git cherry-pick <commit>

Copies the changes from one or more existing commits onto the current branch as new commits.

Handy for carrying a single bug fix over to a release branch without merging everything else. The copy gets its own ID and has no link to the original, so merging both branches later can still produce conflicts if the same lines changed again afterwards.

git cherry-pick a1b2c3d

git cherry-pick -x a1b2c3d

git cherry-pick a1b2c3d~1..e4f5a6b

git cherry-pick --abort

-x

Add a line to the message naming the commit it was copied from.

-n

Apply the changes to your files and staging area without committing.

--continue

Resume after resolving a conflict.

git remote -v

Lists the remotes this repository knows about, with the URLs used to fetch from and push to each.

A freshly cloned repository has a single remote named origin. Checking this list is the quickest way to see whether you are connecting over HTTPS or SSH, or to catch a mistyped URL when a push or fetch fails.

git remote -v

git remote show origin

git remote set-url origin git@github.com:example/project.git

git remote add <name> <url>

Registers a new remote under a short name so you can fetch from it or push to it.

You need it when a project began with git init and now has to be published, or when you forked a project and want to follow the original. Adding a remote only saves the name and address; nothing is downloaded until you fetch.

git remote add origin https://github.com/example/project.git

git remote add upstream https://github.com/original/project.git

git remote remove upstream

-f

Fetch from the new remote immediately after adding it.

git fetch

Downloads new commits, branches, and tags from a remote without changing your own branches or files.

Afterwards, remote-tracking branches such as origin/main show what the remote looks like, and you decide separately whether to merge or rebase. Since it leaves your branches and working files alone, you can run it whenever you like.

git fetch

git fetch --all

git fetch --prune

git log --oneline main..origin/main

--all

Fetch from all remotes.

--prune

Remove remote-tracking branches whose branch no longer exists on the remote.

--tags

Fetch every tag, not only those attached to fetched commits.

git pull

Fetches the upstream branch and then folds its new commits into your current branch.

It is a fetch followed by a merge, or by a rebase if you have configured that. When you and the remote both have new commits and you have not said which approach you prefer, recent Git versions stop and ask you to choose, either with a flag or by setting pull.rebase.

git pull

git pull origin main

git pull --ff-only

--rebase

Replay your local commits on top of the fetched ones instead of merging.

--ff-only

Only fast-forward; fail if the histories have diverged.

--no-rebase

Merge, even if pull.rebase is set.

git pull --rebase

Fetches remote changes and replays your unpushed local commits on top of them instead of creating a merge commit.

It keeps history in a straight line when you and someone else both committed to the same branch. Only your local commits that have not been pushed get rewritten, so it is safe in everyday use; if a conflict appears, resolve it, stage the file, and run git rebase --continue.

git pull --rebase

git config --global pull.rebase true

git pull --rebase --autostash

git push

Uploads commits from your current branch to its matching branch on the remote.

Git rejects the push if the remote has commits you do not have, so that nothing there is overwritten; pull or fetch and integrate, then push again. Without arguments it sends the current branch to its upstream, which you set once with -u.

git push

git push origin main

git push --dry-run

-u

Record the remote branch as this branch's upstream.

--tags

Also push all local tags.

--dry-run

Report what would happen without pushing anything.

git push -u origin <branch>

Publishes a new branch to the remote and remembers that remote branch as its upstream.

Once the upstream is set, plain git push and git pull on that branch know where to go, and git status can report whether you are ahead or behind. To skip this step for every new branch, set push.autoSetupRemote to true.

git push -u origin feature/search

git push -u origin HEAD

git config --global push.autoSetupRemote true

git push --force-with-lease

Overwrites the remote branch with your local version, but only if the remote still points where you last saw it.

After a rebase or amend on a branch you already pushed, a normal push is rejected and some form of forced push is needed. Plain --force replaces the remote branch no matter what is there, whereas --force-with-lease first checks that nobody has pushed since your last fetch and refuses if they have.

Careful: It still rewrites history on the remote, so anyone who pulled the old commits has to reconcile their copy. The check compares against your remote-tracking branch, so if a fetch (including an automatic one run by an editor) updated it without you looking at the new commits, the lease passes and those commits are overwritten anyway; adding --force-if-includes closes that gap. Avoid forced pushes to shared branches such as main.

git push --force-with-lease

git push --force-with-lease --force-if-includes

--force-if-includes

Only allow the forced push if the remote's latest commit has at some point been part of your local branch.

git log

Lists the commits reachable from your current branch, newest first.

The default view prints the full ID, author, date, and message of every commit, which gets long quickly; press q to leave the pager. Adding --oneline and --graph turns it into a compact picture of how branches split and merge, and filters narrow it down by author, date, or content.

git log --oneline --graph --all

git log -n 5

git log --author="Ada" --since="2 weeks ago"

git log -S "fetchUser" --oneline

--oneline

One line per commit: short ID and the message's first line.

--graph

Draw lines beside the commits showing branches and merges.

--all

Include every branch, remote-tracking branch, and tag, not just the current branch.

-n <number>

Show at most this many commits.

git log -p

Shows commit history together with the full set of changes each commit made.

Reading the actual edits next to each message helps when messages are vague. Pair it with -n or a file path to keep the output manageable, or use --stat for a lighter list of the files each commit touched.

git log -p -n 3

git log -p src/app.ts

git log --stat

git log -- <path>

Limits history to the commits that touched a particular file or folder.

The double dash tells Git that what follows is a path rather than a branch name, which matters when the two share a name. By default the history stops at a rename; add --follow to trace a single file back through its earlier names.

git log -- src/app.ts

git log --oneline -- docs/

git log --follow -- src/lib/helpers.ts

--follow

Continue past renames; works with one file at a time.

git show <commit>

Displays one commit's message, author, date, and the changes it introduced.

Without an argument it shows the latest commit on your branch. It also works on tags, and the commit:path form prints a file exactly as it was in that commit without touching your working copy.

git show

git show a1b2c3d

git show HEAD~2:src/app.ts

git show v1.0.0

--stat

List changed files and line counts instead of the full diff.

--name-only

List only the names of changed files.

git blame <file>

Labels each line of a file with the commit, author, and date of the change that last touched it.

Treat it as a way to find context, such as the commit message behind a puzzling line, rather than a way to assign fault. The most recent change to a line is often just reformatting or moved code, and options like -w and -C help you look past those to where the code really came from.

git blame src/app.ts

git blame -L 40,60 src/app.ts

git blame -w -C src/app.ts

-L <start>,<end>

Restrict the output to a range of lines.

-w

Ignore changes that only affect whitespace.

-C

Detect lines that were moved or copied from other files changed in the same commit.

--ignore-rev <commit>

Skip over a specific commit, such as a bulk reformat.

git reflog

Lists every recent position of HEAD, including commits that no longer appear on any branch.

When a reset, rebase, amend, or deleted branch seems to have lost commits, the reflog almost always still points to them, making it the closest thing Git has to a general undo. It is stored only on your machine, old entries are pruned after a while (by default 90 days, or 30 for commits no longer on any branch), and it cannot recover changes that were never committed.

git reflog

git branch rescue "HEAD@{2}"

git reset --hard "HEAD@{1}"

git reflog show feature/search

git revert <commit>

Creates a new commit that applies the exact opposite of an earlier commit.

Because it adds to history instead of removing anything, revert is the safe way to back out a change that is already on a shared branch. Reverting a merge commit needs -m to say which parent represents the main line.

git revert a1b2c3d

git revert --no-edit HEAD

git revert -m 1 f00ba12

git revert -n a1b2c3d e4f5a6b

--no-edit

Use the generated message without opening an editor.

-n

Apply the reverse changes but leave the commit to you.

-m <parent-number>

Choose which parent counts as the main line when reverting a merge.

git reset --soft HEAD~1

Moves the current branch back to an earlier commit while keeping all of the undone changes staged.

It removes the commit and nothing else, so your files and staging area stay exactly as they were and you can recommit with a new message or combine several recent commits into one. If those commits were already pushed, use git revert instead.

git reset --soft HEAD~1

git reset --soft HEAD~3

git reset HEAD~1

Moves the current branch back and unstages the undone changes, leaving them in your working files.

This is the --mixed mode, which is the default, so the flag is normally left out. It suits undoing a commit when you want to stage its changes again in a different arrangement. Run without a commit, git reset simply unstages everything and changes no files.

git reset HEAD~1

git reset --mixed a1b2c3d

git reset

git reset --hard <commit>

Moves the current branch to a commit and makes the staging area and tracked files match it exactly.

It is the fastest way to throw everything away and return to a known state, such as matching the remote after a failed experiment. Untracked files are left alone; git clean handles those.

Careful: Uncommitted changes to tracked files are overwritten, and edits that were never staged are gone for good. Commits you reset past can usually be recovered through git reflog for a while, but uncommitted work cannot. Check git status and consider git stash before running it.

git reset --hard HEAD

git reset --hard origin/main

git restore --staged <file>

Takes a file's changes out of the staging area while keeping the edits in your working copy.

This is the safe way to take back a git add before you commit, since your files are not modified. Older versions of Git suggested git reset HEAD <file> for the same job, and that still works.

git restore --staged src/app.ts

git restore --staged .

git restore --staged -p src/app.ts

git clean -n

Lists the untracked files that git clean would delete, without deleting anything.

Always preview first, because clean removes files Git has never stored, so there is no history to restore them from. Use the same extra flags in the preview that you plan to use for the real run.

git clean -n

git clean -nd

git clean -ndX

-d

Include untracked folders.

-x

Also include files that .gitignore would normally protect.

-X

Include only ignored files.

git clean -fd

Permanently deletes untracked files and folders from your working tree.

By default Git will not delete anything unless you pass -f, a guard controlled by the clean.requireForce setting. Use it to clear out generated files or leftovers after switching branches, once a dry run has shown exactly what will go.

Careful: The deleted files were never in Git, so no Git command can bring them back, and they do not go to the recycle bin or trash. Adding -x also wipes ignored files such as .env and local configuration. Run git clean -n with the same flags first.

git clean -fd

git clean -fdx

-f

Required before anything is actually deleted.

-d

Include untracked folders.

-x

Also delete ignored files.

-i

Choose what to delete from an interactive menu.

git stash

Shelves your uncommitted changes to tracked files and returns the working tree to the last commit.

Both staged and unstaged edits are saved, but untracked files stay behind unless you add -u. It is shorthand for git stash push, and when you bring the work back, Git does not try to restore which changes were staged unless you pass --index.

git stash

git stash -u

-u

Also stash untracked files.

-a

Also stash untracked and ignored files.

git stash push -m "message"

Shelves changes with a description so you can tell your stashes apart later.

Without a message each entry is labelled only with the branch and the commit it was based on, which gets confusing once there are several. The push form also accepts file paths, so you can stash some files and leave the rest in place.

git stash push -m "half-done search filters"

git stash push -m "styles only" -- src/app/globals.css

git stash push --staged -m "ready parts"

git stash push -p

-m <message>

Attach a description to the stash.

--staged

Stash only staged changes.

-p

Pick individual chunks interactively.

-u

Include untracked files.

git stash list

Shows every saved stash, newest first, each with a reference such as stash@{0}.

stash@{0} is always the most recent entry, and the numbers shift as stashes are added or removed. Use git stash show to look inside one before restoring it. In PowerShell, wrap references like stash@{1} in quotes so the braces are passed to Git intact.

git stash list

git stash show "stash@{1}"

git stash show -p "stash@{1}"

git stash pop

Reapplies the latest stash, or one you name, and removes it from the stash list.

If applying it causes a conflict, Git keeps the stash so nothing is lost, and you drop it yourself once the conflict is resolved. Pop is the usual choice when you are simply resuming the shelved work.

git stash pop

git stash pop "stash@{2}"

git stash pop --index

--index

Try to restore the staged state as well as the file changes.

git stash apply

Reapplies a stash to your working tree but keeps it in the stash list.

Pick apply over pop when you want the same changes on more than one branch, or when you would like the stash kept as a backup until you are happy with the result. Remove it afterwards with git stash drop.

git stash apply

git stash apply "stash@{1}"

git stash branch fix-from-stash "stash@{1}"

git stash drop

Deletes one stash entry, the most recent one unless you name another.

Use it to tidy up after an apply, or after resolving a conflicted pop. To remove every stash at once, run git stash clear.

Careful: A dropped stash disappears from the list. Git prints its commit ID as it drops it, and until garbage collection runs you can still reapply that ID with git stash apply, but there is no simple listing to find it again later, so treat dropping and clearing as permanent.

git stash drop

git stash drop "stash@{2}"

git stash clear

git tag

Lists the tags in the repository.

With no arguments it only lists; give it a name and it creates a tag instead. Tags are sorted by name, so v1.10.0 appears before v1.9.0 unless you ask for version-aware sorting.

git tag

git tag -l "v2.*"

git tag --sort=-version:refname

git tag -n

-l <pattern>

Only list tags matching the pattern.

--sort=<key>

Change the order, for example by version number or date.

-d <tag>

Delete a local tag; the remote copy is not affected.

git tag <name>

Creates a lightweight tag, which is simply a name pointing at a commit.

Lightweight tags store no author, date, or message, so they work better as private bookmarks than as public release markers. Without a commit argument the tag goes on your current commit.

git tag before-refactor

git tag v0.9-test a1b2c3d

git tag -a <name> -m "message"

Creates an annotated tag that records who made it, when, and a message, along with the commit it marks.

Annotated tags are stored as full objects in the repository, which makes them the better fit for releases, and they are the kind git describe looks for by default. They can also be signed with -s so others can verify who created them.

git tag -a v1.2.0 -m "Release 1.2.0"

git tag -a v1.1.1 -m "Patch release" a1b2c3d

git show v1.2.0

-a

Create an annotated tag.

-m <message>

Give the message inline instead of opening an editor.

-s

Create a signed annotated tag using your configured signing key.

git push origin <tag>

Uploads tags to a remote, which an ordinary git push does not do.

Tags stay on your machine until you push them explicitly. The --follow-tags option is a tidy middle ground that sends annotated tags pointing at the commits you are pushing, without publishing every lightweight bookmark.

git push origin v1.2.0

git push origin --tags

git push --follow-tags

git config --global push.followTags true

--tags

Push all local tags.

--follow-tags

Push annotated tags that point at commits included in this push.