When working with text files, you will often need to remove specific lines, whether it is stripping comments from a configuration file, cleaning up blank lines in log output, or cutting a range of lines from a data dump. The sed stream editor handles all of these cases from the command line, without opening the file in an editor.

sed processes input line by line, applies your commands, and writes the result to standard output. The original file stays untouched unless you explicitly tell sed to edit in place. If you need to find and replace text rather than remove entire lines, see How to Use sed to Find and Replace Strings in Files .

This guide explains how to use the sed delete command (d) with practical examples covering line numbers, patterns, ranges, and regular expressions.

How the Delete Command Works #

The general form of a sed delete expression is:

sed 'ADDRESSd' file

ADDRESS selects which lines to delete, and d is the delete command. When sed encounters a line that matches the address, it removes that line from the output entirely. Any line that does not match the address is printed as usual.

For demonstration purposes, the examples in this guide use the following file:

red
green
blue
yellow
white
black
orange
purple

Delete by Line Number #

The simplest form of delete targets a specific line number. To remove the third line, place 3 before the d command:

sed '3d' colors.txt

red
green
yellow
white
black
orange
purple

Notice that “blue” (which was on line 3) is gone from the output, but the original colors.txt file is unchanged. This is the default behavior of sed, and it gives you a safe way to preview changes before committing them.

Sometimes you need to remove the last line of a file without knowing how many lines it contains. The $ address represents the last line:

sed '$d' colors.txt

red
green
blue
yellow
white
black
orange

Here “purple” (the last line) has been removed from the output.

Delete Multiple Specific Lines #

If you need to remove several individual lines, separate the addresses with a semicolon. The following command deletes lines 2, 5, and 8 in a single pass:

sed '2d;5d;8d' colors.txt

red
blue
yellow
black
orange

The output is missing “green” (line 2), “white” (line 5), and “purple” (line 8). You can list as many addresses as needed this way.

Delete a Range of Lines #

To delete a block of consecutive lines, specify a range with two numbers separated by a comma. The following command removes lines 3 through 6:

sed '3,6d' colors.txt

red
green
orange
purple

Everything from “blue” (line 3) through “black” (line 6) is gone, and the remaining lines print normally.

You can also combine a line number with $ to delete from a given line to the end of the file. This keeps only the first four lines:

sed '5,$d' colors.txt

red
green
blue
yellow

Adding ! after the address inverts the selection, so sed deletes every line that is not in the range. The following command keeps only lines 3 through 5 and removes everything else:

sed '3,5!d' colors.txt

blue
yellow
white

This is a convenient way to extract a slice from a file without piping through head and tail.

Delete Every Nth Line #

GNU sed supports the step address first~step, which matches every Nth line starting from a given position. To delete every even-numbered line (2, 4, 6, …):

sed '0~2d' colors.txt

red
blue
white
orange

The first number is the starting offset (0 means “before the first line”, so the first match is line 2) and the second number is the step. In this case sed deletes lines 2, 4, 6, and 8.

To delete every third line starting from line 3:

sed '3~3d' colors.txt

red
green
yellow
white
orange
purple

Lines 3 (“blue”) and 6 (“black”) are removed. This syntax is specific to GNU sed and is not available in the BSD version shipped with macOS.

Delete Lines Matching a Pattern #

One of the most common uses of sed delete is removing lines that contain a specific string. Wrap the search pattern in forward slashes before the d command:

sed '/blue/d' colors.txt

red
green
yellow
white
black
orange
purple

Every line containing the string “blue” is removed from the output. Keep in mind that this is a substring match, so a pattern like /bl/d would also delete the line “black” because it contains “bl”.

If you want the match to be case-insensitive, add the I flag after d:

sed '/Blue/Id' colors.txt

This removes lines containing “blue”, “Blue”, “BLUE”, or any other case variation.

Delete Lines Not Matching a Pattern #

Adding ! after the pattern address inverts the match, so sed deletes every line that does not contain the pattern. The following command removes all lines that do not have the letter “e”:

sed '/e/!d' colors.txt

red
green
blue
yellow
white
orange
purple

Only “black” (line 6) was removed because it is the only line without an “e”. This works similarly to grep , but the advantage of sed is that you can combine it with other editing commands in the same expression.

Delete a Range Between Two Patterns #

You can use two patterns separated by a comma to define a range. sed starts deleting at the first line that matches the opening pattern and stops after the first line that matches the closing pattern. The following command removes everything from “green” through “white”:

sed '/green/,/white/d' colors.txt

red
black
orange
purple

Both the “green” and “white” lines are included in the deletion, along with “blue” and “yellow” between them.

You can also mix a line number with a pattern. This deletes from line 1 through the first line that contains “blue”:

sed '1,/blue/d' colors.txt

yellow
white
black
orange
purple

This kind of mixed address is useful when you know where the range starts (a fixed line) but not where it ends.

Delete Empty Lines #

Removing blank lines is one of the most common sed tasks. To delete completely empty lines, use the pattern ^$, which matches lines where the beginning and end have nothing between them:

sed '/^$/d' file.txt

This works well for truly empty lines, but it will not catch lines that contain only spaces or tabs. To remove those as well, use the [[:space:]] character class:

sed '/^[[:space:]]*$/d' file.txt

