Every change in a Git repository can be inspected before it is staged or committed. The git diff command shows the exact lines that were added, removed, or modified — between your working directory, the staging area, and any two commits or branches.

This guide explains how to use git diff to review changes at every stage of your workflow.

Basic Usage #

Run git diff with no arguments to see all unstaged changes — differences between your working directory and the staging area:

git diff

diff --git a/app.py b/app.py
index 3b1a2c4..7d8e9f0 100644
--- a/app.py
+++ b/app.py
@@ -10,6 +10,7 @@ def main():
print("Starting app")
+ print("Debug mode enabled")
run()

Lines starting with + were added. Lines starting with - were removed. Lines with no prefix are context — unchanged lines shown for reference.

If nothing is shown, all changes are already staged or there are no changes at all.

Staged Changes #

To see changes that are staged and ready to commit, use --staged (or its synonym --cached):

git diff --staged

This compares the staging area against the last commit. It shows exactly what will go into the next commit.

git diff --cached

Both flags are equivalent. Use whichever you prefer.

Comparing Commits #

Pass two commit hashes to compare them directly:

git diff abc1234 def5678

To compare a commit against its parent, use the ^ suffix:

git diff HEAD^ HEAD

HEAD refers to the latest commit. HEAD^ is one commit before it. You can go further back with HEAD~2, HEAD~3, and so on.

To see what changed in the last commit:

git diff HEAD^ HEAD

Comparing Branches #

Use the same syntax to compare two branches:

git diff main feature-branch

This shows all differences between the tips of the two branches.

To see only what a branch adds relative to main — excluding changes already in main — use the three-dot notation:

git diff main...feature-branch

The three-dot form finds the common ancestor of both branches and diffs from there to the tip of feature-branch. This is the most useful form for reviewing a pull request before merging.

Comparing a Specific File #

To limit the diff to a single file, pass the path after --:

git diff -- path/to/file.py

The -- separator tells Git the argument is a file path, not a branch name. Combine it with commit references to compare a file across commits:

git diff HEAD~3 HEAD -- path/to/file.py

Summary with –stat #

To see a summary of which files changed and how many lines were added or removed — without the full diff — use --stat:

git diff --stat

 app.py | 3 +++
config.yml | 1 -
2 files changed, 3 insertions(+), 1 deletion(-)

This is useful for a quick overview before reviewing the full diff.

Word-Level Diff #

By default, git diff highlights changed lines. To highlight only the changed words within a line, use --word-diff:

git diff --word-diff

@@ -10,6 +10,6 @@ def main():
print("[-Starting-]{+Running+} app")

Removed words appear in [-brackets-] and added words in {+braces+}. This is especially useful for prose or configuration files where only part of a line changes.

Ignoring Whitespace #

To ignore whitespace-only changes, use -w:

git diff -w

Use -b to ignore changes in the amount of whitespace (but not all whitespace):

git diff -b

These options are useful when reviewing files that have been reformatted or indented differently.

Quick Reference #

For a printable quick reference, see the Git cheatsheet .

FAQ #

What is the difference between git diff and git diff --staged?
git diff shows changes in your working directory that have not been staged yet. git diff --staged shows changes that have been staged with git add and are ready to commit. To see all changes — staged and unstaged combined — use git diff HEAD.

What does the three-dot ... notation do in git diff?
git diff main...feature finds the common ancestor of main and feature and shows the diff from that ancestor to the tip of feature. This isolates the changes that the feature branch introduces, ignoring any new commits in main since the branch was created. In git diff, the two-dot form is just another way to name the two revision endpoints, so git diff main..feature is effectively the same as git diff main feature.

How do I see only the file names that changed, not the full diff?
Use git diff --name-only. To include the change status (modified, added, deleted), use git diff --name-status instead.

How do I compare my local branch against the remote?
Fetch first to update remote-tracking refs, then diff against the updated remote branch. To see what your current branch changes relative to origin/main, use git fetch && git diff origin/main...HEAD. If you want a direct endpoint comparison instead, use git fetch && git diff origin/main HEAD.

Can I use git diff to generate a patch file?
Yes. Redirect the output to a file: git diff > changes.patch. Apply it on another machine with git apply changes.patch.

Conclusion #

git diff is the primary tool for reviewing changes before you stage or commit them. Use git diff for unstaged work, git diff --staged before committing, and git diff main...feature to review a branch before merging. For a history of committed changes, see the git log guide .

Every commit in a Git repository is recorded in the project history. The git log command lets you browse that history — showing who made each change, when, and why. It is one of the most frequently used Git commands and one of the most flexible.

This guide explains how to use git log to view, filter, and format commit history.

Basic Usage #

Run git log with no arguments to see the full commit history of the current branch, starting from the most recent commit:

git log

commit a3f1d2e4b5c6789012345678901234567890abcd
Author: Jane Smith <jane@example.com>
Date: Mon Mar 10 14:22:31 2026 +0100
Add user authentication module
commit 7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c
Author: John Doe <john@example.com>
Date: Fri Mar 7 09:15:04 2026 +0100
Fix login form validation

