Repository Management

Introduction

A repository (repo) is the core storage unit in Git. Managing it effectively involves initializing, cloning, and maintaining the state of your project files.

A Git repository is a directory that contains your project files along with a hidden .git folder. The .git directory stores all the version history, branches, commits, tags, and configuration information for the project. There are two types of repositories:

• • Local Repository – Stored on your computer.
• • Remote Repository – Hosted on platforms like GitHub, GitLab, or Bitbucket.

What is a Git Repository?

A Git repository is a virtual directory that tracks changes to your project files. It contains the project's entire history and metadata in a hidden .git folder. There are two main ways to start a repository:

• Local Initialization: Starting a new project on your computer.
• Cloning: Downloading an existing project from a remote host like GitHub.

Common Repository Management Commands

These commands are the "bread and butter" of a developer's daily workflow:

• git init: Initializes a new, empty Git repository in the current folder.
• git clone [url]: Creates a local copy of an existing remote repository.
• git status: Displays the state of the working directory and the staging area (shows which files are tracked or untracked).
• git add [file]: Moves changes from the working directory to the Staging Area.
• git commit -m "message": Permanently saves the staged changes to the repository history.
• git remote add origin [url]: Links your local repo to a remote server (like GitHub).
• git push -u origin main: Uploads your local commits to the remote repository.

Conclusion

Repository management is the foundation of version control. By understanding the distinction between the working directory, the staging area, and the commit history, you gain full control over your project's evolution. Consistent use of these commands ensures that your code remains organized, shareable, and recoverable at any point in time.

Repository Management is the foundation of working with Git. It involves creating repositories, tracking changes, committing updates, managing files, viewing history, and synchronizing with remote repositories. Proper repository management improves collaboration, maintains a complete history of project changes, and ensures that source code remains secure, organized, and easy to maintain.

Branching Strategy in Git

Introduction

A Branching Strategy is a workflow approach to manage different versions of code. It allows parallel development without affecting the stable production codebase.

A Branching Strategy is a workflow approach used in Git to manage different versions of source code during software development. Branches allow developers to work on new features, bug fixes, testing, and releases without affecting the main production code. A well-defined branching strategy improves collaboration, reduces conflicts, and supports efficient CI/CD (Continuous Integration and Continuous Deployment) workflows used in DevOps environments.

What is a Git Branch?

A Git branch is an independent line of development. Each branch maintains its own commit history, which can later be merged back into the main line.

Common Branching Strategies

1. Git Flow Strategy