The * quantifier matches zero or more whitespace characters, so this pattern covers both empty lines and lines that appear blank but contain invisible whitespace.

Delete Lines Matching a Regular Expression #

The pattern between the slashes is a regular expression, so you can use anchors, character classes, and quantifiers for more precise matching.

A common example is stripping comment lines from a configuration file. The ^# pattern matches any line that starts with #:

sed '/^#/d' config.txt

To delete lines that end with a semicolon, anchor the pattern to the end of the line with $:

sed '/;$/d' source.txt

You can also match by line length. The following command deletes lines that are shorter than 5 characters. The \{0,4\} quantifier means “between 0 and 4 of any character”:

sed '/^.\{0,4\}$/d' file.txt

If you find the backslash escaping awkward, use extended regular expressions with the -E flag (or -r on older systems). This lets you write the same expression without escaping the braces:

sed -E '/^.{0,4}$/d' file.txt

Combining Delete with Other Commands #

One of the strengths of sed is that you can chain multiple operations in a single expression. For example, the following command first removes comment lines and then replaces “localhost” with “127.0.0.1” in whatever remains:

sed '/^#/d; s/localhost/127.0.0.1/g' config.txt

The commands are separated by a semicolon and execute left to right. If a line is deleted by an earlier command, the later commands never see it, so the replacement only applies to non-comment lines.

Editing Files In Place #

All of the examples above print the modified text to standard output without changing the original file. When you are satisfied with the result, add the -i flag to apply the changes directly:

sed -i '/^$/d' file.txt

On macOS, the BSD version of sed requires an explicit extension argument even if you do not want a backup. Use sed -i '' '/^$/d' file.txt for in-place editing without creating a backup file.

Quick Reference #

For a printable quick reference, see the sed cheatsheet .

FAQ #

How do I delete a line containing a specific word? Use sed '/word/d' file.txt. This removes any line where “word” appears as a substring. If you want to match the whole word only (so that “keyword” is not affected), use word boundaries: sed '/\bword\b/d' file.txt.

Can I delete lines from multiple files at once? Yes. Pass multiple filenames after the expression: sed -i '/pattern/d' file1.txt file2.txt. To process files recursively, combine sed with find: find . -name "*.log" -exec sed -i '/DEBUG/d' {} +.

What is the difference between sed '/pattern/d' and grep -v 'pattern'? Both remove matching lines from the output. The difference is that sed can combine deletion with other editing commands in the same expression and supports in-place editing with -i. If all you need is simple line filtering, grep -v is shorter to type.

How do I delete a range of lines and save the result? You can either redirect the output to a new file (sed '3,6d' file.txt > cleaned.txt) or edit in place with a backup (sed -i.bak '3,6d' file.txt). Do not redirect to the same input file, because the shell will truncate it before sed has a chance to read it.

Conclusion #

The sed delete command gives you a fast way to remove lines by number, pattern, or range without opening a file in an editor. For replacing text within lines rather than removing them, see the companion guide on sed find and replace . If you need to work with individual columns or fields within a line, awk is often the better tool for the job.

A firewall is a tool for monitoring and filtering incoming and outgoing network traffic. It works by defining a set of security rules that determine whether to allow or block specific traffic.

Ubuntu ships with a firewall configuration tool called UFW (Uncomplicated Firewall). It is a user-friendly front-end for managing iptables firewall rules. Its main goal is to make managing a firewall easier or, as the name says, uncomplicated.

This article describes how to use the UFW tool to configure and manage a firewall on Ubuntu 24.04. A properly configured firewall is one of the most important aspects of overall system security.

Prerequisites #

Only root or users with sudo privileges can manage the system firewall. The best practice is to run administrative tasks as a sudo user.

Install UFW #

UFW is part of the standard Ubuntu 24.04 installation and should be present on your system. If for some reason it is not installed, you can install the package by typing:

sudo apt update
sudo apt install ufw

Check UFW Status #

UFW is disabled by default. You can check the status of the UFW service with the following command:

sudo ufw status verbose

The output will show that the firewall status is inactive:

Status: inactive

If UFW is activated, the output will look something like the following:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

UFW Default Policies #

The default behavior of the UFW firewall is to block all incoming and forwarding traffic and allow all outbound traffic. This means that anyone trying to access your server will not be able to connect unless you specifically open the port. Applications and services running on your server will be able to access the outside world.

The default policies are defined in the /etc/default/ufw file and can be changed either by manually modifying the file or with the sudo ufw default <policy> <chain> command.

Firewall policies are the foundation for building more complex and user-defined rules. Generally, the initial UFW default policies are a good starting point.

Application Profiles #

An application profile is a text file in INI format that describes the service and contains firewall rules for the service. Application profiles are created in the /etc/ufw/applications.d directory during the installation of the package.

You can list all application profiles available on your server by typing:

sudo ufw app list

Depending on the packages installed on your system, the output will look similar to the following:

Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH

To find more information about a specific profile and included rules, use the following command:

sudo ufw app info 'Nginx Full'

The output shows that the ‘Nginx Full’ profile opens ports 80 and 443.

Profile: Nginx Full
Title: Web Server (Nginx, HTTP + HTTPS)
Description: Small, but very powerful and efficient web server
Ports:
80,443/tcp