Each entry shows the full commit hash, author name and email, date, and commit message. Press q to exit the log view.

Compact Output with –oneline #

The default output is verbose. Use --oneline to show one commit per line — the abbreviated hash and the subject line only:

git log --oneline

a3f1d2e Add user authentication module
7b8c9d0 Fix login form validation
c1d2e3f Update README with setup instructions

This is useful for a quick overview of recent work.

Limiting the Number of Commits #

To show only the last N commits, pass -n followed by the number:

git log -n 5

You can also write it without the space:

git log -5

Filtering by Author #

Use --author to show only commits by a specific person. The value is matched as a substring against the author name or email:

git log --author="Jane"

To match multiple authors, pass --author more than once:

git log --author="Jane" --author="John"

Filtering by Date #

Use --since and --until to limit commits to a date range. These options accept a variety of formats:

git log --since="2 weeks ago"
git log --since="2026-03-01" --until="2026-03-15"

Searching Commit Messages #

Use --grep to find commits whose message contains a keyword:

git log --grep="authentication"

The search is case-sensitive by default. Add -i to make it case-insensitive:

git log -i --grep="fix"

Viewing Changed Files #

To see a summary of which files were changed in each commit without the full diff, use --stat:

git log --stat

commit a3f1d2e4b5c6789012345678901234567890abcd
Author: Jane Smith <jane@example.com>
Date: Mon Mar 10 14:22:31 2026 +0100
Add user authentication module
src/auth.py | 84 ++++++++++++++++++++++++++++++++++++++++++++++++
src/models.py | 12 +++++++
tests/test_auth.py | 45 +++++++++++++++++
3 files changed, 141 insertions(+)

To see the full diff for each commit, use -p (or --patch):

git log -p

Combine with -n to limit the output:

git log -p -3

Viewing History of a Specific File #

To see only the commits that touched a particular file, pass the file path after --:

git log -- path/to/file.py

The -- separator tells Git that what follows is a path, not a branch name. Add -p to see the exact changes made to that file in each commit:

git log -p -- path/to/file.py

Branch and Graph View #

To visualize how branches diverge and merge, use --graph:

git log --oneline --graph

* a3f1d2e Add user authentication module
* 7b8c9d0 Fix login form validation
| * 3e4f5a6 WIP: dark mode toggle
|/
* c1d2e3f Update README with setup instructions

Add --all to include all branches, not just the current one:

git log --oneline --graph --all

This gives a full picture of the repository’s branch and merge history.

Comparing Two Branches #

To see commits that are in one branch but not another, use the .. notation:

git log main..feature-branch

This shows commits reachable from feature-branch that are not yet in main — useful for reviewing what a branch adds before merging.

Custom Output Format #

Use --pretty=format: to define exactly what each log line shows. Some useful placeholders:

• %h — abbreviated commit hash
• %an — author name
• %ar — author date, relative
• %s — subject (first line of commit message)

For example:

git log --pretty=format:"%h %an %ar %s"

a3f1d2e Jane Smith 5 days ago Add user authentication module
7b8c9d0 John Doe 8 days ago Fix login form validation

Excluding Merge Commits #

To hide merge commits and see only substantive changes, use --no-merges:

git log --no-merges --oneline

Quick Reference #

For a printable quick reference, see the Git cheatsheet .

FAQ #

How do I search for a commit that changed a specific piece of code?
Use -S (the “pickaxe” option) to find commits that added or removed a specific string: git log -S "function_name". For regex patterns, use -G "pattern" instead.

How do I see who last changed each line of a file?
Use git blame path/to/file. It annotates every line with the commit hash, author, and date of the last change.

What is the difference between git log and git reflog?
git log shows the commit history of the current branch. git reflog shows every movement of HEAD — including commits that were reset, rebased, or are no longer reachable from any branch. It is the main recovery tool if you lose commits accidentally.

How do I find a commit by its message?
Use git log --grep="search term". For case-insensitive search add -i. If you need to search the full commit message body as well as the subject, add --all-match only when combining multiple --grep patterns, or use git log --grep="search term" --format=full to inspect matching commits more closely. Use -E only when you need extended regular expressions in the grep pattern.

How do I show a single commit in full detail?
Use git show <hash>. It prints the commit metadata and the full diff. To show just the files changed without the diff, use git show --stat <hash>.

Conclusion #

git log is the primary tool for understanding a project’s history. Start with --oneline for a quick overview, use --graph --all to visualize branches, and combine --author, --since, and --grep to zero in on specific changes. For undoing commits found in the log, see the git revert guide or how to undo the last commit .

When you are in the middle of a feature and need to switch branches to fix a bug or review someone else’s work, you have a problem: your changes are not ready to commit, but you cannot switch branches with a dirty working tree. git stash solves this by saving your uncommitted changes to a temporary stack so you can restore them later.

This guide explains how to use git stash to save, list, apply, and delete stashed changes.

Basic Usage #

The simplest form saves all modifications to tracked files and reverts the working tree to match the last commit:

git stash

Saved working directory and index state WIP on main: abc1234 Add login page

