Fusion Labs

Git is one of the most important tools for developers and DevOps engineers. It records changes made to source code, configuration files and infrastructure, allowing teams to collaborate without accidentally overwriting one another’s work.

GitHub is an online platform that stores Git repositories and adds collaboration features such as pull requests, issue tracking, code reviews and automated workflows.

This guide explains the Git and GitHub fundamentals every DevOps beginner should understand.

If you are building your DevOps skills step by step, first explore our complete DevOps roadmap for beginners and Linux fundamentals for DevOps.

What Is Version Control?

Version control is a system for recording changes made to files over time.

Without version control, developers may create files such as:

project-final.zip
project-final-new.zip
project-final-corrected.zip
project-final-really-corrected.zip

This approach becomes confusing and makes collaboration difficult.

Git provides a structured history. It allows you to:

• Track every important change.
• See who changed a file.
• Compare different versions.
• Restore an earlier version.
• Work on multiple features separately.
• Collaborate with other team members.
• Review changes before adding them to production.

Git is a distributed version-control system. Each developer normally has a complete local copy of the repository and its history.

Git Versus GitHub

Git and GitHub are related, but they are not the same.

Git is the version-control software installed on your computer.

GitHub is an online service for hosting Git repositories and supporting team collaboration.

You can use Git without GitHub. You can also host Git repositories on platforms such as GitLab, Bitbucket or your own server.

A typical workflow is:

1. Create or clone a repository.
2. Modify files locally.
3. Stage the required changes.
4. Create a commit.
5. Push the commit to GitHub.
6. Open a pull request.
7. Review and merge the changes.

Why DevOps Engineers Use Git

DevOps engineers use Git for much more than application source code.

Git can manage:

• Dockerfiles
• Docker Compose files
• Kubernetes manifests
• Terraform configuration
• Ansible playbooks
• CI/CD pipeline files
• Shell scripts
• Monitoring configurations
• Nginx configurations
• Technical documentation

Keeping infrastructure and deployment configurations in Git makes changes reviewable, repeatable and easier to audit.

However, secrets such as passwords, access keys and private certificates should never be committed to a repository.

Installing Git

On Ubuntu or Debian, install Git using:

sudo apt update
sudo apt install git

Check the installed version:

git --version

On Fedora or similar systems, use:

sudo dnf install git

Windows and macOS users can download Git from the official Git website or install it through an appropriate package manager.

Configure Your Git Identity

Before creating commits, configure your name and email address:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Check the configuration:

git config --global --list

Git includes this identity in your commits. If you use GitHub, you can use an email associated with your GitHub account or GitHub’s private no-reply email.

Create Your First Repository

Create a project directory:

mkdir devops-git-project
cd devops-git-project

Initialize a Git repository:

git init

Create a file:

touch README.md

Check the repository status:

git status

The git status command shows modified, staged and untracked files. It is one of the most useful commands to run before committing changes.

Understanding the Git Workflow

A basic Git workflow contains three important areas:

1. Working directory: The files you are currently editing.
2. Staging area: The changes selected for the next commit.
3. Repository: The committed project history.

After modifying a file, add it to the staging area:

git add README.md

Stage all relevant changes in the current directory:

git add .

Create a commit:

git commit -m "Add initial project documentation"

A commit is a recorded snapshot of the staged changes.

Use clear commit messages that explain what changed. Avoid unclear messages such as:

update
changes
fixed stuff

Better examples include:

Add Docker configuration for backend
Fix production database migration command
Configure Nginx reverse proxy

View the Commit History

Display the complete commit history:

git log

Display a shorter history:

git log --oneline

Show the changes included in a particular commit:

git show <commit-id>

Compare unstaged changes:

git diff

Compare staged changes:

git diff --staged

Reviewing your differences before committing helps prevent accidental changes from entering the repository.

Working with Branches

A branch provides an independent line of development. It allows you to work on a feature without immediately changing the main version of the project.

Create and switch to a new branch:

git switch -c feature/add-docker

List the available branches:

git branch

Switch back to the main branch:

git switch main

Merge the feature branch into the current branch:

git merge feature/add-docker

Delete the local feature branch after merging:

git branch -d feature/add-docker

Useful branch names include:

feature/add-docker
fix/deployment-script
docs/update-readme
chore/upgrade-dependencies

Branches should normally focus on one feature, fix or related group of changes.

Connecting a Repository to GitHub

Create an empty repository on GitHub without adding another README if your local project already contains one.

Connect the local repository:

git remote add origin https://github.com/username/repository.git

Check the configured remote:

git remote -v

Rename the current branch to main if required:

git branch -M main

Push it to GitHub:

git push -u origin main

The -u option connects your local branch to the remote branch. Future pushes can normally use:

git push

For private repositories, authenticate using an SSH key, personal access token or another method supported by GitHub. Do not use your GitHub account password as a Git password.

Cloning an Existing Repository

To download an existing repository:

git clone https://github.com/username/repository.git

Enter the downloaded directory:

cd repository

A clone includes the project files, Git history and remote configuration.

Fetching and Pulling Changes

Download remote information without modifying your working branch:

git fetch

Download remote commits and integrate them into the current branch:

git pull

git fetch allows you to inspect remote changes before integrating them. git pull performs the download and integration together.

Before beginning new work on a shared branch, update your local repository:

git switch main
git pull

Then create a new feature branch from the updated main branch.

What Is a Pull Request?

A pull request asks the team to review and merge changes from one branch into another.

A common GitHub workflow is:

1. Update your local main branch.
2. Create a feature branch.
3. Make the required changes.
4. Commit the changes.
5. Push the feature branch.
6. Open a pull request on GitHub.
7. Request a code review.
8. Address review comments.
9. Merge the pull request.
10. Delete the completed branch.

Push a new branch to GitHub:

git push -u origin feature/add-docker

A good pull request should explain:

• What was changed.
• Why the change was required.
• How the change was tested.
• Any risks or deployment requirements.
• Screenshots or logs when relevant.

Resolving Merge Conflicts

A merge conflict happens when Git cannot automatically combine overlapping changes.

A conflicted file may contain markers such as:

<<<<<<< HEAD
Current branch content
=======
Incoming branch content
>>>>>>> feature-branch

To resolve the conflict:

1. Open the conflicted file.
2. Decide which content should remain.
3. Remove all conflict markers.
4. Test the corrected file.
5. Stage it.
6. Complete the commit or merge.

Example:

git status
git add corrected-file.txt
git commit

Do not randomly delete conflict markers without understanding both versions of the code.

Ignoring Files with .gitignore

The .gitignore file tells Git which untracked files should not be included in the repository.

A Node.js project may contain:

node_modules/
.env
dist/
coverage/
*.log

A Terraform project may include:

.terraform/
*.tfstate
*.tfstate.*

Do not commit:

• .env files containing secrets.
• Private keys.
• Cloud access credentials.
• Database passwords.
• Generated dependencies such as node_modules.
• Local editor and operating-system files.
• Terraform state containing sensitive information.

Adding a file to .gitignore does not automatically stop tracking it if it has already been committed.

Undoing Changes Safely

Git provides different commands for different types of mistakes.

Restore an unstaged file to its last committed version:

git restore filename

Remove a file from the staging area while retaining its changes:

git restore --staged filename

Create a new commit that reverses an earlier commit:

git revert <commit-id>

git revert is usually safer for shared branches because it preserves the existing history.

Commands such as git reset --hard can permanently discard uncommitted work. Confirm the exact consequences before using destructive Git commands.

Git Tags and Releases

Tags identify important points in project history, such as software releases.

Create a version tag:

git tag -a v1.0.0 -m "Release version 1.0.0"

Push the tag to GitHub:

git push origin v1.0.0

List tags:

git tag

DevOps teams can use tags to trigger release pipelines, build container images or deploy a particular application version.

GitHub Actions and CI/CD

GitHub Actions can run automated workflows whenever selected repository events occur.

For example, a workflow may run when:

• Code is pushed.
• A pull request is opened.
• A version tag is created.
• A scheduled time is reached.
• A workflow is manually started.

A CI/CD workflow can:

1. Install project dependencies.
2. Run formatting and linting checks.
3. Run automated tests.
4. Build the application.
5. Build a Docker image.
6. Scan the image for vulnerabilities.
7. Push the image to a registry.
8. Deploy the application.

Workflow files are normally stored inside:

.github/workflows/

Store sensitive values in GitHub Actions secrets instead of writing them directly in workflow files.

Recommended Git Workflow for DevOps Teams

A simple team workflow can use:

• main for stable production-ready code.
• Short-lived feature and fix branches.
• Pull requests for reviewing changes.
• Automated tests before merging.
• Protected branches to prevent unsafe direct pushes.
• Tags for identifying releases.

The basic sequence is:

git switch main
git pull
git switch -c feature/update-pipeline

# Make and test the changes

git status
git add .
git commit -m "Update deployment pipeline"
git push -u origin feature/update-pipeline

After pushing, open a pull request on GitHub and request a review.

The exact branching strategy should match the team’s release process. A small team may not need a complicated collection of long-lived branches.

Git Security Best Practices

Follow these practices when using Git in DevOps projects:

• Never commit passwords or access keys.
• Use a secret manager or protected CI/CD secrets.
• Enable multifactor authentication on GitHub.
• Protect important branches.
• Require pull-request reviews.
• Review changes before committing.
• Use the minimum required repository permissions.
• Rotate any secret accidentally exposed in Git.
• Keep third-party actions and dependencies reviewed and updated.
• Avoid executing untrusted scripts without inspection.

Deleting an exposed secret from the latest file is not enough. The secret may still exist in repository history, logs or existing clones. Revoke or rotate it immediately.

Practical Git and GitHub Project

Create a repository for a small web application and complete these tasks:

1. Initialize the Git repository.
2. Add a useful README.md.
3. Create an appropriate .gitignore.
4. Commit the initial files.
5. Push the project to GitHub.
6. Create a branch for Docker support.
7. Add a Dockerfile on that branch.
8. Push the branch.
9. Open a pull request.
10. Review and merge the pull request.
11. Add a GitHub Actions workflow that runs a basic test.
12. Create and push a release tag.

Document each step in the README. This project demonstrates version control, branching, collaboration and basic CI/CD knowledge.

Common Git Mistakes to Avoid

Beginners should avoid:

• Adding every file without reviewing git status.
• Committing passwords or .env files.
• Working directly on the main branch for every change.
• Using unclear commit messages.
• Combining unrelated changes in one commit.
• Force-pushing without understanding its impact.
• Using destructive reset commands carelessly.
• Ignoring merge conflicts instead of resolving them properly.
• Creating a complicated branch strategy for a small project.
• Pushing untested changes.

Frequent small commits with clear messages are generally easier to understand and review than large, unrelated commits.

Frequently Asked Questions

Is Git required for DevOps?

Git is essential in most modern DevOps environments because application code, infrastructure definitions, deployment scripts and CI/CD configurations are commonly stored in Git repositories.

Is GitHub the only platform for Git?

No. Git repositories can also be hosted on GitLab, Bitbucket, Azure DevOps or private Git servers.

Should beginners learn Git commands or use a graphical interface?

A graphical interface can be convenient, but learning the main command-line operations helps you understand Git and use it on remote Linux servers and inside automation workflows.

What should I learn after Git?

After Linux and Git, continue with networking fundamentals, Docker and CI/CD. These skills will prepare you for cloud computing, Terraform and Kubernetes.

Conclusion

Git gives DevOps teams a reliable way to manage application code, infrastructure and automation configurations. GitHub adds collaboration, pull requests, reviews and automated workflows.

Begin with repositories, staging, commits and branches. Then practise merging, resolving conflicts, working with remotes and opening pull requests.

The best way to understand Git is to use it throughout a real project. Make regular commits, create feature branches and review the project history whenever you make changes.

Continue learning through our DevOps, Linux and technology guides.