DevOps - Git

Quiz

Git is a distributed version control system. It plays a big role in DevOps workflows. We use Git to manage source code, help developers collaborate, and automate continuous integration/continuous deployment (CI/CD) pipelines. Git makes it easy to track versions, create branches, and merge code changes.

These features are very important for fast collaboration and quick development cycles. Git repositories are the core of DevOps pipelines. They trigger automated builds, tests, and deployments. This ensures we deliver software quickly, consistently, and with full traceability.

Setting Up Git for DevOps Workflow

In this section, let's understand how to set up Git for DevOps workflow.

Installing and Configuring Git

To start with Git in a DevOps workflow, first, we need to install it on our system −

Linux

sudo apt-get install git

macOS

brew install git

Windows

We can download and install Git from the official website.

After installing Git, we need to set up our user details globally −

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

This makes sure that our commits are correctly linked to us. To check the setup, we can use −

git config --list

Integrating Git with CI / CD Tools (Jenkins, GitLab CI, etc.)

Git works well with CI/CD tools like Jenkins, GitLab CI, and others. It helps trigger builds and deployments automatically.

Jenkins

First, we need to install the Git Plugin in Jenkins. In the Jenkins job setup, we add the Git repository URL and our credentials. We configure the build to start based on Git events, like a push or pull request. Take a look at the following example −

scm:
  git:
    - url: 'https://github.com/your-repository.git'
      branch: 'main'

GitLab CI

We define our CI/CD pipeline in a file called .gitlab-ci.yml inside the repository. Take a look at the following example −

stages:
  - build
  - test
  - deploy
build:
  stage: build
  script:
    - npm install
test:
  stage: test
  script:
    - npm test
deploy:
  stage: deploy
  script:
    - ./deploy.sh

This makes sure that each push to the Git repository will trigger the correct CI/CD pipeline.

Branching Strategies in DevOps

In DevOps, branching strategies help us manage how we make changes to our code in a Git repository. A good branching strategy is very important for better teamwork, faster development, and smooth CI/CD pipelines. Some common strategies we use are Git Flow, GitHub Flow, and trunk-based development.

Git Flow vs. GitHub Flow vs. Trunk-Based Development

Git Flow − Git Flow is an old method. In this strategy, the master branch has the stable code for production, and the develop branch has the latest development changes. New features go into separate feature branches. We create releases from the release branch, and any urgent fixes are done in the hotfix branch. This method works well for big projects that need planned releases.

git flow init

GitHub Flow − GitHub Flow is simpler and works best for continuous delivery. In this method, we create feature branches from main, work on them, and once ready, merge them back into main. This is good for teams that deploy often and use pull requests to review code.

git checkout -b feature-branch
git push origin feature-branch

Trunk-Based Development − Trunk-based development focuses on making small, frequent commits directly to the main (or trunk) branch. We often create short-lived feature branches or sometimes work directly on main and merge changes multiple times a day. This method supports continuous integration and delivery with minimal branching.

git checkout main
git pull origin main
git merge feature-branch

Creating and Managing Feature, Release, and Hotfix Branches

In DevOps, we create and manage different branches for features, releases, and hotfixes. This helps us work on different tasks without disturbing the main code.

Feature Branches − We use feature branches to develop new features or improvements without changing the main code. These branches are created from the main or develop branch.

git checkout -b feature/login-ui

Release Branches − Release branches help us prepare the code for deployment. We use them for last-minute changes, bug fixes, and versioning before merging back into main and develop.

git checkout -b release/1.0.0

Hotfix Branches − Hotfix branches are made for quick fixes in the production environment. After fixing the issue, we merge the hotfix back into both main and develop to keep them up-to-date.

git checkout -b hotfix/fix-crash

Merging and Rebasing Strategies in Team Collaboration

We can use either merging or rebasing to bring changes from different branches together.

Merging − Merging combines changes from one branch into another while keeping the commit history. This is helpful when we want to maintain the full context of each change.

git merge feature-branch

Rebasing − Rebasing moves the entire branch to start from the latest commit of the target branch, which gives a cleaner history. Its helpful when we want to avoid extra merge commits.

git rebase main

When to Use Merging or Rebasing

We prefer merging when we want to keep the exact history of our changes.
We use rebasing when we want a clean history, especially for feature branches before merging them into main.

The strategy we choose depends on our team's workflow, release schedule, and whether we want a detailed or clean commit history.

Git Hooks in DevOps Automation

Git hooks are simple scripts that run at different points during the Git process. They help automate tasks before or after certain Git actions. Using hooks can make our workflow smoother and help enforce good practices in DevOps pipelines.

pre-commit − This hook runs before a commit is created. It's useful for checking code style or running linters to keep the code clean.
commit-msg − It runs after the commit message is written but before the commit is finished. It ensures that commit messages follow a certain style.
post-commit − This one runs after a commit. It's often used to notify teams or run extra tests.
pre-push − This hook runs before changes are pushed to a remote repository. It can be used to run unit tests or validation checks before pushing.
post-merge − This runs after a merge. It can trigger deployment scripts or run extra tests after merging code.

We usually place these hooks in the .git/hooks/ folder. We can also customize them based on our DevOps pipeline needs.

Automating Linting, Testing, and Deployment with Git Hooks

Git hooks are great for automating tasks like linting, testing, and deployment during development. For example:

pre-commit (Linting)

We can automatically lint code before each commit to make sure the code is clean.

Example for a pre-commit hook (using eslint for JavaScript) −

# .git/hooks/pre-commit
#!/bin/sh
npm run lint
if [ $? -ne 0 ]; then
  echo "Linting failed, commit aborted!"
  exit 1
fi

pre-push (Testing)

We can run unit tests before pushing to make sure the code doesn't break anything.

Example for a pre-push hook (using jest for testing) −

# .git/hooks/pre-push
#!/bin/sh
npm test
if [ $? -ne 0 ]; then
   echo "Tests failed, push aborted!"
   exit 1
fi

post-commit (Deployment)

After committing, we can trigger deployment scripts, especially for staging or production environments.

Example for a post-commit hook (deploying to a server) −

# .git/hooks/post-commit
#!/bin/sh
./deploy.sh

These hooks help automate tasks like checking code, running tests, and deploying, all while staying tightly integrated with the Git workflow.

Conclusion

In this chapter, we explained the key aspects of using Git in a DevOps environment. We covered setting up Git for workflows, automating common Git operations, managing branches, using Git hooks, and automating deployment scripts.

By using Git's power in DevOps pipelines, we can ensure consistent code quality. It also helps us streamline testing and deployment and improve collaboration.

Print Page