Your working tree is now clean. You can switch branches, pull updates, or apply a hotfix. When you are ready to return to your work, restore the stash.

By default, git stash saves both staged and unstaged changes to tracked files. It does not save untracked or ignored files unless you explicitly include them (see below).

Stashing with a Message #

A plain git stash entry shows the branch and last commit message, which becomes hard to read when you have multiple stashes. Use -m to attach a descriptive label:

git stash push -m "WIP: user authentication form"

This makes it easy to identify the right stash when you list them later.

Listing Stashes #

To see all saved stashes, run:

git stash list

stash@{0}: On main: WIP: user authentication form
stash@{1}: WIP on main: abc1234 Add login page

Stashes are indexed from newest (stash@{0}) to oldest. The index is used when you want to apply or drop a specific stash.

To inspect the contents of a stash before applying it, use git stash show:

git stash show stash@{0}

Add -p to see the full diff:

git stash show -p stash@{0}

Applying Stashes #

There are two ways to restore a stash.

git stash pop applies the most recent stash and removes it from the stash list:

git stash pop

git stash apply applies a stash but keeps it in the list so you can apply it again or to another branch:

git stash apply

To apply a specific stash by index, pass the stash reference:

git stash apply stash@{1}

If applying the stash causes conflicts, resolve them the same way you would resolve a merge conflict, then stage the resolved files.

Stashing Untracked and Ignored Files #

By default, git stash only saves changes to files that Git already tracks. New files you have not yet staged are left behind.

Use -u (or --include-untracked) to include untracked files:

git stash -u

To include both untracked and ignored files — for example, generated build artifacts or local config files — use -a (or --all):

git stash -a

Partial Stash #

If you only want to stash some of your changes and leave others in the working tree, use the -p (or --patch) flag to interactively select which hunks to stash:

git stash -p

Git will step through each changed hunk and ask whether to stash it. Type y to stash the hunk, n to leave it, or ? for a full list of options.

Creating a Branch from a Stash #

If you have been working on a stash for a while and the branch has diverged enough to cause conflicts on apply, you can create a new branch from the stash directly:

git stash branch new-branch-name

This creates a new branch, checks it out at the commit where the stash was originally made, applies the stash, and drops it from the list if it applied cleanly. It is the safest way to resume stashed work that has grown out of sync with the base branch.

Deleting Stashes #

To remove a specific stash once you no longer need it:

git stash drop stash@{0}

To delete all stashes at once:

git stash clear

Use clear with care — there is no undo.

Quick Reference #

For a printable quick reference, see the Git cheatsheet .

FAQ #

What is the difference between git stash pop and git stash apply?
pop applies the stash and removes it from the stash list. apply restores the changes but keeps the stash entry so you can apply it again — for example, to multiple branches. Use pop for normal day-to-day use and apply when you need to reuse the stash.

Does git stash save untracked files?
No, not by default. Run git stash -u to include untracked files, or git stash -a to also include files that match your .gitignore patterns.

Can I stash only specific files?
Yes. In modern Git, you can pass pathspecs to git stash push, for example: git stash push -m "label" -- path/to/file. If you need a more portable workflow, use git stash -p to interactively select which hunks to stash.

How do I recover a dropped stash?
If you accidentally ran git stash drop or git stash clear, the underlying commit may still exist for a while. Run git fsck --no-reflogs | grep "dangling commit" to list unreachable commits, then git show <hash> to inspect them. If you find the right stash commit, you can recreate it with git stash store -m "recovered stash" <hash> and then apply it normally.

Can I apply a stash to a different branch?
Yes. Switch to the target branch with git switch branch-name, then run git stash apply stash@{0}. If there are no conflicts, the changes are applied cleanly. If the branches have diverged significantly, consider git stash branch to create a fresh branch from the stash instead.

Conclusion #

git stash is the cleanest way to set aside incomplete work without creating a throwaway commit. Use git stash push -m to keep your stash list readable, prefer pop for one-time restores, and use git stash branch when applying becomes messy. For a broader overview of Git workflows, see the Git cheatsheet or the git revert guide .

f-strings, short for formatted string literals, are the most concise and readable way to format strings in Python. Introduced in Python 3.6, they let you embed variables and expressions directly inside a string by prefixing it with f or F.

This guide explains how to use f-strings in Python, including expressions, format specifiers, number formatting, alignment, and the debugging shorthand introduced in Python 3.8.

Basic Syntax #

An f-string is a string literal prefixed with f. Any expression inside curly braces {} is evaluated at runtime and its result is inserted into the string:

name = "Leia"
age = 30
print(f"My name is {name} and I am {age} years old.")

My name is Leia and I am 30 years old.

Any valid Python expression can appear inside the braces — variables, attribute access, method calls, or arithmetic:

price = 49.99
quantity = 3
print(f"Total: {price * quantity}")

Total: 149.97

Expressions Inside f-Strings #

You can call methods and functions directly inside the braces:

name = "alice"
print(f"Hello, {name.upper()}!")

Hello, ALICE!

Ternary expressions work as well:

age = 20
print(f"Status: {'adult' if age >= 18 else 'minor'}")

Status: adult

