Skip to content

DevOps Day 25: The Complete Git Feature Branch Workflow

Today's task was the most comprehensive Git workflow I've tackled yet. It simulated the entire lifecycle of a feature, from its inception on a new branch to its integration into the main project. This is the standard, professional way that development teams all over the world manage their codebases safely and collaboratively.

I had to create a new branch, add a new file to it, commit the changes, merge the branch back into master, and finally push all the new history to the central server. This exercise was a fantastic, hands-on demonstration of the core Git commands that make parallel development possible.

Table of Contents

The Task

My objective was to perform a full feature development cycle on a Git repository located on the Storage Server. The specific requirements were: 1. Work within the /usr/src/kodekloudrepos/official Git repository. 2. Create a new branch named datacenter from the master branch. 3. Copy a file, /tmp/index.html, into the repository. 4. Add and commit this new file specifically on the datacenter branch. 5. Merge the datacenter branch back into the master branch. 6. Push both the master and datacenter branches to the remote server (origin).

My Step-by-Step Solution

The process was a logical sequence of Git commands, all performed on the Storage Server. A key challenge was that the repository was in a root-owned directory, so every Git command required sudo.

Phase 1: Branching and Development

  1. I connected to the Storage Server (ssh natasha@ststor01) and navigated to the repository (cd /usr/src/kodekloudrepos/official).
  2. I used the git checkout -b shortcut to create the new datacenter branch and immediately switch to it. 
    sudo git checkout -b datacenter
  3. While on the datacenter branch, I performed the "development work": copying the new file, adding it to staging, and committing it. 
    # Copy the file into the current directory
sudo cp /tmp/index.html .

# Stage the new file for the next commit
sudo git add index.html

# Commit the staged file to the 'datacenter' branch history
sudo git commit -m "Add datacenter index file"

Phase 2: Merging and Pushing

With the feature complete on its branch, it was time to integrate it back into the main project. 1. First, I had to switch back to the master branch. This is a critical step before merging. 

sudo git checkout master
2. Next, I merged the datacenter branch into my current branch (master). 
sudo git merge datacenter
The output showed a "fast-forward" merge, indicating the changes were applied cleanly.

  1. Finally, I pushed all my local work (the new commit on master and the new datacenter branch itself) to the central remote server. 
    sudo git push origin master datacenter
    The output from the push command, showing that both branches were sent to the remote, was the final confirmation of success.

Why Did I Do This? (The "What & Why")

- The Feature Branch Workflow: This is the core concept. You never work directly on the master branch. The master branch is considered the stable, canonical version of the code. All new work is done on a separate "feature branch" to ensure the main codebase is always protected from work-in-progress, bugs, and experimental code. - git checkout -b: This is a very common command that combines two actions: git branch <name> (create a new branch) and git checkout <name> (switch to it). It's the standard way to start work on a new feature. - git merge: This command takes the independent lines of history from two branches and integrates them into a single branch. In my case, I was on master and ran git merge datacenter, which took all the commits from the datacenter branch and applied them to master. - "Fast-Forward" Merge: This is the simplest type of merge. It happens when the master branch has not had any new commits since the feature branch was created. Git can simply move the master pointer forward to the end of the feature branch, as if the commits were made directly on master. - git push origin <branch1> <branch2>: The push command is how you share your local commits with the team. By listing multiple branch names, I can efficiently send all my updates to the remote server in a single command.

Deep Dive: The Lifecycle of a Feature Branch

This task was a perfect demonstration of the entire lifecycle of a small feature, which can be visualized as a loop.

[Image of a Git feature branch workflow]

  1. Start from master: My starting point was the clean, stable master branch.
  2. Create a New Path (checkout -b datacenter): I created a separate, isolated path to do my work without affecting the main path.
  3. Do the Work (add, commit): I created the new feature (adding the index.html file) and saved my progress in a commit on my private path.
  4. Re-join the Main Path (checkout master, merge datacenter): Once my work was complete, I went back to the main master path and pulled in all the changes from my feature path, combining them.
  5. Publish Everything (push origin ...): I updated the central server with both the new state of the master branch and the history of the datacenter branch for my teammates to see.

This cycle of branching, developing, merging, and pushing is repeated for every new feature, bug fix, or change in a project, ensuring the master branch remains a reliable source of truth.

Common Pitfalls

- Forgetting sudo: In this specific lab environment, the repository was owned by root. Forgetting to use sudo for any of the Git commands that write data (checkout -b, add, commit, merge, push) would have resulted in a "Permission denied" error. - Merging in the Wrong Direction: A common mistake is to be on the feature branch and merge master into it. While this is useful for updating your branch with the latest changes from the team, it's not the correct way to finish a feature. The merge must be done while on the master branch. - Forgetting to Push Both Branches: If I had only pushed master (git push origin master), my new feature would be in the main codebase, but the datacenter branch itself would only exist on my local machine. Pushing both shares the complete history of the work. - Missing git config: If I hadn't configured my user name and email, the git commit command would have failed and asked me to identify myself first.

Exploring the Commands Used

- sudo git checkout -b datacenter: Checks out a new branch named datacenter and switches to it. - sudo cp /tmp/index.html .: Standard Linux command to copy a file into the current directory (.). - sudo git add index.html: Adds the specified file to the Git staging area, preparing it for the next commit. - sudo git commit -m "...": Creates a new commit with the staged files and attaches the specified message. - sudo git checkout master: Switches the working directory back to the master branch. - sudo git merge datacenter: Merges all commits from the datacenter branch into the current branch (master). - sudo git push origin master datacenter: Pushes the state of the local master and datacenter branches to the remote server named origin.