Git and GitHub Workflow: The Ultimate Guide for DevOps Beginners

Git and GitHub play an important role in modern software development and DevOps workflows. They help development teams track source-code changes, collaborate efficiently, review code, manage application versions, and integrate development activities with CI/CD automation.

In a typical DevOps environment, Git is used for version control, while GitHub provides a remote platform for hosting repositories and collaborating with other developers. When GitHub is integrated with Jenkins, code changes can automatically trigger build, testing, code-quality analysis, and deployment processes.

1. What Is Git?

Git is a distributed version control system that records changes made to source code over time. It allows developers to maintain different versions of an application, work on separate branches, compare modifications, and collaborate without unnecessarily interfering with each other's work.

Git also maintains a history of committed changes, making it easier to investigate previous versions of files and recover from certain development mistakes.

2. What Is GitHub?

GitHub is a platform that hosts Git repositories and provides collaboration features such as Pull Requests, code reviews, branch protection, issue tracking, and repository management.

In a team environment, developers generally maintain local Git repositories and synchronize their changes with a shared GitHub repository. This provides a central location where source code can be reviewed, managed, and prepared for release.

3. Understanding the Git and GitHub Workflow

A common Git and GitHub workflow begins when a developer creates a feature branch from the development branch. The developer implements the required changes, commits the code, and pushes the feature branch to GitHub.

For example, if a developer is implementing a login feature, the following commands can be used:

Git Commands:

git checkout -b feature/login
git add .
git commit -m "Add login functionality"
git push origin feature/login

Here is what each command does:

• git checkout -b feature/login creates and switches to a new feature branch.
• git add . stages the applicable changes in the current directory.
• git commit -m records the staged changes with a descriptive commit message.
• git push origin feature/login pushes the feature branch to the remote repository named origin.

After pushing the branch, the developer can create a Pull Request in GitHub so that other team members can review the proposed changes.

4. Creating a Pull Request in GitHub

A Pull Request, commonly called a PR, is used to propose changes from one branch into another. It allows team members to examine the code before it becomes part of the target branch.

During the review process, developers can:

• Review the proposed source-code changes.
• Provide comments and suggestions.
• Request modifications when necessary.
• Approve the changes according to project requirements.
• Check the results of automated validation workflows.

Once the required approvals and checks are completed, the Pull Request can be merged according to the team's development and release policies.

5. Common Git Branching Strategies

Different development teams use different branching strategies depending on their application architecture, release frequency, and collaboration requirements.

A common branching structure may include the following branches:

• main: Contains stable or production-ready code.
• develop: Used to integrate ongoing development changes.
• feature: Used to implement individual features or enhancements.
• release: Used to prepare and stabilize a particular application release.
• hotfix: Used to address urgent issues that require a separate corrective release.

The exact branching model depends on the project. In production environments, direct changes to the main branch are commonly restricted so that code changes pass through the required reviews and validation checks.

6. Why Pull Requests Are Important

Pull Requests provide a structured way to review and manage code changes before they are merged into important branches.

They help teams identify potential problems, discuss implementation decisions, verify automated checks, and maintain a record of changes made to the application.

When combined with branch protection rules and CI/CD validation, Pull Requests can help teams maintain a more controlled and consistent development workflow.

7. How to Resolve Git Merge Conflicts

A merge conflict occurs when Git cannot automatically combine changes from different branches. This can happen when multiple developers modify the same section of a file or when conflicting changes are introduced through separate commits.

When a conflict occurs, the developer should first inspect the repository and understand which files require attention.

Git Commands:

git pull
git status

The conflicting files can then be opened in a code editor. Git usually marks the conflicting sections so that the developer can identify the changes that need to be reconciled.

After reviewing the conflicting sections, the developer should:

1. Decide which changes should be retained.
2. Remove the conflict markers from the affected files.
3. Save the resolved files.
4. Run the relevant tests to verify the changes.
5. Stage and commit the resolved changes when appropriate.

Resolving conflicts carefully helps prevent accidental loss of another developer's work.

8. Using Git Tags for Version Management

Git tags are used to identify specific points in a repository's history. They are particularly useful for marking application releases and identifying the source-code version associated with a deployment.

For example, a team can create a tag for version 1.0.0 using the following commands:

Git Commands:

git tag v1.0.0
git push origin v1.0.0

The first command creates a tag named v1.0.0, while the second pushes that tag to the remote repository.

Tags help development and DevOps teams identify specific releases, investigate deployment issues, and locate previously released versions when preparing a rollback.

9. GitHub and Jenkins Integration

GitHub can be integrated with Jenkins to automate different stages of the software delivery process.

For example, a GitHub webhook can notify Jenkins when a developer pushes code or creates a Pull Request. Jenkins can then retrieve the required source code and start the configured pipeline.

The exact trigger depends on the Jenkins job configuration, repository integration, and the events selected by the development team.

10. Typical GitHub and Jenkins CI/CD Pipeline

A typical DevOps pipeline may contain the following stages:

CI/CD Workflow:

GitHub
   ↓
Jenkins
   ↓
Maven Build
   ↓
Unit Tests
   ↓
