Git Engineering Workflow 1

Introduction

This article walks through a complete Git-based development workflow: from creating a repository to branching, committing changes, opening a pull request, and merging into main. It demonstrates how modern teams collaborate using version control, feature isolation, code review, and CI/CD principles to deliver software in a structured and reliable way.

Lab Requirements

Before starting this Git Engineering Workflow Lab, ensure the following tools and accounts are available:

Software

• Git installed on your local machine
• Visual Studio Code (or another code editor)
• GitHub CLI (gh) installed and authenticated

Accounts

• A GitHub account
• Access to create repositories on GitHub

Basic Knowledge

• Familiarity with the command line or terminal
• Basic understanding of files and folders
• Fundamental Git concepts such as repositories, commits, and branches (helpful but not mandatory)

Lab Objectives

By completing this lab, you will learn how to:

• Create and clone Git repositories
• Work with feature branches
• Stage and commit changes
• Push code to GitHub
• Create and review Pull Requests
• Merge code into the main branch
• Understand the role of CI/CD in modern software development
• Implement a basic GitHub Actions workflow for Continuous Integration

Expected Outcome

At the end of the lab, you will have a fully functional GitHub repository that demonstrates a professional Git workflow, including branching, code review, merging, and a working CI pipeline using GitHub Actions.

Step 1: Creating the Repository

Before any code can be cloned, committed, or pushed, a repository must first be created. A Git repository serves as the central location where project files and their version history are stored.

To begin this exercise, I created a new repository on GitHub by:

• Logging into my GitHub account
• Clicking New Repository
• Naming the repository git-engineering-flow-lab
• Selecting Public visibility
• Initializing the repository with a README.md file

Once the repository was created, GitHub generated a remote location where all future changes to the project would be stored.

Step 2: Cloning the Repository

After creating the repository on GitHub, the next step was to clone it to my local machine.
At this stage, the repository existed only on GitHub. To start working on it locally, I needed to create a copy on my computer using Git's cloning feature.
Cloning a repository does much more than simply downloading files. When a repository is cloned, Git downloads:

• The project files
• The complete commit history
• Branch information
• Repository configuration

This creates a fully functional local copy of the project while maintaining a connection to the remote repository hosted on GitHub.

To clone the repository, I copied its HTTPS URL from GitHub and ran:

git clone https://github.com/rahimahisah17/git-engineering-flow-lab.git

Git then created a new folder named git-engineering-flow-lab and downloaded the repository contents into it.

At this point, I had two copies of the repository:

• A remote repository hosted on GitHub
• A local repository stored on my computer

This local repository would serve as my workspace for making changes before pushing them back to GitHub.

Step 3: Creating a Feature Branch
After cloning the repository, the next step in the Git workflow is to create a feature branch. This is where development work happens in isolation from the main codebase.

Working directly on the main branch is discouraged because it can introduce unstable or unfinished changes into production code. Instead, feature branches allow developers to safely build new functionality without affecting the stable version of the project.

To begin working on a new feature, I created and switched to a new branch using the following command:

git checkout -b feature/add-login-button

This command performs two actions at once:

• Creates a new branch called feature/add-login-button
• Switches to that branch immediately
• So all new work happens in isolation

You can confirm the branch was created and active by running:

git branch

Feature branches are a core part of modern Git workflows because they:

• Keep the main branch stable and deployable
• Allow multiple developers to work independently
• Enable experimentation without risk to production code
• Make code review easier through Pull Requests

Step 4: Write Code and Commit Changes

After creating a feature branch and adding a new file to the project, the next step in the Git workflow is to write code (make changes) and commit them.

In this step, I created a simple file called login.txt to represent the login feature being developed.

Inside the project directory, I added content to a new file:

echo Login button feature added > login.txt

This command creates a file named login.txt and writes a simple message into it. In a real project, this step would involve writing actual application code instead of a text file.

To check the state of the repository, I ran:

git status

Then I staged the file using:

git add login.txt

Staging tells Git which changes should be included in the next commit. At this point, the file moved from “untracked” to “ready to be committed.”

Then I created a commit:

git commit -m "feat: add login"

This command creates a commit, which is a permanent snapshot of the project at that point in time.

A commit is one of the most important concepts in Git. It acts like a save point, allowing developers to track progress, revert changes if needed, and maintain a clear history of the project.

By committing small and meaningful changes, the project history remains clean, readable, and easy to manage.

Step 5: Push Branch to Remote Repository

After committing my changes locally, the next step was to upload my work to GitHub. This is done by pushing the feature branch to the remote repository.

At this stage, my changes existed only on my local machine. To share them and prepare for collaboration, I needed to synchronize my local branch with GitHub.

I ran the following command:

git push -u origin feature/add-login-button

This command performs two important actions:

• Pushes the branch to GitHub
• Uploads the local feature/add-login-button branch to the remote repository
• Sets upstream tracking (-u)
• Links the local branch to the remote branch
• This allows future pushes to be done using only:

git push

Pushing a branch is a key part of modern Git workflows because it:

• Shares your work with the remote repository (GitHub)
• Makes your changes visible to teammates
• Prepares the branch for pull request creation
• Keeps local and remote repositories in sync

Without pushing, your work remains only on your local machine and cannot be reviewed or merged.

Step 6: Open Pull Request (PR)

After pushing my feature branch to GitHub, the next step was to open a Pull Request (PR). A Pull Request is a way of proposing changes so they can be reviewed before being merged into the main branch.

This is a key part of collaborative development, where code is not directly pushed into production but instead reviewed first.

To create the Pull Request, I used the GitHub CLI:

gh pr create --fill

This command automatically:

• Creates a Pull Request on GitHub
• Compares the feature branch (feature/add-login-button) with main
• Uses the latest commit message as the PR title
• Auto-fills the PR description based on commit history

After running the command, GitHub generated a URL to view the Pull Request in the browser.

Instead of directly pushing changes to main, developers work on feature branches and submit Pull Requests for review.

A Pull Request represents a proposal to merge changes. It is not yet part of the main codebase. This ensures that every change is reviewed, discussed, and approved before integration.

Even in solo projects, PRs help simulate real-world engineering workflows.

Step 7: Code Review

After opening the Pull Request, the next stage in the Git workflow is code review. This is where changes are inspected before being merged into the main branch.

Even though this project was done individually, this step simulates how teams review code in real-world development environments.

To inspect the Pull Request directly from the terminal, I ran:

gh pr view --comments

The terminal displayed the Pull Request summary:

• PR Title: feat: add login file
• Status: Open
• Branch: feature/add-login-button → main
• Comments: None
• Checks: No checks

No description:

• This means no additional PR description was manually added
• GitHub only used the commit message as the PR title

No checks:

• This indicates there is no CI/CD pipeline configured for this repository
• In real-world projects, this area would show automated test results or build status

Code review is a critical step in professional software development because it:

• Helps catch bugs before merging
• Improves code quality
• Encourages collaboration and feedback
• Ensures consistency in the codebase

Even when working alone, reviewing your own PR helps reinforce good development habits.

A Pull Request is not just a merge request BUT a discussion point for changes. This is where code is validated before becoming part of the main branch.

This step completes the review stage of the Git workflow, preparing the changes for final integration into the main branch.

Step 8: Merge Pull Request into Main

After completing code review, the final step in the Git workflow is to merge the Pull Request into the main branch. This is where the feature officially becomes part of the project’s primary codebase.

At this point, the feature branch has been developed, reviewed, and approved for integration.

To complete the merge using the GitHub CLI, I ran:

gh pr merge --squash

This command performs several actions automatically:

• Merges the Pull Request into the main branch
• Squashes all commits into one meaningful commit
• Closes the Pull Request
• Updates the repository history on GitHub

In modern Git workflows, feature branches are temporary. Once their work is completed and merged, they are deleted or left inactive. The main branch remains the single source of truth for production-ready code.

This step completes the full Git workflow cycle:
write code → commit → push → review → merge → deliver to main

Step 9: CI/CD Deployment (Automated Delivery)

After merging the Pull Request into the main branch, the final stage in a modern Git workflow is CI/CD (Continuous Integration and Continuous Deployment).

At this point, the responsibility of delivering the code shifts from the developer to an automated system.

What triggers CI/CD?

In most real-world projects, a CI/CD pipeline is automatically triggered when:

• Code is pushed to a repository (git push)
• A Pull Request is merged into main

In this workflow, the merge into main represents a production-ready change that activates the pipeline.

What happens in the pipeline?

Once triggered, the CI/CD system typically performs several automated tasks:

Continuous Integration (CI):

• Runs automated tests
• Validates code quality
• Ensures new changes do not break existing functionality

Continuous Deployment (CD):

• Builds the application
• Packages the code
• Deploys it to a staging or production environment

CI/CD removes manual deployment steps from the development process.

Instead of developers copying files to servers manually, everything is handled by automation:

Once code is merged into main, it can automatically be tested, built, and deployed without human intervention.

Why CI/CD is important

This approach improves software delivery by:

• Reducing human error in deployments
• Speeding up release cycles
• Ensuring consistent builds
• Allowing rapid feedback from production systems

CI/CD represents the final stage of the Git workflow. It ensures that every approved change can safely and automatically reach production.
This completes the full development cycle:

code → commit → push → review → merge → deploy

To reinforce the CI/CD concept, I created a GitHub Actions workflow and successfully triggered it by pushing changes to the main branch. The workflow executed automatically and completed successfully, demonstrating how modern development teams automate validation and delivery processes.

Summary

This article demonstrates a complete Git workflow used in modern software development. It covers creating a repository, cloning it locally, working on a feature branch, making and committing changes, pushing to GitHub, opening a pull request, performing code review, merging changes into the main branch, and understanding CI/CD deployment. The process highlights how developers collaborate, maintain code quality, and automate delivery using Git and GitHub.
NOTE: A GitHub Actions workflow was implemented to demonstrate Continuous Integration (CI). While a deployment target was not configured, the workflow successfully validated the automation process that forms the foundation of a complete CI/CD pipeline.