Mastering Git for DevOps: From Acquaintances to Collaborators

💻 - Git Week 2 Day 2 – Branching & Comparing Changes After learning how to set up Git and make my first commits, today I focused on branching — one of the most powerful features of Git that allows you to experiment, develop, and test new ideas without touching your main project timeline. ⸻ 🌿 Creating and Viewing Branches • git branch branch-name — creates a new branch. • git branch — lists all branches and shows which one you’re currently on (* marks the active branch). • By default, this is usually master (or main). ⸻ 🔄 Switching Between Branches • git checkout branch-name — switches to an existing branch. • git switch branch-name — does the same thing but with a newer, cleaner command. Create and switch in one step: • git checkout -b branch-name • or • git switch -c branch-name This creates a new branch and immediately moves you into it — perfect for starting a new feature or experiment. ⸻ ⚖️ Comparing and Merging Branches To compare your new branch with the main one: • git diff master — shows the differences between your branch and the main timeline. When your work is ready to be merged back into the main branch: • git merge branch-name — merges your branch changes into master (or main). To see which branches have already been merged: • git branch --merged To delete a branch: • git branch -d branch-name — deletes it safely (if merged). • git branch -D branch-name — force deletes it (even if unmerged). To see all branches, including remote ones: • git branch -a ⸻ Branching helped me understand how developers collaborate and work on multiple features at once without affecting the main project. It’s like creating alternate timelines that can later be merged back into the main storyline — a perfect analogy for version control. ⸻ Next Up: I’ll be learning how to: • Ignore files using .gitignore. • View changes using git diff. • Unstage files with git restore –staged. If you’re following my DevOps journey, stay tuned as I continue learning and applying version control in real-world projects 🚀 #Git #DevOpsJourney #VersionControl #CloudComputing #GitHub #LearningInPublic

Here’s the tool that saved me from a thousand merge conflicts… GIT Not glamorous, but if you work with teams managing code, it’s non-negotiable. Working with a dev team on a project. Multiple people, same files, chaos. Code disappeared. Nobody knew what version was current. Then Git came along and solved it. We could push to different branches without altering previous changes. Track every modification. Roll back instantly. What Git Does: Git is a time machine for your code. Every change tracked. Every version saved. Multiple people working simultaneously without conflicts. GitHub is where Git projects live the cloud-based home for your repositories. Free account. Unlimited public repos. See my GitHub profile for real projects I’ve built. You don’t need to be a developer. But if you work with tech teams, understanding Git changes everything: • Follow what your team is actually doing • Track project progress through commits • Understand deployment timelines • Coordinate better because you speak their language. Essential Git Commands: ✅git init — Start new repository ✅git clone — Copy a project ✅git fork — Create your own copy ✅git add . — Stage changes ✅git commit -m "message" — Save changes ✅git push — Send to repository ✅git pull — Get latest updates ✅git branch — Create different branche ✅git merge — Combine change ✅git status — Check file changes ✅git log — See commit history That’s 90% of what you need. First time was terrifying. Thought I’d break something. Then I realized that Git is designed so that : Every change is trackable. Everything can be undone. If You Work With Tech Teams, Learn Git basics. It’s free. You’ll instantly be more valuable because you can actually follow technical conversations. Have you used Git? Drop your experience below or DM if you want a starter guide. Day 13/20 ✅ #20DaysToShine #Git #GitHub #DevOps #TechSkills #ExecutiveAssistant #CloudComputing