You can also create custom profiles for your applications.

Enabling UFW #

If you are connecting to your Ubuntu server from a remote location, before enabling the UFW firewall you must explicitly allow incoming SSH connections. Otherwise, you will no longer be able to connect to the machine.

To configure your UFW firewall to allow incoming SSH connections, type the following command:

sudo ufw allow ssh

Rules updated
Rules updated (v6)

If SSH is running on a non-standard port , you need to open that port.

For example, if your ssh daemon listens on port 7722, enter the following command to allow connections on that port:

sudo ufw allow 7722/tcp

Now that the firewall is configured to allow incoming SSH connections, you can enable it by typing:

sudo ufw enable

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

You will be warned that enabling the firewall may disrupt existing ssh connections; type y and hit Enter.

Opening Ports #

Depending on the applications that run on the system, you may also need to open other ports. The general syntax to open a port is as follows:

ufw allow port_number/protocol

Below are a few ways to allow HTTP connections.

The first option is to use the service name. UFW checks the /etc/services file for the port and protocol of the specified service:

sudo ufw allow http

You can also specify the port number and the protocol:

sudo ufw allow 80/tcp

When no protocol is given, UFW creates rules for both tcp and udp.

Another option is to use the application profile; in this case, ‘Nginx HTTP’:

sudo ufw allow 'Nginx HTTP'

UFW also supports another syntax for specifying the protocol using the proto keyword:

sudo ufw allow proto tcp to any port 80

Port Ranges #

UFW also allows you to open port ranges. The start and the end ports are separated by a colon (:), and you must specify the protocol, either tcp or udp.

For example, if you want to allow ports from 7100 to 7200 on both tcp and udp, run the following commands:

sudo ufw allow 7100:7200/tcp
sudo ufw allow 7100:7200/udp

Specific IP Address and Port #

To allow connections on all ports from a given source IP, use the from keyword followed by the source address.

Here is an example of allowlisting an IP address:

sudo ufw allow from 64.63.62.61

If you want to allow the given IP address access only to a specific port, use the to any port keyword followed by the port number.

For example, to allow access on port 22 from a machine with IP address 64.63.62.61, enter:

sudo ufw allow from 64.63.62.61 to any port 22

Subnets #

The syntax for allowing connections to a subnet of IP addresses is the same as when using a single IP address. The only difference is that you need to specify the netmask.

Below is an example showing how to allow access for IP addresses ranging from 192.168.1.1 to 192.168.1.254 to port 3306 (MySQL):

sudo ufw allow from 192.168.1.0/24 to any port 3306

Specific Network Interface #

To allow connections on a particular network interface, use the in on keyword followed by the name of the network interface:

sudo ufw allow in on eth2 to any port 3306

Denying Connections #

The default policy for all incoming connections is set to deny, and if you have not changed it, UFW will block all incoming connections unless you specifically open the connection.

Writing deny rules is the same as writing allow rules; you only need to use the deny keyword instead of allow.

Say you opened ports 80 and 443, and your server is under attack from the 23.24.25.0/24 network. To deny all connections from that network, run:

sudo ufw deny from 23.24.25.0/24

To deny access only to ports 80 and 443 from 23.24.25.0/24, use the following command:

sudo ufw deny proto tcp from 23.24.25.0/24 to any port 80,443

Deleting UFW Rules #

There are two ways to delete UFW rules: by rule number, and by specifying the actual rule.

Deleting rules by rule number is easier, especially when you are new to UFW. To delete a rule by number, first find the number of the rule you want to delete. To get a list of numbered rules, use the ufw status numbered command:

sudo ufw status numbered

Status: active
To Action From
-- ------ ----
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 80/tcp ALLOW IN Anywhere
[ 3] 8080/tcp ALLOW IN Anywhere

To delete rule number 3, the one that allows connections to port 8080, enter:

sudo ufw delete 3

The second method is to delete a rule by specifying the actual rule. For example, if you added a rule to open port 8069 you can delete it with:

sudo ufw delete allow 8069

Disabling UFW #

If you want to stop UFW and deactivate all the rules, use:

sudo ufw disable

To re-enable UFW and activate all rules, type:

sudo ufw enable

Resetting UFW #

Resetting UFW will disable it and delete all active rules. This is helpful if you want to revert all your changes and start fresh.

To reset UFW, run the following command:

sudo ufw reset

IP Masquerading #

IP Masquerading is a variant of NAT (network address translation) in the Linux kernel that translates network traffic by rewriting the source and destination IP addresses and ports. With IP Masquerading, you can allow one or more machines in a private network to communicate with the internet using one Linux machine that acts as a gateway.

Configuring IP Masquerading with UFW involves several steps.

First, you need to enable IP forwarding. To do that, open the /etc/ufw/sysctl.conf file:

sudo nano /etc/ufw/sysctl.conf

Find and uncomment the line which reads net.ipv4.ip_forward=1:

net.ipv4.ip_forward=1

Next, you need to configure UFW to allow forwarded packets. Open the UFW configuration file:

sudo nano /etc/default/ufw

Locate the DEFAULT_FORWARD_POLICY key, and change the value from DROP to ACCEPT:

DEFAULT_FORWARD_POLICY="ACCEPT"

Now you need to set the default policy for the POSTROUTING chain in the nat table and the masquerade rule. To do so, open the /etc/ufw/before.rules file:

sudo nano /etc/ufw/before.rules

Append the following lines:

#NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic through eth0 - Change to public network interface
-A POSTROUTING -s 10.8.0.0/16 -o eth0 -j MASQUERADE

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

Replace eth0 in the -A POSTROUTING line with the name of your public network interface.

When you are done, save and close the file. Finally, reload the UFW rules:

sudo ufw disable
sudo ufw enable

Troubleshooting #

UFW blocks SSH after enabling it
If you enabled UFW without first allowing SSH, you will lose access to a remote server. To recover, you need console access (via your hosting provider’s web console) and run sudo ufw allow ssh followed by sudo ufw enable. Always allow SSH before enabling UFW on a remote machine.

Rules not active after ufw reset
After a reset, UFW is disabled and all rules are cleared. You need to re-add your rules and run sudo ufw enable to bring the firewall back up.

IPv6 rules not created
If ufw status shows rules only for IPv4, check that IPV6=yes is set in /etc/default/ufw, then run sudo ufw disable && sudo ufw enable to reload the configuration.

Application profile not found
If sudo ufw allow 'Nginx Full' returns an error, the profile may not be installed yet. Install the relevant package first (for example, nginx), then retry.

Conclusion #

We have shown you how to install and configure a UFW firewall on your Ubuntu 24.04 server. For a full reference of UFW commands and options, see the UFW man page .

Both apt and apt-get manage packages on Debian-based systems. They talk to the same package database, resolve the same dependencies, and pull from the same repositories. Yet they exist as separate tools, and choosing the wrong one in the wrong context can cause minor headaches.

This guide explains how apt and apt-get differ, when to use each one, and how their commands map to each other.

Why Two Tools Exist #

apt-get has been the standard Debian package manager since 1998. It is reliable and well-documented, but its interface was designed for an era when terminal usability was an afterthought. Related tasks like searching and showing package details live in a separate tool called apt-cache, so users constantly switch between the two.

The apt command was introduced in Debian 8 and Ubuntu 14.04 (APT version 1.0, released in 2014) as a user-friendly front end. It combines the most common apt-get and apt-cache operations into a single command, adds a progress bar, and uses colored output by default.

Both tools are part of the same apt package and share the same underlying libraries. Installing one always installs the other.

User-Facing Differences #

When you run apt install in a terminal, you will notice a few things that apt-get does not do:

• A progress bar at the bottom of the screen shows overall download and install progress.
• Newly installed packages are highlighted in the output.
• The number of upgradable packages is shown after apt update finishes.
• Output is formatted with color when connected to a terminal.

These features make apt more pleasant for interactive use. They also make its output less predictable for scripts, since the formatting can change between APT versions without warning. The apt man page states this explicitly: the command line interface of apt “may change between versions” and “should not be used in scripts.”

apt-get, on the other hand, guarantees a stable output format. Its behavior and exit codes are consistent across versions, which is why automation tools like Ansible, Docker, and CI pipelines use apt-get rather than apt.

Command Comparison #

The table below maps the most common apt commands to their apt-get or apt-cache equivalents:

As you can see, apt merges apt-get and apt-cache into one tool and adds a few convenience commands like apt list and apt edit-sources that have no direct apt-get equivalent.

When to Use apt #

Use apt for everyday interactive work in the terminal. If you are installing a package, checking for updates, or searching the repository by hand, apt is the better choice. The progress bar and cleaner output make it easier to follow what is happening.

For example, to update your package index and upgrade all packages:

sudo apt update && sudo apt upgrade

To search for a package and then install it:

apt search nginx

sudo apt install nginx

When to Use apt-get #

Use apt-get in shell scripts, Dockerfiles, CI pipelines, and any automated workflow. The stable output format means your scripts will not break when the system upgrades to a newer APT version.

A typical Dockerfile uses apt-get with the -y flag to skip confirmation prompts:

RUN apt-get update && apt-get install -y \
 curl \
 git \
 && rm -rf /var/lib/apt/lists/*

The same applies to Bash scripts and configuration management tools. If the command runs without a human watching the output, use apt-get.

Advanced Operations #

The commands below work with both apt and apt-get, but they are better documented and more established under apt-get. In scripts and Dockerfiles, prefer the apt-get form for consistency and stability.

• apt-get install --no-install-recommends pkg — Install a package without pulling in recommended (but not required) dependencies. This is widely used in Docker images to keep the image size small.
• apt-get install --allow-downgrades pkg — Allow installing an older version of a package.
• apt-get build-dep pkg — Install all build dependencies needed to compile a package from source.
• apt-get source pkg — Download the source package.
• apt-get download pkg — Download the .deb file without installing it.
• apt-get changelog pkg — Display the package changelog.
• apt-get clean / apt-get autoclean — Clear the local package cache.

FAQ #

Is apt-get deprecated? No. apt-get is actively maintained and receives updates alongside apt. The APT developers have stated that apt-get will not be removed. It remains the recommended tool for scripts and automation.

Can I replace all apt-get commands with apt? For interactive terminal use, yes. For scripts, no. The apt output format is not guaranteed to remain stable, and its interface may change between versions. Stick with apt-get in any automated workflow.

Is there a performance difference between apt and apt-get? No. Both tools use the same libraries and resolve dependencies the same way. The only difference is the user interface. Install and download speeds are identical.

What about apt-cache? Is it still needed? For interactive use, apt search and apt show replace the most common apt-cache operations. For scripts or when you need advanced query options like apt-cache policy or apt-cache depends, you should still use apt-cache directly.

Conclusion #

Use apt when you are typing commands at a terminal, and apt-get when you are writing scripts or Dockerfiles. For a complete reference of apt subcommands, see the apt Command in Linux guide and the APT cheatsheet .

git clone copies an existing Git repository into a new directory on your local machine. It sets up tracking branches for each remote branch and creates a remote called origin pointing back to the source.

This guide explains how to use git clone with the most common options and protocols.

Syntax #

The basic syntax of the git clone command is:

git clone [OPTIONS] REPOSITORY [DIRECTORY]

REPOSITORY is the URL or path of the repository to clone. DIRECTORY is optional; if omitted, Git uses the repository name as the directory name.

Clone a Remote Repository #

The most common way to clone a repository is over HTTPS. For example, to clone a GitHub repository:

git clone https://github.com/user/repo.git

This creates a repo directory in the current working directory, initializes a .git directory inside it, and checks out the default branch.

You can also clone over SSH if you have an SSH key configured :

git clone git@github.com:user/repo.git

SSH is generally preferred for repositories you will push to, as it does not require entering credentials each time.

Clone into a Specific Directory #

By default, git clone creates a directory named after the repository. To clone into a different directory, pass the target path as the second argument:

git clone https://github.com/user/repo.git my-project

To clone into the current directory, use . as the target:

git clone https://github.com/user/repo.git .

Clone a Specific Branch #

By default, git clone checks out the default branch (usually main or master). To clone and check out a different branch, use the -b option:

git clone -b develop https://github.com/user/repo.git

The full repository history is still downloaded; only the checked-out branch differs. To limit the download to a single branch, combine -b with --single-branch:

git clone -b develop --single-branch https://github.com/user/repo.git

Shallow Clone #

A shallow clone downloads only a limited number of recent commits rather than the full history. This is useful for speeding up the clone of large repositories when you do not need the full commit history.

To clone with only the latest commit:

git clone --depth 1 https://github.com/user/repo.git

To include the last 10 commits:

git clone --depth 10 https://github.com/user/repo.git

Shallow clones are commonly used in CI/CD pipelines to reduce download time. To convert a shallow clone to a full clone later, run:

git fetch --unshallow

Clone a Local Repository #

git clone also works with local paths. This is useful for creating an isolated copy for testing:

git clone /path/to/local/repo new-copy

Troubleshooting #

Destination directory is not empty
git clone URL . works only when the current directory is empty. If files already exist, clone into a new directory or move the existing files out of the way first.

Authentication failed over HTTPS
Most Git hosting services no longer accept account passwords for Git operations over HTTPS. Use a personal access token or configure a credential manager so Git can authenticate securely.

Permission denied (publickey)
This error usually means your SSH key is missing, not loaded into your SSH agent, or not added to your account on the Git hosting service. Verify your SSH setup before retrying the clone.

Host key verification failed
SSH could not verify the identity of the remote server. Confirm you are connecting to the correct host, then accept or update the host key in ~/.ssh/known_hosts.

Quick Reference #

For a printable quick reference, see the Git cheatsheet .

FAQ #

What is the difference between HTTPS and SSH cloning?
HTTPS cloning works out of the box but prompts for credentials unless you use a credential manager. SSH cloning requires a key pair to be configured but does not prompt for a password on each push or pull.

Does git clone download all branches?
Yes. All remote branches are fetched, but only the default branch is checked out locally. Use git branch -r to list all remote branches, or git checkout branch-name to switch to one.

How do I clone a private repository?
For HTTPS, provide your username and a personal access token when prompted. For SSH, ensure your public key is added to your account on the hosting service.

Can I clone a specific tag instead of a branch?
Yes. Use -b with the tag name: git clone -b v1.0.0 https://github.com/user/repo.git. Git checks out that tag in a detached HEAD state, so create a branch if you plan to make commits.

Conclusion #

git clone is the starting point for working with any existing Git repository. After cloning, you can inspect the commit history with git log , review changes with git diff , and configure your username and email if you have not done so already.

The jobs command is a Bash built-in that lists all background and suspended processes associated with the current shell session. It shows the job ID, state, and the command that started each job.

This article explains how to use the jobs command, what each option does, and how job specifications work for targeting individual jobs.

Syntax #

The general syntax for the jobs command is:

jobs [OPTIONS] [JOB_SPEC...]

When called without arguments, jobs lists all active jobs in the current shell.

Listing Jobs #

To see all background and suspended jobs, run jobs without any arguments:

jobs

If you have two processes (one running and one stopped), the output will look similar to this:

[1]- Stopped vim notes.txt
[2]+ Running ping google.com &

Each line shows:

• The job number in brackets ([1], [2])
• A + or - sign indicating the current and previous job (more on this below)
• The job state (Running, Stopped, Done)
• The command that started the job

To include the process ID (PID) in the output, use the -l option:

jobs -l

[1]- 14205 Stopped vim notes.txt
[2]+ 14230 Running ping google.com &

The PID is useful when you need to send a signal to a process with the kill command.

Job States #

Jobs reported by the jobs command can be in one of these states:

• Running — the process is actively executing in the background.
• Stopped — the process has been suspended, typically by pressing Ctrl+Z.
• Done — the process has finished. This state appears once and is then cleared from the list.
• Terminated — the process was killed by a signal.

When a background job finishes, the shell displays its Done status the next time you press Enter or run a command.

Job Specifications #

Job specifications (job specs) let you target a specific job when using commands like fg, bg, kill , or disown. They always start with a percent sign (%):

• %1, %2, … — refer to a job by its number.
• %% or %+ — the current job (the most recently backgrounded or suspended job, marked with +).
• %- — the previous job (marked with -).
• %string — the job whose command starts with string. For example, %ping matches a job started with ping google.com.
• %?string — the job whose command contains string anywhere. For example, %?google also matches ping google.com.

Here is a practical example. Start two background jobs:

sleep 300 &
ping -c 100 google.com > /dev/null &

Now list them:

jobs

[1]- Running sleep 300 &
[2]+ Running ping -c 100 google.com > /dev/null &

You can bring the sleep job to the foreground by its number:

fg %1

Or by the command prefix:

fg %sleep

Both are equivalent and bring job [1] to the foreground.

Options #

The jobs command accepts the following options:

• -l — List jobs with their process IDs in addition to the normal output.
• -p — Print only the PID of each job’s process group leader. This is useful for scripting.
• -r — List only running jobs.
• -s — List only stopped (suspended) jobs.
• -n — Show only jobs whose status has changed since the last notification.

To show only running jobs:

jobs -r

To get just the PIDs of all jobs:

jobs -p

14205
14230

Using jobs in Interactive Shells #

The jobs command is primarily useful in an interactive shell where job control is enabled. In a regular shell script, job control is usually off, so jobs may return no output even when background processes exist.

If you need to manage background work in a script, track process IDs with $! and use wait with the PID instead of a job spec:

# Start a background task
long_task &
task_pid=$!

# Poll until it finishes
while kill -0 "$task_pid" 2>/dev/null; do
 echo "Task is still running..."
 sleep 5
done

echo "Task complete."

To wait for several background tasks, store their PIDs and pass them to wait:

task_a &
pid_a=$!

task_b &
pid_b=$!

task_c &
pid_c=$!

wait "$pid_a" "$pid_b" "$pid_c"
echo "All tasks complete."

In an interactive shell, you can still wait for a job by its job spec:

wait %1

Quick Reference #

FAQ #

What is the difference between jobs and ps?
jobs shows only the processes started from the current shell session. The ps command lists all processes running on the system, regardless of which shell started them.

Why does jobs show nothing even though processes are running?
jobs only tracks processes started from the current shell. If you started a process in a different terminal or via a system service, it will not appear in jobs. Use ps aux to find it instead.

How do I stop a background job?
Use kill %N where N is the job number. For example, kill %1 sends SIGTERM to job 1. If the job does not stop, use kill -9 %1 to force-terminate it.

What do the + and - signs mean in jobs output?
The + marks the current job, the one that fg and bg will act on by default. The - marks the previous job. When the current job finishes, the previous job becomes the new current job.

How do I keep a background job running after closing the terminal?
Use nohup before the command, or disown after backgrounding it. For long-running interactive sessions, consider Screen or Tmux .

Conclusion #

The jobs command lists all background and suspended processes in the current shell session. Use it together with fg, bg, and kill to control jobs interactively. For a broader guide on running and managing background processes, see How to Run Linux Commands in the Background .

Docker Compose is a tool for defining and running multi-container applications. Instead of starting each container separately with docker run , you describe all of your services, networks, and volumes in a single YAML file and bring the entire environment up with one command.

This guide explains how Docker Compose V2 works, walks through a practical example with a SvelteKit development server and PostgreSQL database, and covers the most commonly used Compose directives and commands.

Quick Reference #

For a printable quick reference, see the Docker cheatsheet .

Prerequisites #

The examples in this guide require Docker with the Compose plugin installed. Docker Desktop includes Compose by default. On Linux, install the docker-compose-plugin package alongside Docker Engine.

To verify Compose is available, run:

docker compose version

Docker Compose version v2.x.x

Compose V2 runs as docker compose (with a space), not docker-compose. The old V1 binary is end-of-life and not covered in this guide.

The Compose File #

Modern Docker Compose prefers a file named compose.yaml, though docker-compose.yml is still supported for compatibility. In this guide, we will use docker-compose.yml because many readers still recognize that name first.

A Compose file describes your application’s environment using three top-level keys:

• services — defines each container: its image, ports, volumes, environment variables, and dependencies
• volumes — declares named volumes that persist data across container restarts
• networks — defines custom networks for service communication (Compose creates a default network automatically)

Compose V2 does not require a version: field at the top of the file. If you see version: '3' in older guides, that is legacy syntax kept for backward compatibility, not something new Compose files need.

YAML uses indentation to define structure. Use spaces, not tabs.

Setting Up the Example #

In this example, we will run a SvelteKit development server alongside a PostgreSQL 16 database using Docker Compose.

Start by creating a new SvelteKit project. The npm create command launches an interactive wizard — select “Skeleton project” when prompted, then choose your preferred options for TypeScript and linting:

npm create svelte@latest myapp
cd myapp

If you already have a Node.js project, skip this step and use your project directory instead.

Next, create a docker-compose.yml file in the project root:

services:
 app:
 image: node:20-alpine
 working_dir: /app
 volumes:
 - .:/app
 - node_modules:/app/node_modules
 ports:
 - "5173:5173"
 environment:
 DATABASE_URL: postgresql://postgres:${POSTGRES_PASSWORD}@db:5432/myapp
 depends_on:
 db:
 condition: service_healthy
 command: sh -c "npm install && npm run dev -- --host"

 db:
 image: postgres:16-alpine
 volumes:
 - postgres_data:/var/lib/postgresql/data
 environment:
 POSTGRES_USER: postgres
 POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
 POSTGRES_DB: myapp
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U postgres"]
 interval: 5s
 timeout: 5s
 retries: 5

volumes:
 postgres_data:
 node_modules:

Compose V2 automatically reads a .env file in the project directory and substitutes ${VAR} references in the compose file. Create a .env file to define the database password:

POSTGRES_PASSWORD=changeme

The password above is for local development only. We will walk through each directive in the compose file in the next section.

Understanding the Compose File #

Let us go through each directive in the compose file.

services #

The services key is the core of any compose file. Each entry under services defines one container. The key name (app, db) becomes the service name, and Compose also uses it as the hostname for inter-service communication — so the app container can reach the database at db:5432.

image #

The image directive tells Compose which Docker image to pull. Both node:20-alpine and postgres:16-alpine are pulled from Docker Hub if they are not already present on your machine. The alpine variant uses Alpine Linux as a base, which keeps image sizes small.

working_dir #

The working_dir directive sets the working directory inside the container. All commands run in /app, which is where we mount the project files.

volumes #

The app service uses two volume entries:

- .:/app
- node_modules:/app/node_modules

The first entry is a bind mount. It maps the current directory on your host (.) to /app inside the container. Any file you edit on your host is immediately reflected inside the container, which is what enables hot-reload during development.

The second entry is a named volume. Without it, the bind mount would overwrite /app/node_modules with whatever is in your host directory — which may be empty or incompatible. The node_modules named volume tells Docker to keep a separate copy of node_modules inside the container so the bind mount does not interfere with it.

The db service uses a named volume for its data directory:

- postgres_data:/var/lib/postgresql/data

This ensures that your database data persists across container restarts. When you run docker compose down, the postgres_data volume is kept. Only docker compose down -v removes it.

Named volumes must be declared at the top level under volumes:. Both postgres_data and node_modules are listed there with no additional configuration, which tells Docker to manage them using its default storage driver.

ports #

The ports directive maps ports between the host machine and the container in "HOST:CONTAINER" format. The entry "5173:5173" exposes the Vite development server so you can open http://localhost:5173 in your browser.

environment #

The environment directive sets environment variables inside the container. The app service receives the DATABASE_URL connection string, which a SvelteKit application can read to connect to the database.

Notice the ${POSTGRES_PASSWORD} syntax. Compose reads this value from the .env file and substitutes it before starting the container. This keeps credentials out of the compose file itself.

depends_on #

By default, depends_on only controls the order in which containers start — it does not wait for a service to be ready. Compose V2 supports a long-form syntax with a condition key that changes this behavior:

depends_on:
 db:
 condition: service_healthy

With condition: service_healthy, Compose waits until the db service passes its healthcheck before starting app. This prevents the Node.js process from trying to connect to PostgreSQL before the database is accepting connections.

command #

The command directive overrides the default command defined in the image. Here it runs npm install to install dependencies, then starts the Vite dev server with --host to bind to 0.0.0.0 inside the container (required for Docker to forward the port to your host):

sh -c "npm install && npm run dev -- --host"

Running npm install on every container start is slow but convenient for development — you do not need to install dependencies manually before running docker compose up. For production, use a multi-stage Dockerfile to pre-install dependencies and build the application.

healthcheck #

The healthcheck directive defines a command Compose runs inside the container to determine whether the service is ready. The pg_isready utility checks whether PostgreSQL is accepting connections:

test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 5s
retries: 5

Compose runs this check every 5 seconds. Once the service passes its first check, it is marked as healthy and any services using condition: service_healthy are allowed to start. If the check fails 5 consecutive times, the service is marked as unhealthy.

Managing the Application #

Run all commands from the project directory — the directory where your docker-compose.yml is located.

Starting Services #

To start all services and stream their logs to your terminal, run:

docker compose up

Compose pulls any missing images, creates the network, starts the db container, waits for it to pass its healthcheck, then starts the app container. Press Ctrl+C to stop.

To start in detached mode and run the services in the background:

docker compose up -d

Viewing Status and Logs #

To list running services and their current state:

docker compose ps

NAME IMAGE COMMAND SERVICE STATUS PORTS
myapp-app-1 node:20-alpine "docker-entrypoint.s…" app Up 2 minutes 0.0.0.0:5173->5173/tcp
myapp-db-1 postgres:16-alpine "docker-entrypoint.s…" db Up 2 minutes 5432/tcp

To view the logs for a specific service:

docker compose logs app

To follow the logs in real time (like tail -f):

docker compose logs -f app

Press Ctrl+C to stop following.

Running Commands Inside a Container #

To open an interactive shell inside the running app container:

docker compose exec app sh

This is useful for running one-off commands, inspecting the file system, or debugging. Type exit to leave the shell.

Stopping and Removing Services #

To stop running containers without removing them — preserving named volumes and the network:

docker compose stop

To start them again after stopping:

docker compose start

To stop containers and remove them along with the network:

docker compose down

Named volumes (postgres_data, node_modules) are preserved. Your database data is safe.

To also remove all named volumes — this deletes your database data:

docker compose down -v

Use this when you want a completely clean environment.

Common Directives Reference #

The following directives are not used in the example above but are commonly needed in real projects.

restart #

The restart directive controls what Compose does when a container exits:

services:
 app:
 restart: unless-stopped

The available policies are:

• no — do not restart (default)
• always — always restart, including on system reboot
• unless-stopped — restart unless the container was explicitly stopped
• on-failure — restart only when the container exits with a non-zero status

Use unless-stopped for long-running services in single-host deployments.

build #

Instead of pulling a pre-built image, build tells Compose to build the image from a local Dockerfile :

services:
 app:
 build:
 context: .
 dockerfile: Dockerfile

context is the directory Compose sends to the Docker daemon as the build context. dockerfile specifies the Dockerfile path relative to context. If both the image and a build context exist, build takes precedence.

env_file #

The env_file directive injects environment variables into a container from a file at runtime:

services:
 app:
 env_file:
 - .env.local

This is different from Compose’s native .env substitution. The .env file at the project root is read by Compose itself to substitute ${VAR} references in the compose file. The env_file directive injects variables directly into the container’s environment. Both can be used together.

networks #

Compose creates a default bridge network connecting all services automatically. You can define custom networks to isolate groups of services or control how containers communicate:

services:
 app:
 networks:
 - frontend
 - backend
 db:
 networks:
 - backend

networks:
 frontend:
 backend:

A service only communicates with other services on the same network. In this example, app can reach db because both share the backend network. A service attached only to frontend — not backend — has no route to db.

profiles #

Profiles let you define optional services that only start when explicitly requested. This is useful for development tools, debuggers, or admin interfaces that you do not want running all the time:

services:
 app:
 image: node:20-alpine

 adminer:
 image: adminer
 profiles:
 - tools
 ports:
 - "8080:8080"

Running docker compose up starts only app. To also start adminer, pass the profile flag:

docker compose --profile tools up

Troubleshooting #

Port is already in use
Another process on your host is using the same port. Change the host-side port in the ports: mapping. For example, change "5173:5173" to "5174:5173" to expose the container on port 5174 instead.

Service cannot connect to the database
If you are not using condition: service_healthy, depends_on only ensures the db container starts before app — it does not wait for PostgreSQL to be ready to accept connections. Add a healthcheck to the db service and set condition: service_healthy in depends_on as shown in the example above.

node_modules is empty inside the container
The bind mount .:/app maps your host directory to /app, which overwrites /app/node_modules with whatever is on your host. If your host directory has no node_modules, the container sees none either. Fix this by adding a named volume entry node_modules:/app/node_modules as shown in the example. Docker preserves the named volume’s contents and the bind mount does not overwrite it.

FAQ #

What is the difference between docker compose down and docker compose stop?
docker compose stop stops the running containers but leaves them on disk along with the network and volumes. You can restart them with docker compose start. docker compose down removes the containers and the network. Named volumes are kept unless you add the -v flag.

How do I view logs for a specific service?
Run docker compose logs SERVICE, replacing SERVICE with the service name defined in your compose file (for example, docker compose logs app). To follow logs in real time, add the -f flag: docker compose logs -f app.

How do I pass secrets without hardcoding them in the Compose file?
Create a .env file in the project directory with your credentials (for example, POSTGRES_PASSWORD=changeme) and reference them in the compose file using ${VAR} syntax. Compose reads the .env file automatically. Add .env to your .gitignore so credentials are never committed to version control.

Can I use Docker Compose in production?
Compose works well for single-host deployments — it is simpler to operate than Kubernetes when you only have one server. Use restart: unless-stopped to keep services running after reboots, and keep secrets in environment variables rather than hardcoded values. For multi-host deployments, look at Docker Swarm or Kubernetes.

What is the difference between a bind mount and a named volume?
A bind mount (./host-path:/container-path) maps a specific directory from your host into the container. Changes on either side are immediately visible on the other. A named volume (volume-name:/container-path) is managed entirely by Docker — it persists data independently of the host directory structure and is not tied to a specific path on your machine. Use bind mounts for source code (so edits take effect immediately) and named volumes for database data (so it persists reliably).

Conclusion #

Docker Compose gives you a straightforward way to define and run multi-container development environments with a single YAML file. Once you are comfortable with the basics, the next step is writing custom Dockerfiles to build your own images instead of relying on generic ones.

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}"
)