You can also access dictionary keys and list items:

user = {"name": "Bob", "city": "Berlin"}
print(f"{user['name']} lives in {user['city']}.")

Bob lives in Berlin.

Escaping Braces #

To include a literal curly brace in an f-string, double it:

value = 42
print(f"{{value}} = {value}")

{value} = 42

Multiline f-Strings #

To build a multiline f-string, wrap it in triple quotes:

name = "Leia"
age = 30
message = f"""
Name: {name}
Age: {age}
"""
print(message)

Name: Leia
Age: 30

Alternatively, use implicit string concatenation to keep each line short:

message = (
 f"Name: {name}\n"
 f"Age: {age}"
)

Format Specifiers #

f-strings support Python’s format specification mini-language. The full syntax is:

{value:[fill][align][sign][width][grouping][.precision][type]}

Floats and Precision #

Control the number of decimal places with :.Nf:

pi = 3.14159265
print(f"{pi:.2f}")
print(f"{pi:.4f}")

3.14
3.1416

Thousands Separator #

Use , to add a thousands separator:

population = 1_234_567
print(f"{population:,}")

1,234,567

Percentage #

Use :.N% to format a value as a percentage:

score = 0.875
print(f"Score: {score:.1%}")

Score: 87.5%

Scientific Notation #

Use :e for scientific notation:

distance = 149_600_000
print(f"{distance:e}")

1.496000e+08

Alignment and Padding #

Use <, >, and ^ to align text within a fixed width. Optionally specify a fill character before the alignment symbol:

print(f"{'left':<10}|")
print(f"{'right':>10}|")
print(f"{'center':^10}|")
print(f"{'padded':*^10}|")

left |
right|
center |
**padded**|

Number Bases #

Convert integers to binary, octal, or hexadecimal with the b, o, x, and X type codes:

n = 255
print(f"Binary: {n:b}")
print(f"Octal: {n:o}")
print(f"Hex (lower): {n:x}")
print(f"Hex (upper): {n:X}")

Binary: 11111111
Octal: 377
Hex (lower): ff
Hex (upper): FF

Debugging with = #

Python 3.8 introduced the = shorthand, which prints both the expression and its value. This is useful for quick debugging:

x = 42
items = [1, 2, 3]
print(f"{x=}")
print(f"{len(items)=}")

x=42
len(items)=3

The = shorthand preserves the exact expression text, making it more informative than a plain print().

Quick Reference #

FAQ #

What Python version do f-strings require?
f-strings were introduced in Python 3.6. If you are on Python 3.5 or earlier, use str.format() or % formatting instead.

What is the difference between f-strings and str.format()?
f-strings are evaluated at runtime and embed expressions inline. str.format() uses positional or keyword placeholders and is slightly more verbose. f-strings are generally faster and easier to read for straightforward formatting.

Can I use quotes inside an f-string expression?
Yes, but you must use a different quote type from the one wrapping the f-string. For example, if the f-string uses double quotes, use single quotes inside the braces: f"Hello, {user['name']}". In Python 3.12 and later, the same quote type can be reused inside the braces.

Can I use f-strings with multiline expressions?
Expressions inside {} cannot contain backslashes directly, but you can pre-compute the value in a variable first and reference that variable in the f-string.

Are f-strings faster than % formatting?
In many common cases, f-strings are faster than % formatting and str.format(), while also being easier to read. Exact performance depends on the expression and Python version, so readability is usually the more important reason to prefer them.

Conclusion #

f-strings are the preferred way to format strings in Python 3.6 and later. They are concise, readable, and support the full format specification mini-language for controlling number precision, alignment, and type conversion. For related string operations, see Python String Replace and How to Split a String in Python .

A Python virtual environment is a self-contained directory that includes its own Python interpreter and a set of installed packages, isolated from the system-wide Python installation. Using virtual environments lets each project maintain its own dependencies without affecting other projects on the same machine.

This guide explains how to create and manage virtual environments using venv (built into Python 3) and virtualenv (a popular third-party alternative) on Linux and macOS.

Quick Reference #

What Is a Python Virtual Environment? #

When you install a package globally with pip install, it is available to every Python script on the system. This becomes a problem when two projects need different versions of the same library — for example, one requires requests==2.28.0 and another requires requests==2.31.0. Installing both globally is not possible.

A virtual environment solves this by giving each project its own isolated space for packages. Activating an environment prepends its bin/ directory to your PATH, so python and pip resolve to the versions inside the environment rather than the system-wide ones.

Installing venv #

The venv module ships with Python 3 and requires no separate installation on most systems. On Ubuntu and Debian, the module is packaged separately:

sudo apt install python3-venv

On Fedora, RHEL, and Derivatives, venv is included with the Python package by default.

Verify your Python version before creating an environment:

python3 --version

For more on checking your Python installation, see How to Check Python Version .

Creating a Virtual Environment #

Navigate to your project directory and run:

python3 -m venv venv

The second venv is the name of the directory that will be created. The conventional names are venv or .venv. The directory contains a copy of the Python binary, pip, and the standard library.

To create the environment in a specific location rather than the current directory:

python3 -m venv ~/projects/myproject/venv

Activating the Virtual Environment #

Before using the environment, you need to activate it.

On Linux and macOS:

source venv/bin/activate

Once activated, your shell prompt changes to show the environment name:

(venv) user@host:~/myproject$

From this point on, python and pip refer to the versions inside the virtual environment, not the system-wide ones.

To deactivate the environment and return to the system Python:

deactivate

Installing Packages #

With the environment active, install packages using pip as you normally would. If pip is not installed on your system, see How to Install Python Pip on Ubuntu .

pip install requests

To install a specific version:

pip install requests==2.31.0

To list all packages installed in the current environment:

pip list

Packages installed here are completely isolated from the system and from other virtual environments.

Managing Dependencies with requirements.txt #

Sharing a project with others, or deploying it to another machine, requires a way to reproduce the same package versions. The convention is to save all dependencies to a requirements.txt file:

pip freeze > requirements.txt

The file lists every installed package and its exact version:

certifi==2024.2.2
charset-normalizer==3.3.2
idna==3.6
requests==2.31.0
urllib3==2.2.1

To install all packages from the file in a fresh environment:

pip install -r requirements.txt

This is the standard workflow for reproducing an environment on a different machine or in a CI/CD pipeline.

Using a Specific Python Version #

By default, python3 -m venv uses whichever Python 3 version is the system default. If you have multiple Python versions installed, you can specify which one to use:

python3.11 -m venv venv

This creates an environment based on Python 3.11 regardless of the system default. To check which versions are available :

python3 --version
python3.11 --version

virtualenv: An Alternative to venv #

virtualenv is a third-party package that predates venv and offers a few additional features. Install it with pip:

pip install virtualenv

Creating and activating an environment with virtualenv follows the same pattern:

virtualenv venv
source venv/bin/activate

To use a specific Python interpreter:

virtualenv -p python3.11 venv

When to use virtualenv over venv:

• You need to create environments faster — virtualenv is significantly faster on large projects.
• You are working with Python 2 (legacy codebases only).
• You need features like --copies to copy binaries instead of symlinking.

For most modern Python 3 projects, venv is sufficient and has the advantage of requiring no installation.

Excluding the Environment from Version Control #

The virtual environment directory should never be committed to version control. It is large, machine-specific, and fully reproducible from requirements.txt. Add it to your .gitignore:

echo "venv/" >> .gitignore

If you named your environment .venv instead, add .venv/ to .gitignore.

Troubleshooting #

python3 -m venv venv fails with “No module named venv”
On Ubuntu and Debian, the venv module is not included in the base Python package. Install it with sudo apt install python3-venv, then retry.

pip install installs packages globally instead of into the environment
The environment is not activated. Run source venv/bin/activate first. You can verify by checking which pip — it should point to a path inside your venv/ directory.

“command not found: python” after activating the environment
The environment uses python3 as the binary name if it was created with python3 -m venv. Use python3 explicitly, or check which python and which python3 inside the active environment.

The environment breaks after moving or renaming its directory
Virtual environments contain hardcoded absolute paths to the Python interpreter. Moving or renaming the directory invalidates those paths. Delete the directory and recreate the environment in the new location, then reinstall from requirements.txt.

FAQ #

What is the difference between venv and virtualenv?
venv is a standard library module included with Python 3 — no installation needed. virtualenv is a third-party package with a longer history, faster environment creation, and Python 2 support. For new Python 3 projects, venv is the recommended choice.

Should I commit the virtual environment to git?
No. Add venv/ (or .venv/) to your .gitignore and commit only requirements.txt. Anyone checking out the project can recreate the environment with pip install -r requirements.txt.

Do I need a virtual environment for every project?
It is strongly recommended. Without isolated environments, installing or upgrading a package for one project can break another. The overhead of creating a virtual environment is minimal.

What is the difference between pip freeze and pip list?
pip list shows installed packages in a human-readable format. pip freeze outputs them in requirements.txt format (package==version) suitable for use with pip install -r.

Can I use a virtual environment with a different Python version than the system default?
Yes. Pass the path to the desired interpreter when creating the environment: python3.11 -m venv venv. The environment will use that interpreter for both python and pip commands.

Conclusion #

Virtual environments are the standard way to manage Python project dependencies. Create one with python3 -m venv venv, activate it with source venv/bin/activate, and use pip freeze > requirements.txt to capture your dependencies. For more on managing Python installations, see How to Check Python Version .

systemd is the init system used by most modern Linux distributions, including Ubuntu, Debian, Fedora, and RHEL. It manages system processes, handles service dependencies, and starts services automatically at boot.

A systemd service file — also called a unit file — tells systemd how to start, stop, and manage a process. This guide explains how to create a systemd service file, install it on the system, and manage it with systemctl.

Quick Reference #

Understanding systemd Unit Files #

Service files are plain text files with an .service extension. They are stored in one of two locations:

• /etc/systemd/system/ — system-wide services, managed by root. Files here take priority over package-installed units.
• /usr/lib/systemd/system/ or /lib/systemd/system/ — units installed by packages, depending on the distribution. Do not edit these directly; copy them to /etc/systemd/system/ to override.