SonarQube
   ↓
Nexus
   ↓
Docker Build
   ↓
Docker Hub
   ↓
Deployment

Here is a brief explanation of the pipeline stages:

• GitHub: Stores the application's source code and manages collaboration.
• Jenkins: Automates the configured build, testing, and delivery stages.
• Maven: Builds Java applications and manages project dependencies.
• Unit Tests: Validate individual components of the application.
• SonarQube: Analyzes source code for code-quality issues and configured quality requirements.
• Nexus: Can store and manage build artifacts.
• Docker: Builds container images for applications.
• Docker Hub: Can be used as a registry to store and distribute container images.
• Deployment: Releases the application to the target environment.

The actual pipeline may differ between organizations. Some teams use alternative build tools, artifact repositories, container registries, cloud services, and deployment platforms.

11. Managing Deployments with Git Branches and Tags

Jenkins pipelines can use branch names or Git tags to control which workflow should run and which environment should receive a deployment.

For example, a development branch may trigger a pipeline that deploys the application to a testing environment, while a release tag may be used to identify a version approved for production deployment.

These conditions should be defined according to the organization's release process, approval requirements, and deployment policies.

12. Git Best Practices for DevOps Engineers

Following consistent Git practices helps development teams maintain an understandable repository history and reduce avoidable collaboration problems.

Some useful Git best practices include:

• Create small, meaningful commits that describe specific changes.
• Write clear and descriptive commit messages.
• Synchronize local branches with the appropriate remote branches regularly.
• Use Pull Requests to review changes before merging.
• Protect important branches such as main.
• Run the required tests before merging code.
• Use Git tags to identify important releases.
• Avoid committing passwords, tokens, and other sensitive information.
• Follow the branching and release strategy established by the project.

These practices help keep the repository organized and make it easier for team members to understand the development history.

13. How to Discard Local Changes in Git

Sometimes a developer modifies a file but later decides that the changes are unnecessary. Git provides the git restore command to discard unstaged changes to a specific file.

Git Command:

git restore <file>

This command restores the specified file to its state in the index, normally the version from the latest staging operation or commit when no other staged changes affect it.

Important: Use this command carefully because discarded local modifications may not be recoverable through Git.

14. How to Undo a Local Commit

If a developer creates a commit locally but has not pushed it to a shared repository, the commit can be undone using Git reset.

Git Command:

git reset HEAD~1

This command moves the current branch back by one commit. In its default mode, it keeps the changes from that commit in the working directory but unstages them.

The appropriate reset option depends on whether the developer wants to retain the changes, keep them staged, or discard them. Reset operations should be performed carefully to avoid losing work.

15. How to Revert a Commit Already Pushed to GitHub

When a commit has already been pushed to a shared branch, rewriting the existing history can affect other developers who have based their work on that commit.

In many shared-repository situations, git revert is a suitable approach because it creates a new commit that reverses the changes introduced by an earlier commit.

Git Command:

git revert <commit-id>

This approach preserves the existing commit history and records the reversal as a separate change.

16. Handling Accidentally Committed Secrets

One important security concern in Git is accidentally committing sensitive information, such as passwords, API keys, access tokens, or AWS credentials.

Removing a secret from the latest version of a file does not necessarily remove it from the repository's earlier commit history. Therefore, exposed credentials must be handled carefully.

If sensitive information is accidentally committed, the appropriate response includes the following steps:

1. Revoke or rotate the exposed credentials: Treat the credentials as compromised and replace them immediately.
2. Investigate the exposure: Determine which repository, branches, and systems may have been affected.
3. Remove the secret when necessary: If required, use an appropriate history-rewriting process and coordinate with the team.
4. Use secret-management tools: Store sensitive values in an approved secret manager rather than hard-coding them in source files.
5. Improve prevention: Consider secret scanning and repository security controls to help identify accidental exposures.

Credential rotation is essential because removing a secret from Git history does not guarantee that nobody has already accessed or copied it.

17. Git and GitHub in a Real-World DevOps Workflow

Git provides version control, while GitHub supports repository hosting and team collaboration. Jenkins connects these source-code changes with automated CI/CD processes.

A typical team workflow may include the following activities:

1. Developers create feature branches for their assigned tasks.
2. They implement changes and commit their work using Git.
3. They push their branches to GitHub.
4. Pull Requests are created for code review and validation.
5. Approved changes are merged into the appropriate branch.
6. Jenkins runs the configured build, test, and deployment pipeline.
7. Git tags may be used to identify important releases.

This workflow provides a structured way to manage source code and connect development activities with automated delivery.

Conclusion

Git and GitHub are essential tools for collaborative software development and modern DevOps practices. Git helps teams track changes, maintain source-code history, and work with branches, while GitHub provides repository hosting, Pull Requests, and collaboration features.

When integrated with Jenkins, GitHub can also support automated CI/CD workflows that include building, testing, code-quality analysis, artifact management, container image creation, and deployment.

By understanding Git commands, branching strategies, Pull Requests, merge conflicts, tagging, recovery methods, and security practices, developers and DevOps engineers can manage source code more effectively and support a consistent software delivery process.