🧠 “Git it right, or get lost in commits 😅” Every DevOps engineer has faced it — that “wait, which branch am I even on?” moment 😭 Let’s be honest — Git isn’t just a tool... it’s a superpower 💪 that can either save your project or break your sleep schedule 😂 Here’s a quick refresher from my Git cheatsheet (the one every DevOps engineer should keep pinned somewhere 👇): 🔹 git init — start fresh, new repo who dis 🔹 git add . — stage your chaos 🔹 git commit -m "fixed everything" — we all know that lie 😜 🔹 git branch — see your clones 🔹 git checkout -b feature/fix — your safe sandbox 🔹 git merge — where the real drama begins 🔹 git push origin main — the final move 🫡 🔹 git revert HEAD — your time machine back to sanity 🔹 git log --oneline — the story of your mistakes 😂 💡 Remember: “Git keeps your past, even when you try to forget it.” And that’s what makes it one of the most powerful tools in the DevOps world 🌍 So next time you hit git commit, do it with confidence — and maybe a little prayer 🙏 💬 Tell me in the comments: 👉 What’s the funniest or scariest Git command you’ve ever run? 👉 Ever had a git push -f moment that went horribly wrong? 👀 Let’s share some Git horror stories and lessons 😂👇 #Git #GitHub #DevOps #VersionControl #CICD #CloudEngineering #SoftwareDevelopment #CodingHumor #GitCommands #DevelopersLife #GitCheatSheet #GitTips #DevOpsEngineer #CloudNative #Automation #TechCommunity #CodeLife #SoftwareEngineering #LearningInPublic #DevOpsCommunity #PlatformEngineering #EngineeringExcellence #ProgrammingLife #GitOps #GitWorkflow #CloudComputing #DeveloperExperience #InfraAutomation #DevOpsTools #SourceControl #DevSecOps #Linux #GitBasics #CloudJourney

Imagine working on a new feature without the fear of breaking your entire project - that’s the power of Git branches. Day 28 of My DevOps Journey – I'm not here to teach about Git or say much because I could have skipped this part, more because I do this almost everytime as a developer, but I wanted to see if there was something else I could pick out theoretically just in case because learning is continuous. And then also because it is very fundamental to my learning journey. And so I'm not sure before now, I have actually interacted much with Rollbacks.... But it felt good going over it. Before now, I'd already know that a branch in Git is like a safe playground where you can experiment. You can create, switch, and work on new ideas without affecting the main project. But what I wasn't very familiar with is the git rollback commands - Because mistakes happen! Git gives you the freedom to undo, reset, and restore your project to any point in time. git reset --soft HEAD # Undo commit, keep changes staged git reset --hard HEAD # Undo commit and discard changes Today really showed me how version control gives developers freedom without fear. You can build, break, roll back, and try again - without losing progress. #DevOps #Git #Day28 #WomenInTech

My Git learnings & experiments Hey LinkedIn — I spent time today revisiting Git fundamentals and ran a few hands-on experiments. Here’s the cleaned-up, practical summary of what I learned and why it matters 🔧 Repo setup — the basic flow Commands I ran and why: # create a repo locally cd <your-directory> git init # stage everything git add . # rename (or set) the main branch git branch -M main  # renames current branch to "main" (or creates it if not present) # create first commit git commit -m "first commit on branch main" # push to remote and set upstream git push -u origin main Notes: main is a convention (a modern replacement for master) — you can name the branch anything, but main is commonly used for clarity and inclusiveness. git push -u origin main sets the upstream so future git push works without specifying branch. 🧠 Staging, commits, and branch context — key clarifications A few important details I confirmed by practicing: git add stages changes into the index (the staging area) which is repository-wide — not “attached to a branch” in a direct sense. Commits are created on whichever branch your HEAD currently points to. So: If you are on feature and run git commit, the commit belongs to feature. Pushing what ends up on the remote branch depends on which ref you push. Common gotcha I clarified: git push origin main attempts to push your local branch named main to origin/main. If you want to push the current branch to the remote main branch, you must explicitly push your current HEAD to that ref, e.g.: # push current branch to remote branch named main git push origin HEAD:main That command updates origin/main with the commits from your current branch (HEAD). This explains why changes can appear on main even when you were “on” another branch — because the push target was explicitly set to main. Takeaway: Always double-check git status, git branch, and the exact git push refspec you use before pushing to protected branches like main. #Git #GitCommands #VersionControl #DevOps #SoftwareEngineering #CodingJourney #LearningInPublic #100DaysOfCode #TechLearning #ProgrammersLife #DeveloperTools #SoftwareDevelopment #CodeNewbie #EngineeringExcellence #TechCommunity