A service file is divided into three sections:

• [Unit] — describes the service and declares dependencies.
• [Service] — defines how to start, stop, and run the process.
• [Install] — controls how and when the service is enabled.

Creating a Simple Service File #

In this example, we will create a service that runs a custom Bash script. First, create the script you want to run:

sudo nano /usr/local/bin/myapp.sh

Add the following content to the script:

#!/bin/bash
echo "myapp started" >> /var/log/myapp.log
# your application logic here
exec /usr/local/bin/myapp

Make the script executable:

sudo chmod +x /usr/local/bin/myapp.sh

Now create the service file:

sudo nano /etc/systemd/system/myapp.service

Add the following content:

[Unit]
Description=My Custom Application
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/myapp.sh
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

After saving the file, reload systemd to pick up the new unit:

sudo systemctl daemon-reload

Enable and start the service:

sudo systemctl enable --now myapp

Check that it is running:

sudo systemctl status myapp

● myapp.service - My Custom Application
Loaded: loaded (/etc/systemd/system/myapp.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2026-03-10 09:00:00 CET; 2s ago
Main PID: 1234 (myapp.sh)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/myapp.service
└─1234 /bin/bash /usr/local/bin/myapp.sh

Unit File Sections Explained #

[Unit] Section #

The [Unit] section contains metadata and dependency declarations.

Common directives:

• Description= — a short human-readable name shown in systemctl status output.
• After= — start this service only after the listed units are active. Does not create a dependency; use Requires= for hard dependencies.
• Requires= — this service requires the listed units. If they fail, this service fails too.
• Wants= — like Requires=, but the service still starts even if the listed units fail.
• Documentation= — a URL or man page reference for the service.

[Service] Section #

The [Service] section defines the process and how systemd manages it.

Common directives:

• Type= — the startup type. See Service Types below.
• ExecStart= — the command to run when the service starts. Must be an absolute path.
• ExecStop= — the command to run when the service stops. If omitted, systemd sends SIGTERM.
• ExecReload= — the command to reload the service configuration without restarting.
• Restart= — when to restart automatically. See Restart Policies below.
• RestartSec= — how many seconds to wait before restarting. Default is 100ms.
• User= — run the process as this user instead of root.
• Group= — run the process as this group.
• WorkingDirectory= — set the working directory for the process.
• Environment= — set environment variables: Environment="KEY=value".
• EnvironmentFile= — read environment variables from a file.

[Install] Section #

The [Install] section controls how the service is enabled.

• WantedBy=multi-user.target — the most common value. Enables the service for normal multi-user (non-graphical) boot.
• WantedBy=graphical.target — use this if the service requires a graphical environment.

Service Types #

The Type= directive tells systemd how the process behaves at startup.

For most custom scripts and applications, Type=simple is the right choice.

Restart Policies #

The Restart= directive controls when systemd automatically restarts the service.

For long-running services, Restart=on-failure is the most common choice. Use Restart=always for services that must stay running under all circumstances.

Running a Service as a Non-Root User #

Running services as root is a security risk. Use the User= and Group= directives to run the service as a dedicated user:

[Unit]
Description=My Custom Application
After=network.target

[Service]
Type=simple
User=myappuser
Group=myappuser
ExecStart=/usr/local/bin/myapp
Restart=on-failure
WorkingDirectory=/opt/myapp
Environment="NODE_ENV=production"

[Install]
WantedBy=multi-user.target

Create the system user before enabling the service:

sudo useradd -r -s /usr/sbin/nologin myappuser

Troubleshooting #

Service fails to start — “Failed to start myapp.service”
Check the logs with journalctl : sudo journalctl -u myapp --since "5 minutes ago". The output shows the exact error message from the process.

Changes to the service file have no effect
You must run sudo systemctl daemon-reload after every edit to the unit file. systemd reads the file at reload time, not at start time.

“ExecStart= must be an absolute path”
The ExecStart= value must start with /. Use the full path to the binary — for example /usr/bin/python3 not python3. Use which python3 to find the absolute path.

Service starts but immediately exits
The process may be crashing on startup. Check sudo journalctl -u myapp -n 50 for error output. If Type=simple, make sure ExecStart= runs the process in the foreground — not a script that launches a background process and exits.

Service does not start at boot despite being enabled
Confirm the [Install] section has a valid WantedBy= target and that systemctl enable was run after daemon-reload. Check with systemctl is-enabled myapp.

FAQ #

Where should I put my service file?
Put custom service files in /etc/systemd/system/. Files there take priority over package-installed units in /usr/lib/systemd/system/ and persist across package upgrades.

What is the difference between enable and start?
systemctl start starts the service immediately for the current session only. systemctl enable creates a symlink so the service starts automatically at boot. To do both at once, use systemctl enable --now myservice.

How do I view logs for my service?
Use sudo journalctl -u myservice to see all logs. Add -f to follow live output, or --since "1 hour ago" to limit the time range. See the journalctl guide for full usage.

Can I run a service as a regular user without root?
Yes, using user-level systemd units stored in ~/.config/systemd/user/. Manage them with systemctl --user enable myservice. They run when the user logs in and stop when they log out (unless lingering is enabled with loginctl enable-linger username).

How do I reload a service after changing its configuration?
If the service supports it, use sudo systemctl reload myservice — this sends SIGHUP or runs ExecReload= without restarting the process. Otherwise, use sudo systemctl restart myservice.

Conclusion #

Creating a systemd service file gives you full control over how and when your process runs — including automatic restarts, boot integration, and user isolation. Once the file is in place, use systemctl enable --now to activate it and journalctl -u to monitor it. For scheduling tasks that run once at a set time rather than continuously, consider cron jobs as an alternative.

Git is the world’s most popular distributed version control system used by many open-source and commercial projects. It allows you to collaborate on projects with fellow developers, keep track of your code changes, revert to previous stages, create branches , and more.

This guide covers installing and configuring Git on Debian 13 (Trixie) using apt or by compiling from source.

Quick Reference #

For a printable quick reference, see the Git cheatsheet .

Installing Git with Apt #

This is the quickest way to install Git on Debian.

Check if Git is already installed:

git --version

If Git is not installed, you will see a “command not found” message. Otherwise, it shows the installed version.

Use the apt package manager to install Git:

sudo apt update
sudo apt install git

Verify the installation:

git --version

Debian 13 stable currently provides Git 2.47.3:

git version 2.47.3

You can now start configuring Git.

When a new version of Git is released, you can update using sudo apt update && sudo apt upgrade.

Installing Git from Source #

The main benefit of installing Git from source is that you can compile any version you want. However, you cannot maintain your installation through the apt package manager.

Install the build dependencies:

sudo apt update
sudo apt install libcurl4-gnutls-dev libexpat1-dev cmake gettext libz-dev libssl-dev gcc wget

Visit the Git download page to find the latest version.

At the time of writing, the latest stable Git version is 2.53.0.

If you need a different version, visit the Git archive to find available releases.

Download and extract the source to /usr/src:

wget -c https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.53.0.tar.gz -O - | sudo tar -xz -C /usr/src

Navigate to the source directory and compile:

cd /usr/src/git-*
sudo make prefix=/usr/local all
sudo make prefix=/usr/local install

The compilation may take some time depending on your system.

If your shell still resolves /usr/bin/git after installation, open a new terminal or verify your PATH and binary location with:

which git
echo $PATH

Verify the installation:

git --version

git version 2.53.0

To upgrade to a newer version later, repeat the same process with the new version number.

Configuring Git #

After installing Git, configure your username and email address. Git associates your identity with every commit you make.

Set your global commit name and email:

git config --global user.name "Your Name"
git config --global user.email "youremail@yourdomain.com"

Verify the configuration:

git config --list

user.name=Your Name
user.email=youremail@yourdomain.com

The configuration is stored in ~/.gitconfig:

[user]
name = Your Name
email = youremail@yourdomain.com

You can edit the configuration using the git config command or by editing ~/.gitconfig directly.

For a deeper walkthrough, see How to Configure Git Username and Email .

Troubleshooting #

E: Unable to locate package git
Run sudo apt update first and verify you are on Debian 13 repositories. If sources were recently changed, refresh package metadata again.

git --version still shows an older version after source install
Your shell may still resolve /usr/bin/git before /usr/local/bin/git. Check with which git and adjust PATH order if needed.

Build fails with missing headers or libraries
One or more dependencies are missing. Re-run the dependency install command and then compile again.

make succeeds but git command is not found
Confirm install step ran successfully: sudo make prefix=/usr/local install. Then check /usr/local/bin/git exists.

FAQ #

Should you use apt or source on Debian 13?
For most systems, use apt because updates are integrated with Debian security and package management. Build from source only when you need a newer Git release than the repository version.

Does compiling from source replace the apt package automatically?
No. Source builds under /usr/local and can coexist with the apt package in /usr/bin. Your PATH order determines which binary runs by default.

How can you remove a source-installed Git version?
If you built from the source tree, run sudo make prefix=/usr/local uninstall from that same source directory.

Conclusion #

We covered two ways to install Git on Debian 13: using apt, which provides Git 2.47.3, or compiling from source for the latest version. The default repository version is sufficient for most use cases.

For more information, see the Pro Git book .

ss is a command-line utility for displaying socket statistics on Linux. It is the modern replacement for the deprecated netstat command and is faster, more detailed, and available by default on all current Linux distributions.

This guide explains how to use ss to list open sockets, filter results by protocol and port, and identify which process is using a given connection.

ss Syntax #

ss [OPTIONS] [FILTER]

When invoked without options, ss displays all non-listening sockets that have an established connection.

List All Sockets #

To list all sockets regardless of state, use the -a option:

ss -a

The output includes columns for the socket type (Netid), state, receive and send queue sizes, local address and port, and peer address and port:

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp ESTAB 0 0 192.168.1.10:ssh 192.168.1.5:52710
tcp LISTEN 0 128 0.0.0.0:http 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:bootpc 0.0.0.0:*

Filter by Socket Type #

TCP Sockets (-t) #

To list only TCP sockets:

ss -t

To include listening TCP sockets as well, combine with -a:

ss -ta

UDP Sockets (-u) #

To list only UDP sockets:

ss -ua

Unix Domain Sockets (-x) #

To list Unix domain sockets used for inter-process communication:

ss -xa

Show Listening Sockets #

The -l option shows only sockets that are in the listening state:

ss -tl

The most commonly used combination is -tulpn, which shows all TCP and UDP listening sockets with process names and numeric addresses:

ss -tulpn

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))
tcp LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=5678,fd=6))
udp UNCONN 0 0 0.0.0.0:68 0.0.0.0:* users:(("dhclient",pid=910,fd=6))