A structured model ideal for release-heavy projects. It uses specific branches: main (stable), develop (integration), feature/*, release/*, and hotfix/*.

2. GitHub Flow

A lightweight, branch-based workflow that supports teams who deploy regularly. It relies on Pull Requests for code review before merging into main.

3. Trunk-Based Development

Focuses on a single main branch with short-lived feature branches, ideal for CI/CD pipelines to avoid "merge hell."

4. GitLab Flow

Combines Git Flow and GitHub Flow, utilizing environment-specific branches (staging/production) for enterprise applications.

Branch Management Commands

Branching Strategy in DevOps

In a modern DevOps lifecycle, branching is the trigger for automated pipelines:

• CI Pipeline: Automated testing on every Pull Request.
• Deployment: Merging to main triggers auto-deployment to production via Jenkins, Docker, or Kubernetes.

Recommendation: For most DevOps teams, GitHub Flow combined with CI/CD is the most efficient and scalable choice.

Recommended Strategy for DevOps Projects

In modern DevOps environments, simplicity and speed are paramount. For most agile teams, the GitHub Flow + CI/CD integration is the gold standard.

Why this strategy wins:

• Scalability: Works flawlessly with cloud-native architectures.
• Reliability: Automated testing prevents broken code from hitting production.
• Speed: Small, frequent deployments reduce complexity and minimize "merge hell."

Git Merge & Rebase

Introduction

Both Merge and Rebase are Git commands used to integrate changes from one branch into another branch. They combine different development histories but work in different ways.

1. Git Merge

Definition: Git Merge combines the changes from one branch into another branch by creating a new merge commit. It preserves the complete history of both branches.

Syntax: git merge <branch-name>

Example:
Suppose we have:
main
|
A---B
\
C---D feature
After merging:
main
|
A---B---------M
\ /
C-----D
M = Merge Commit

Steps:

• Switch to the branch where you want changes: git checkout main
• Merge feature branch: git merge feature
• Push changes: git push origin main

Advantages of Git Merge

• ✅ Keeps complete project history
• ✅ Safe for shared/public branches
• ✅ Easy to understand
• ✅ Does not modify existing commits

Disadvantages

• ❌ Creates additional merge commits
• ❌ History can become complex in large projects

2. Git Rebase

Definition: Git Rebase moves or reapplies your branch commits on top of another branch. It creates a cleaner, linear project history.

Syntax: git rebase <branch-name>

Example:
Before Rebase:
main
|
A---B---C
\
D---E feature
After Rebase:
main
|
A---B---C---D'---E'
The feature branch commits are rewritten on top of the latest main branch.

Steps:

• Switch to feature branch: git checkout feature
• Update branch: git fetch origin
• Rebase with main: git rebase main
• Push changes: git push origin feature
• If history was changed: git push --force

Merge vs Rebase Comparison

When to Use Git Merge

Use Merge when: Working with shared branches, multiple developers collaborate, you want to preserve complete history, or merging production releases.

Example: feature branch → main branch
Command: git checkout main, git merge feature

When to Use Git Rebase

Use Rebase when: Updating your personal feature branch, cleaning commit history, preparing code before a Pull Request, or keeping Git history simple.

Example: feature branch → latest main changes
Command: git checkout feature, git rebase main

DevOps / CI-CD Best Practice

A common DevOps workflow:
Developer -> Feature Branch -> git rebase main -> Pull Request -> Code Review -> Merge into Main -> CI/CD Pipeline -> Production Deployment

Important Rule: ⚠️ Never rebase shared branches like main, master, or production. Avoid git rebase main on a branch that many developers are using. Rebase is best for your own local feature branches.

Useful Commands

• Check branch history: git log --oneline --graph --all
• Abort merge: git merge --abort
• Abort rebase: git rebase --abort
• Continue rebase: git rebase --continue

Summary

• Merge = Combine branches safely and preserve history
• Rebase = Rewrite history and create a clean linear timeline
• For enterprise DevOps teams: Rebase feature branches + Merge reviewed code into main branch

Git Pull Requests (PR)

Introduction

A Pull Request (PR) allows developers to request that their code changes be reviewed and merged into another branch. It is a collaboration and code review workflow built on top of Git.

Purpose of Pull Requests:

• ✅ Review code before merging
• ✅ Detect bugs and security issues
• ✅ Discuss improvements
• ✅ Run automated CI/CD tests
• ✅ Maintain code quality & track approvals

Pull Request Workflow

The standard development path involves: Clone -> Feature Branch -> Develop -> Commit -> Push -> Create PR -> Review -> Merge -> Deploy.

Creating a PR (Step-by-Step):

1. Clone: git clone https://github.com/company/project.git
2. Branch: git checkout -b feature-login
3. Code & Commit: git add . followed by git commit -m "Added user login feature"
4. Push: git push origin feature-login
5. Create PR: On GitHub/GitLab, select source feature-login and target main.

The Review Process

1. Code Review: Senior developers check quality, security, and standards.
2. Automated Testing: CI/CD tools verify the build, unit tests, and security scans.
3. Approval: Final sign-off from Lead/QA/DevOps.
4. Merge Options: Merge Commit, Squash Merge, or Rebase Merge.

Best Practices

• Keep PRs Small: Focus on one task per PR.
• Clear Titles: Use descriptive names (e.g., "Add AWS S3 backup automation").
• Add Descriptions: Explain the purpose, changes, and testing results.
• Link Issues: Use Fixes #245 to track bugs.
• Never Push Directly to Main: Always go through the PR/Review process.

Pull Requests in DevOps

PRs are the heart of DevOps automation. A PR creation triggers an automated pipeline:

Developer PR -> GitHub/GitLab -> CI Pipeline (Build, Test, Security Scan) -> Approval -> Merge -> CD Deployment -> Production
        

Common PR Commands:

Pull Request Summary

GitHub Actions

Introduction

Definition: GitHub Actions is a CI/CD automation platform provided by GitHub that allows developers and DevOps engineers to automatically build, test, deploy, and manage software workflows directly from a GitHub repository.

It uses YAML configuration files to define automated workflows that run when specific events occur, such as:

• Code push
• Pull Request creation
• New release
• Scheduled time (cron jobs)
• Manual execution

Why Use GitHub Actions?

GitHub Actions helps teams:

• ✅ Automate software build processes
• ✅ Run automated tests
• ✅ Perform security scans
• ✅ Build Docker images
• ✅ Deploy applications to cloud platforms
• ✅ Automate DevOps tasks
• ✅ Reduce manual deployment effort

GitHub Actions Architecture

The main components are:

Repository
    |
.github/workflows/
    |
Workflow YAML File
    |
   Jobs
    |
   Steps
    |
  Actions / Commands
    |
  Runner Machine

Main Components of GitHub Actions

1. Workflow

A workflow is an automated process defined in a YAML file. Location: .github/workflows/. A workflow defines when it runs, what jobs execute, and what steps are performed.

2. Events (Triggers)

Events define when the workflow starts.

• Push Event: on: push: branches: - main (Runs when code is pushed to the main branch).
• Pull Request Event: on: pull_request: branches: - main (Runs when a Pull Request is created).
• Schedule Event: on: schedule: - cron: "0 0 * * *" (Runs automatically at scheduled times).

3. Jobs

A workflow contains one or more jobs. Example: jobs: build: runs-on: ubuntu-latest. Jobs run on Ubuntu, Windows, or macOS.

4. Steps

Steps are individual tasks inside a job.

5. Actions

Actions are reusable automation components (e.g., uses: actions/checkout@v4).

6. Runner

A Runner is the server that executes GitHub Actions workflows. Types: GitHub-hosted runners (Ubuntu, Windows, macOS) and Self-hosted runners (AWS EC2, On-premises Linux, Private infrastructure).

Basic GitHub Actions Workflow

Example: .github/workflows/build.yml

name: Node.js CI Pipeline
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout Code
      uses: actions/checkout@v4
    - name: Setup Node
      uses: actions/setup-node@v4
      with:
        node-version: 20
    - name: Install Packages
      run: npm install
    - name: Run Tests
      run: npm test

GitHub Actions CI/CD Pipeline

Flow: Developer → Git Push → GitHub Repository → GitHub Actions Trigger → Build, Test, Security Scan → Docker Image Build → Push to Registry → Deploy to AWS/Kubernetes → Production

GitHub Actions with Docker

Example workflow:

name: Docker Build
on:
  push:
    branches:
      - main
jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Build Docker Image
      run: docker build -t myapp .
    - name: Login Docker Hub
      run: docker login
    - name: Push Image
      run: docker push myapp

GitHub Actions with AWS Deployment

Common AWS integrations: Amazon EC2, Amazon S3, Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS).

GitHub Actions vs Jenkins

GitHub Actions Best Practices

1. Use Secrets: Never store passwords in plain text. Use ${{ secrets.DB_PASSWORD }}.
2. Use Branch Protection: Protect main, production, release branches.
3. Cache Dependencies: Use actions/cache@v4 to improve pipeline speed.
4. Separate Environments: Development → Testing → Staging → Production.

Summary

GitHub Actions = Automation engine for GitHub repositories.

• Workflow → Complete automation process
• Event → Trigger condition
• Job → Group of tasks
• Step → Individual commands
• Action → Reusable automation component
• Runner → Machine executing the workflow

For a DevOps Engineer, GitHub Actions is an essential CI/CD skill used for automating modern cloud-native application deployments.

GitLab Overview

Introduction

Definition: GitLab is a complete DevOps platform that provides tools for the entire software development lifecycle, including source code management, version control, CI/CD automation, security testing, monitoring, and application deployment.

Unlike traditional tools that require multiple integrations, GitLab provides a single platform where teams can plan, create, test, deploy, and monitor applications. GitLab is widely used by DevOps teams for implementing DevOps automation and CI/CD pipelines.

GitLab DevOps Lifecycle

GitLab follows the complete DevOps lifecycle:

Plan | Create | Verify | Package | Release | Configure | Monitor | Secure

Key Features of GitLab

1. Git Repository Management

GitLab provides Git-based source code management similar to GitHub. Developers can create repositories, store source code, manage branches, track changes, review code, and manage permissions.

Example: git clone https://gitlab.com/company/project.git

2. GitLab Projects

A Project is a repository where source code, issues, pipelines, and documentation are stored.

Company Project
       |
       ├── Source Code
       ├── Issues
       ├── Merge Requests
       ├── CI/CD Pipeline
       └── Documentation

3. GitLab Branching Strategy

Common enterprise workflow: main | develop | feature | release | hotfix

4. Merge Requests (MR)

GitLab uses Merge Requests instead of Pull Requests. A Merge Request allows developers to submit code changes, request reviews, discuss improvements, run automated tests, and merge approved code.

Workflow: Developer → Feature Branch → Merge Request → Code Review → CI/CD Pipeline → Merge into Main

5. GitLab CI/CD

GitLab has built-in CI/CD automation. Configuration file: .gitlab-ci.yml

stages:
 - build
 - test
 - deploy

build_job:
 stage: build
 script:
   - echo "Building application"

test_job:
 stage: test
 script:
   - echo "Running tests"

deploy_job:
 stage: deploy
 script:
   - echo "Deploying application"

GitLab Pipeline Architecture

Code Push → GitLab CI/CD Trigger → (Build | Test | Security Scan | Deploy) → Production

6. GitLab Runner

A GitLab Runner executes CI/CD jobs. Types: Shared Runner (Provided by GitLab) and Specific Runner (Dedicated to a project/group).

7. GitLab Container Registry

GitLab provides a built-in Docker image registry. Workflow: Developer → Docker Build → GitLab Container Registry → Kubernetes Deployment.

8. GitLab Kubernetes Integration

GitLab integrates with Kubernetes for automated deployments. Common environments: Development, Staging, Production.

9. GitLab Security Features

GitLab provides DevSecOps capabilities: SAST, DAST, Dependency Scanning, Container Scanning, and Secret Detection.

10. GitLab Issue Tracking

GitLab includes project management features: Issues, Labels, Milestones, Boards, and Roadmaps.

Example: Issue #101 | Title: Fix Login Authentication Bug | Status: In Progress

GitLab Architecture

Users → GitLab Web UI → (Git Repository | CI/CD Engine | GitLab Runner) → Deployment → Cloud/Kubernetes/Server

GitLab vs GitHub

GitLab in DevOps Workflow

Developer → GitLab Repository → Merge Request → GitLab CI/CD Pipeline → Docker Build → Container Registry → Kubernetes/Cloud → Production

Common GitLab Commands

• Clone repository: git clone <repository-url>
• Check status: git status
• Create branch: git checkout -b feature-name
• Push changes: git push origin feature-name
• Pull latest code: git pull origin main

GitLab Best Practices

✅ Use protected branches | ✅ Enable Merge Request approvals | ✅ Store credentials in CI/CD variables | ✅ Use automated testing pipelines | ✅ Integrate security scanning | ✅ Use Infrastructure as Code with Terraform | ✅ Use Docker and Kubernetes deployment automation

GitLab Summary

GitLab is an all-in-one DevOps platform that enables organizations to manage the complete software delivery lifecycle — from source code to production deployment.

Git Best Practices

Introduction

Definition: Git Best Practices are recommended rules, workflows, and techniques that help development teams maintain clean code history, improve collaboration, reduce conflicts, and enable reliable CI/CD deployments. Following Git best practices is essential for DevOps engineers, software developers, and cloud teams working on enterprise projects.

1. Use Meaningful Commit Messages

Recommended Format: <Type>: Short description

2. Commit Small and Frequently

Avoid large commits. Benefits: Easier code review, troubleshooting, and better rollback capability.

3. Never Commit Directly to Main Branch

Recommended: Developer → Feature Branch → Pull/Merge Request → Code Review → main.

4. Use a Branching Strategy

Main enterprise workflow includes: main, develop, feature/*, bugfix/*, and hotfix/*.

5. Pull Latest Changes Before Starting Work

git checkout main → git pull origin main → git checkout -b feature-login

6. Use Pull Requests / Merge Requests

Never merge untested code. Workflow: Feature Branch → Pull Request → Code Review → CI/CD Testing → Merge.

7. Review Code Before Merging

Review for code quality, security, performance, standards, and documentation.

8. Keep Branches Updated

Use git merge main or git rebase main regularly to reduce conflicts.

9. Avoid Committing Sensitive Data

❌ Never commit passwords, API keys, or SSH keys. Use Environment variables or CI/CD secrets.

10. Use .gitignore Properly

Exclude files like node_modules/, .env, *.log, .terraform/.

11. Write Good README Documentation

Include description, installation, configuration, usage, and deployment process.

12. Tag Releases

Use Git tags for versions (e.g., v1.0.0) following the Major.Minor.Patch format.

13. Use Git Hooks

Automate checks (formatting, unit testing, security) before commits using pre-commit hooks.

14. Use Git Rebase Carefully

Good for personal feature branches; ⚠️ Avoid on shared/production branches.

15. Resolve Conflicts Carefully

Check git status, edit files, git add ., then git commit.

16. Use CI/CD Integration

Connect Git with GitHub Actions, GitLab CI/CD, or Jenkins.

17. Regularly Clean Repository

Remove unused branches: git branch -d and git fetch --prune.

Recommended DevOps Git Workflow

Clone → Feature Branch → Code Changes → Commit → Push → Pull Request → CI/CD Pipeline → Code Review → Merge to Main → Production Deployment.

Git Best Practices Checklist

Summary

Git Best Practices help teams build secure, maintainable, and scalable software delivery workflows. For a DevOps Engineer, the ideal Git workflow is: Feature Branch → Commit → Push → Pull Request → Review → CI/CD Pipeline → Merge → Production Deployment.

Real-World Team Collaboration Using Git

Introduction

Definition: Real-world Git team collaboration describes how multiple developers, DevOps engineers, testers, and project managers work together on the same software project using Git-based workflows. In professional environments, Git is used with platforms like GitHub, GitLab, and Bitbucket to manage source code, review changes, automate testing, and deploy applications.

Real-World Development Team Structure

                 Project Manager
                       |
                 Technical Lead
                       |
        -----------------------------
        |              |            |
     Developers     QA Team    DevOps Engineer
        |              |            |
        -----------------------------
                       |
                   Production

Typical Team Roles

• 1. Developer: Writes application code, creates feature branches, commits changes, and creates Pull/Merge Requests. (Example: git checkout -b feature-payment)
• 2. Tech Lead / Senior Developer: Reviews code, approves changes, maintains coding standards, and manages branch strategy.
• 3. QA Engineer: Tests new features, verifies bug fixes, runs automated tests, and reports issues.
• 4. DevOps Engineer: Manages CI/CD pipelines, automates deployments, maintains cloud infrastructure, and manages containers/Kubernetes.

Enterprise Git Workflow

                Production
                    |
                   main
                    |
              release branch
                    |
                 develop
                    |
        -------------------------
        |           |           |
    feature-1   feature-2    bug-fix

Step-by-Step Real-World Collaboration

1. Project Setup: DevOps engineer initializes repository (git init).
2. Clone: Developer downloads project (git clone <repository-url>).
3. Create Feature Branch: Developers never work on main (git checkout -b feature-user-login).
4. Development: Write code and check status (git status).
5. Commit Changes: Create meaningful commits (git add ., git commit -m "feat: Add authentication").
6. Push: Upload to remote server (git push origin feature-user-login).
7. Pull/Merge Request: Create PR/MR with description, screenshots, and testing details.
8. Code Review: Senior developer checks quality, security, and performance.
9. Automated CI/CD Pipeline: Pipeline runs Build, Unit Tests, Security Scans, and Docker Build.
10. Merge Code: After approval, git merge feature-user-login.
11. Testing & Deployment: Development server → QA Testing → Production Release.

Best Practices & Real-World Examples

Handling Conflicts: If login.py changes by two devs, use git pull origin develop, fix conflicts, and commit.

DevOps Integration: Git → PR → CI/CD → Docker Build → Container Registry → Kubernetes → Production.

• Branch Protection: Protect main/production branches.
• Communication: Use Git Issues for tracking bugs and tasks.
• Small Commits: Keep commits focused on individual tasks.
• Code Reviews: Essential for quality and knowledge sharing.
• Automate Everything: Testing, security, deployment, and infrastructure.

Real-World Example: Banking Application

Developer → Feature Branch → Merge Request → Security Review → Auto Testing → Approval → CI/CD Pipeline → Kubernetes → Production System

Summary

Real-world Git collaboration follows this pattern: Clone → Branch → Code → Commit → Push → Pull Request → Review → CI/CD Testing → Merge → Deploy.