🧰 Essential Git Commands Every DevOps Engineer Uses Daily Git isn’t just about commits — it’s about control, traceability, and teamwork. Here are some commands that keep every DevOps pipeline flowing smoothly 👇 💡 Daily Git essentials: git clone <repo> # Copy a repository git status # Check changes git add . # Stage everything git commit -m "Message" # Save your work git push origin main # Share with the world git pull origin main # Get latest updates git log --oneline --graph # Visualize commit history git diff # See what changed git stash / git stash pop # Save or restore temporary work git checkout -b <branch> # Create & switch branch Small commands. Big impact. 🚀 Because in DevOps, version control = peace of mind. 😌 #Git #DevOps #VersionControl #GitHub #Coding #OpenSource #TechEducation #DeveloperTools

Most engineers use Git daily, but how many truly *master* it? 🧐 As we transition into senior roles, our relationship with foundational tools like Git evolves from mere usage to strategic command. It's no longer just about `commit` and `push`; it's about understanding the fabric of our codebase's history and ensuring its integrity. For a senior engineer, Git mastery means: * **Architectural Clarity:** Using `rebase` to maintain a clean, linear project history, making future refactoring and debugging significantly easier. This isn't just a preference; it's a strategic choice for system health. * **Efficient Debugging:** Leveraging `git bisect` to pinpoint the exact commit that introduced a bug, drastically cutting down investigation time and proving critical technical ownership. * **Complex Scenario Navigation:** Proficiently using `cherry-pick`, `reflog`, and even `git submodules` or `worktrees` for managing intricate project dependencies or experimental branches without disrupting core development. * **Mentorship & Standards:** Guiding teams on advanced Git workflows, establishing best practices for merge strategies, and fostering a culture of clean, maintainable version control. This depth of understanding isn't just a technical flex; it directly translates to increased team productivity, reduced technical debt, and robust system stability—hallmarks of impactful engineering leadership. What's your most underutilized Git command or advanced workflow that has saved your day? Share your insights! 👇 #SoftwareEngineering #TechLeadership #SeniorEngineer #DevExcellence #CareerGrowth #EngineeringTrends #SystemDesign #DeveloperLife #CodeToLead #GitMastery

🚀 Understanding the Staging Area in Git If you’ve ever worked with Git, you’ve probably come across the term **“staging area”** — but what exactly does it do? 🤔 Think of Git as a **three-step workflow**: 1. **Working Directory** – where you make changes to your files. 2. **Staging Area (Index)** – a middle ground where you prepare specific changes for your next commit. 3. **Repository** – where committed snapshots are stored permanently. 💡 **The staging area** acts like a “preview” zone. It lets you: * Review and control what changes go into your next commit. * Commit only part of your edits instead of *everything* you’ve modified. * Keep your history clean and meaningful. Example: git add file1.js # Moves changes to the staging area git status # Shows what's staged and what's not git commit -m "Fix login bug" # Commits only the staged changes In short — the staging area gives you **precision and flexibility**. Instead of saving every change, you decide exactly what story your next commit tells. 📖 How do *you* use the staging area in your Git workflow? Do you commit often, or batch your changes? #Git #VersionControl #SoftwareDevelopment #DevOps #CodingTips #GitBasics

Day 35 of #100DaysOfDevOps — Wrapping Up Git with Git Hooks! Today marked the final Git lesson in my DevOps journey so far — and it was all about Git Hooks What I did: Merged a feature branch into the master branch Created a post-update hook that automatically creates a release tag (e.g., release-2025-10-25) whenever changes are pushed to the master branch Tested the hook and verified the tag creation This was the perfect way to end the Git series — automating tasks at the repo level to ensure smooth CI/CD workflows Quick Recap of What I’ve Learned in Git So Far: ✅ Initializing and cloning repositories ✅ Staging, committing, and pushing changes ✅ Working with branches and merges ✅ Reverting and resetting commits ✅ Using stash to save temporary work ✅ Rebasing for a clean linear history ✅ Resolving merge conflicts ✅ Cherry-picking specific commits ✅ Setting up Git Hooks for automation Git has been a powerful foundation for version control and collaboration — next up, we dive into Docker, where we’ll start containerising applications! #100DaysOfDevOps #DevOps #KodeKloud