From Tester to DevOps: My Git & GitHub Journey + Why Branching Strategy Matters

Transitioning from a Software Tester to a DevOps Engineer is like switching gears in your tech career. One of the first tools I mastered in this journey was Git and GitHub—and let me tell you, understanding how code is versioned, branched, and merged changed how I think about collaboration and delivery forever.

This blog is a practical walkthrough of what I’ve learned so far, including good branching strategies, real Git commands, and key differences between Git and GitHub.

---

🧠 What is Git?

Git is a distributed version control system. It tracks every change made to your codebase so you can easily collaborate, experiment, and roll back when needed.

🧠 What is GitHub?

GitHub is a cloud-based hosting platform built on top of Git. It allows teams to manage Git repositories, collaborate via pull requests, issues, and automate workflows.

---

🔁 Git vs GitHub (Quick Look)

---

🧪 Commands I Practiced (Beginner to Intermediate)

# 1. Initialize a repo
git init

# 2. Check untracked files
git status

# 3. Add file(s) to staging
git add <filename>

# 4. Check changes in file
git diff

# 5. Commit changes
git commit -m "your message"

# 6. Push changes to remote
git push

# 7. View commit history
git log

# 8. Go back to a previous state
git reset --hard <commit_id>

# 9. Clone a repository
git clone <repo_url>

---

🌿 Git Branching — Why It Matters

Branching allows you to work on isolated features or fixes without affecting the main codebase.

📌 Commands I Used to Work with Branches:

# Create a new branch
git branch <branch_name>

# Create and switch to a new branch
git checkout -b <branch_name>

---

✅ Understanding a Good Branching Strategy

A good branching strategy makes teamwork easier, prevents conflicts, and ensures clean, maintainable code history. Here’s a breakdown:

🏷️ Common Branch Types:

• main / master: Always production-ready.

• develop: Integration branch where features are merged before going live.

• feature/*: For new features.

• bugfix/*: For fixing issues in develop.

• hotfix/*: For urgent fixes directly on main.

🚀 Why You Need a Branching Strategy:

• It reduces merge conflicts.

• Helps manage parallel development.

• Keeps the main branch clean and deployable.

• Makes code reviews easier.

🛠️ Example Strategy (Used at Scitara & many companies):

main → deploys to production
develop → active development branch
feature/xyz → new features branched from develop
hotfix/abc → urgent fix branched from main

---

🔄 Merge Methods I Explored

There are multiple ways to bring code from one branch to another. Here’s what I practiced:

1. Git Merge

Keeps both histories intact and creates a merge commit.

git checkout main
git merge feature/xyz

2. Git Rebase

Linear history, rewrites commits.

git checkout feature/xyz
git rebase main

3. Git Cherry-Pick

Picks specific commits from one branch to another.

git cherry-pick <commit_id>

✅ I used cherry-pick when I wanted just one commit from my Division branch into main.

---

🧠 Git Log & Commit Exploration

Once I committed changes, git log showed:

• Author details

• Commit hashes

• Messages and timestamps

This became super helpful when I used git reset --hard to revert to a previous state. It’s like a time machine for your code!

---

📂 Git Clone vs Git Fork — What’s the Difference?

---

🖥️ Bonus: Show Hidden Files (Linux)

To see hidden .git/ folder:

ls -la

---

💬 Final Thoughts

If you're transitioning to DevOps like I am, learning Git isn't optional—it’s foundational. Start with basic commands, understand the importance of branches, and embrace a good strategy that suits your team or project.

This journey is exciting, and I’ll be sharing more as I go deeper into CI/CD, Docker, AWS, and more.

---