Each option in the combination does the following:

• -t — show TCP sockets
• -u — show UDP sockets
• -l — show listening sockets only
• -p — show the process name and PID
• -n — show numeric addresses and ports instead of resolving hostnames and service names

Show Process Information #

The -p option adds the process name and PID to the output. This requires root privileges to see processes owned by other users:

sudo ss -tp

State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
ESTAB 0 0 192.168.1.10:ssh 192.168.1.5:52710 users:(("sshd",pid=2341,fd=5))

Use Numeric Output #

By default, ss resolves port numbers to service names (for example, port 22 becomes ssh). The -n option disables this and shows raw port numbers:

ss -tn

This is useful when you need to match exact port numbers in scripts or when name resolution is slow.

Filter by Port #

To find which process is using a specific port, filter by destination or source port. For example, to list all sockets using port 80:

ss -tulpn | grep :80

You can also use the built-in filter syntax:

ss -tnp 'dport = :443'

To filter by source port:

ss -tnp 'sport = :22'

Filter by Connection State #

ss supports filtering by connection state. Common states include ESTABLISHED, LISTEN, TIME-WAIT, and CLOSE-WAIT.

To show only established TCP connections:

ss -tn state ESTABLISHED

To show only sockets in the TIME-WAIT state:

ss -tn state TIME-WAIT

