راقب اتجاهات التقنية العالمية، وجمع موارد المطورين

The DevOps bootcamp · Chapter 4 of 14 · DevOps · new chapter every Thursday morning

By the end of this chapter: Use branches, tags and history the way a delivery pipeline reads them.

The problem

You are a junior engineer on your first backend project, and you need to test a branch on the team's shared staging server. You SSH into the server, pull your code, and run the start command. However, the terminal returns an error message: Error: listen EADDRINUSE: address already in use :::8080. This error indicates that another process is already using port 8080, which is the port your application is trying to use.

You try changing the port, but the proxy routing traffic to your application expects it to be running on port 8080. You assume the previous version of the application is still running, but you do not know how to find it. You try running your new application as the superuser to force it through, and it starts, but immediately crashes with Permission denied: /var/log/staging-api/error.log. This error message suggests that your application does not have the necessary permissions to write to the log file.

You have wasted an hour trying to troubleshoot the issue, and you are still no closer to testing your branch. You need to understand how to manage different versions of your application, how to find and stop running processes, and how to handle permissions issues.

Before you start

To follow along with this chapter, you need to have Git installed on your machine, and you should have a basic understanding of Linux commands, such as navigating the file system and running processes. You should also have a Git repository set up for your project. You can verify that Git is installed by running the command git --version in your terminal. The output should display the version of Git installed on your machine, such as git version 2.37.1.

Understanding Git branches

In Git, a branch is a separate line of development in your repository. You can think of it as a separate copy of your codebase that you can work on independently of the main codebase. When you create a new branch, Git creates a new pointer to the current commit, and any changes you make will be committed to that branch.

To create a new branch, you can use the command git branch <branch-name>. For example, to create a new branch called feature/new-feature, you would run the command git branch feature/new-feature. You can then switch to that branch using the command git checkout feature/new-feature.

Using Git tags

Git tags are used to mark specific points in your repository's history. They are often used to mark releases or milestones. To create a new tag, you can use the command git tag <tag-name>. For example, to create a new tag called v1.0, you would run the command git tag v1.0.

Understanding Git history

Git history refers to the record of all changes made to your repository over time. You can view the history of your repository using the command git log. This will display a list of all commits made to your repository, including the commit message, author, and date.

Build it

To solve the problem of testing a branch on the shared staging server, you can follow these steps:

Create a new branch for your feature: Run the command git branch feature/new-feature to create a new branch.
Switch to the new branch: Run the command git checkout feature/new-feature to switch to the new branch.
Make changes and commit: Make the necessary changes to your code and commit them using the command git add . and git commit -m "New feature".
Push the branch to the remote repository: Run the command git push origin feature/new-feature to push the new branch to the remote repository.
SSH into the staging server: SSH into the staging server and pull the new branch using the command git pull origin feature/new-feature.
Stop any running processes: Use the command ps aux | grep <process-name> to find any running processes using port 8080, and then use the command kill <process-id> to stop them.
Start the new application: Run the command to start your new application, and verify that it is running on port 8080.
Verify permissions: Verify that your application has the necessary permissions to write to the log file by running the command ls -l /var/log/staging-api/error.log and checking the ownership and permissions.

When this breaks

Here are some common issues you may encounter when working with Git branches and tags:

Conflict between branches: If you make changes to the same file in two different branches, you may encounter conflicts when trying to merge the branches. To resolve conflicts, you can use the command git merge --abort to abort the merge, and then use the command git merge <branch-name> to retry the merge.
Tags not being pushed: If you create a new tag but it is not being pushed to the remote repository, you can use the command git push origin --tags to push the tags.
History not being displayed: If the history of your repository is not being displayed correctly, you can use the command git log --all to display all commits, including those on other branches.

What it costs

Using Git branches and tags can have some costs, such as:

Increased complexity: Working with multiple branches and tags can increase the complexity of your repository, making it harder to manage.
Merge conflicts: Merging branches can result in conflicts, which can be time-consuming to resolve.
Tag management: Managing tags can be time-consuming, especially if you have a large number of tags.

However, the benefits of using Git branches and tags, such as being able to work on multiple features independently and marking specific points in your repository's history, outweigh the costs.

In the interview

In an interview, you may be asked questions such as:

Can you explain the difference between a Git branch and a Git tag?
- A weak answer would be: "A branch is like a copy of the code, and a tag is like a label."
- A strong answer would be: "A Git branch is a separate line of development in the repository, allowing you to work on multiple features independently. A Git tag is a marker for a specific point in the repository's history, often used to mark releases or milestones."
How do you handle merge conflicts in Git?
- A weak answer would be: "I just use the command git merge --abort to abort the merge."
- A strong answer would be: "I use the command git merge --abort to abort the merge, and then use the command git merge <branch-name> to retry the merge. I also use tools such as git diff to identify the conflicts and resolve them manually."

Your tasks

Create a new branch: Create a new branch for a feature you want to work on, and switch to that branch.
Make changes and commit: Make some changes to your code and commit them to the new branch.
Push the branch to the remote repository: Push the new branch to the remote repository.
Merge the branch: Merge the new branch into the main branch, and resolve any conflicts that arise.
Create a new tag: Create a new tag for a release or milestone, and push it to the remote repository.

Note: These tasks are designed to be completed in a real-world scenario, and may require additional setup and configuration depending on your specific environment.

Your tasks this week

Do the exercises above before the next chapter. Reading a tutorial and doing
one are different activities and only one of them changes what you can build.

Stuck on any of them? Say so — describe what you tried and what happened:
tell me where you got stuck. I read every one, and the questions
that come back more than twice get answered in the next chapter.

The DevOps bootcamp

Chapter 4 of 14. New chapter every Thursday morning.
Next: Containers: images, layers and why your build is enormous.

· The full syllabus and every chapter so far
· Subscribers also get the condensed notes for this chapter, the running
recap of everything the series has covered, and the extended guidance:
subscribe

Written by Amit Chakraborty — founding engineer and senior architect: React Native, AI and RAG systems, production architecture. Portfolio · LinkedIn · GitHub.

Need this built, reviewed or taught to your team? Get in touch or email amit@devamit.co.in. Available for senior and founding engineering roles, consulting and training, remote worldwide.