Linux and Git Skills Every DevOps Beginner Needs

A DevOps beginner needs enough Linux to move around a server, read file permissions, find a running process and read its log. They also need enough Git to make small commits, use branches and resolve a merge conflict. Learn both inside a disposable project, so you can see the effect of every command and recover safely.

How do I start?

1. Get a Linux environment: Ubuntu in a virtual machine, or WSL if you use Windows. Do not practise on a machine that holds work you cannot lose. 2. Create a folder such as practice/greeter and write a tiny program in any language that prints a greeting and reads one setting, for example a port number, from an environment variable. 3. Run git init, add a README, and make your first commit. 4. Run the program, then break it on purpose by unsetting the variable. Read what the error says before you change anything.

Keep this project for the whole guide. Every section below uses it.

A worked example: the app that will not start

Your greeter fails with a message about the port. Work through it in order instead of guessing.

• Read the last lines of the output. Does it say the address is already in use, or that a setting is missing?
• List listening ports and find which process holds the one you wanted. If it is another copy of your own app, stop that process.
• Check that the file holding your settings exists and that your user can read it.
• Fix the one thing the evidence points to, run again, then commit the fix with a message that says what was wrong.

Afterwards run git log and read your history. A reviewer should be able to see what broke and why from the commit message alone.

Files and permissions

Practise locating files, reading configuration and distinguishing relative from absolute paths. Understand who owns a file and who can read, write or execute it.

Before changing permissions, identify the exact target and why the application needs access. Making everything writable may hide the immediate problem while creating a larger one.

Processes and logs

Start a small application and identify its process and listening port. Inspect its output when it starts successfully and when configuration is missing.

Learn to narrow a failure using evidence. “The server is down” might mean the process stopped, the port differs or the request is reaching another service.

Git history and diffs

Create a repository with a short README and a simple program. Make one meaningful change per commit during practice. Read the diff before recording it.

A branch lets you develop changes separately; it is not a backup of secrets or a permission boundary. Keep credentials out of the repository from the start.

Collaboration exercise

Make two branches that edit the same sentence differently, then merge them in the disposable repository. Inspect the conflict and resolve it according to the intended content.

Do not choose one side blindly. Explain why your final version is correct and run the relevant check afterward.

Practical checklist

• Locate the application's configuration without printing secrets.
• Identify its process and port.
• Read a focused log excerpt.
• Explain a diff and the purpose of a branch.
• Resolve a small conflict intentionally.
• Reproduce the setup in a clean directory.

Avoid destructive commands aimed at broad directories. When learning unfamiliar commands, read their documentation and use an isolated exercise.

Your portfolio can include a setup guide and a short troubleshooting record. Show what you observed and how it changed your next step, rather than presenting a transcript of commands without reasoning.

What are the common mistakes?

• Running everything as the administrator account, or setting a file to be writable by everyone, so that a permission error disappears. The error was information, and you removed it.
• Copying commands from a tutorial without knowing what they do.
• Committing a settings file that contains a password or token. Add it to .gitignore before the first commit.
• Making one huge commit at the end of the day, which nobody can review.
• Rewriting shared history on a branch other people use.

How do I check I got it?

Delete your working folder, clone your repository into a clean directory and follow only your own README. If you cannot get the app running, your documentation is missing a step. Then explain, without notes, what a process is, how you found its port and why two branches editing one line produce a conflict. If you can do that aloud, you have the foundation.

What should I build next?

Move on to packaging and automation with Docker and CI/CD through one application. The DevOps roadmap shows where this stage fits in the larger sequence, and the DevOps track explains how mentor-led practice is organised for this field.

Sources & further reading

• Docker getting started
• GitHub Actions concepts

Examples and practice recommendations are educational illustrations. Tool documentation and programme inclusions should be checked for your intended use.