Filter by Address #

To show sockets connected to or from a specific IP address:

ss -tn dst 192.168.1.5

To filter by source address:

ss -tn src 192.168.1.10

You can combine address and port filters:

ss -tnp dst 192.168.1.5 dport = :22

Show IPv4 or IPv6 Only #

To restrict output to IPv4 sockets, use -4:

ss -tln -4

To show only IPv6 sockets, use -6:

ss -tln -6

Show Summary Statistics #

The -s option prints a summary of socket counts by type and state without listing individual sockets:

ss -s

Total: 312
TCP: 14 (estab 4, closed 3, orphaned 0, timewait 3)
Transport Total IP IPv6
RAW 1 0 1
UDP 6 4 2
TCP 11 7 4
INET 18 11 7
FRAG 0 0 0

This is useful for a quick overview of the network state on a busy server.

Practical Examples #

The following examples cover common diagnostics you will use together with tools like ip , ifconfig , and check listening ports .

Find which process is listening on port 8080:

sudo ss -tlpn sport = :8080

List all established SSH connections to your server:

ss -tn state ESTABLISHED '( dport = :22 or sport = :22 )'

Show all connections to a remote host:

ss -tn dst 203.0.113.10

Count established TCP connections:

ss -tn state ESTABLISHED | tail -n +2 | wc -l

Quick Reference #

Troubleshooting #

ss -p does not show process names
Process information for sockets owned by other users requires elevated privileges. Use sudo ss -tp or sudo ss -tulpn.

Filters return no results
Use quoted filter expressions such as ss -tn 'dport = :443', and verify whether you should filter by sport or dport.

Service names hide numeric ports
If output shows service names (ssh, http) instead of port numbers, add -n to keep numeric ports and avoid lookup ambiguity.

Output is too broad on busy servers
Start with protocol and state filters (-t, -u, state ESTABLISHED) and then add address or port filters to narrow results.

You need command-level context, not only sockets
Use ss with ps or pgrep when you need additional process detail.

FAQ #

What is the difference between ss and netstat?
ss is the modern replacement for netstat. It reads directly from kernel socket structures, making it significantly faster on systems with many connections. netstat is part of the net-tools package, which is deprecated and not installed by default on most current distributions.

Why do I need sudo with ss -p?
Without root privileges, ss can only show process information for sockets owned by your own user. To see process names and PIDs for all sockets, run ss with sudo.

What does Recv-Q and Send-Q mean in the output?
Recv-Q is the number of bytes received but not yet read by the application. Send-Q is the number of bytes sent but not yet acknowledged by the remote host. Non-zero values on a listening socket or consistently high values can indicate a performance issue.

How do I find which process is using a specific port?
Run sudo ss -tulpn | grep :<port>. The -p flag adds process information and -n keeps port numbers numeric so the grep match is reliable.

Conclusion #

ss is the standard tool for inspecting socket connections on modern Linux systems. The -tulpn combination covers most day-to-day needs, while the state and address filters make it easy to narrow results on busy servers. For related network diagnostics, see the ip and ifconfig command guides, or check listening ports for a broader overview.