Gideon Bature’s Post

🧹 Day 13 – “Git Cleanup Crew – Keeping Your Repo Clean & Deployment-Ready 🧼💻” A messy Git repo is like a messy kitchen… you can cook, but you’ll suffer while doing it. 😂 Today’s toolkit is all about cleaning, ignoring, tagging, and maintaining your codebase — just like a true DevOps engineer. 🚮 .gitignore – The Gatekeeper This file decides what should never enter Git. Logs, temp files, build artifacts — keep all that junk out. Add it once. Your repo stays clean forever. Use case: Exclude unwanted files/folders from Git tracking. 💡 DevOps tip: Use https://gitignore.io to generate perfect templates. 🧽 git clean -fd – The Deep Cleaner Deletes all untracked files and directories in seconds. “Are these files important?” Git: Nope. DELETE. 😂 Use case: Remove leftover files after merges, builds, or experiments. ⚠️ Be careful: This permanently deletes files — no recycle bin! 🏷️ git tag -a v1.0 -m "Release 1.0" – The Bookmark Tags important points in history like releases, milestones, rollbacks. “This is the version we deployed to production!” Use case: Mark stable releases and deployments. 💡 Pro tip: git push --tags to push all your tags to remote. 🔧 git fsck – The Repo Doctor Scans your repository and reveals issues like missing objects or corrupt data. It’s like a health checkup for Git itself. Use case: Validate repo integrity; essential in large, long-running projects. 💡 Pro tip: Run this in old monolithic repos — you’ll be shocked. 🗑️ git gc – The Garbage Collector Reclaims space, removes unused objects, and optimizes the repo. Think of this as clearing cache + vacuuming + healing broken commits. 😅 Use case: Make your repo smaller, cleaner, faster. 💡 Pro tip: git gc --aggressive for deeper optimization (use less often). 💬 Moral of the Story A clean repo = faster deployments + fewer surprises + happier DevOps engineers. 😎 Your Cleanup Crew: .gitignore → Stop junk at the door git clean → Remove untracked mess git tag → Mark milestones git fsck → Check repo health git gc → Optimize everything Treat your Git repo like production — keep it clean. 💯 ❓ Your Turn What’s the worst kind of file you’ve accidentally pushed before the .gitignore era? 😅 .env? node_modules? 400 MB zip file? Confess below 👇

Day 14 – “Git Week Wrap-Up – The 14-Minute Guide Every DevOps Engineer Should Know 💻✨” After 7 days of digging through Git commands, merges, stashes, conflicts, logs, and cleanups… one thing becomes clear: Git isn’t just a tool — it’s your project’s memory. Today’s post is a simple, no-nonsense recap of everything we mastered this week. If someone wants a one-page Git guide, this is it. 🧱 1. Starting the Project (Day 8) Commands: git init, git status, git add, git commit, git log Theme: Every repo starts with a heartbeat — your first commit. Why it matters: This is Git’s foundation. If you understand these five, you understand 50% of Git already. 🌿 2. Branching & Collaboration (Day 9) Commands: git branch, git checkout, git merge, git diff, git log --graph Theme: Git branching = teamwork + separation of responsibilities. Why it matters: Teams scale only when code can move independently and merge smoothly. 🌐 3. Remotes & Syncing (Day 10) Commands: git clone, git remote, git fetch, git pull, git push Theme: Your local repo is only half the story — GitHub is the other half. Why it matters: Modern DevOps = distributed teams + shared repos. Remote syncing is the backbone. 💥 4. Merge Conflicts & Recovery (Day 11) Commands: git merge, git diff, git stash, git restore, git reset Theme: Git isn’t confusing — communication is. Why it matters: Conflicts happen. Knowing how to solve them saves time, nerves, and releases. 🕵️ 5. Debugging & Investigating (Day 12) Commands: git blame, git show, git reflog, git bisect, advanced logs Theme: Sometimes you don’t debug code — you debug history. Why it matters: Faster root cause = faster fixes = fewer late-night on-call moments. 🧹 6. Repo Maintenance (Day 13) Commands: .gitignore, git clean, git tag, git fsck, git gc Theme: Clean repos deploy better. Why it matters: A healthy repo = reliable builds, smoother CI/CD pipelines, and smaller artifacts. 🎯 Moral of the Week Git isn’t about memorizing commands. It’s about developing intuition: When to commit When to branch When to merge When to debug When to clean Master this intuition → you become unstoppable in any DevOps role. 🚀 ❓ Your Turn After 14 days of Linux + Git… Which Git command finally “clicked” for you this week? Share your favorite one below 👇

💻 - Git Week 2 Day 5 & 6 – Merging, Conflicts & Git Workflows This week, I focused on one of the most important parts of Git: merging branches and managing conflicts — the kind of real-world challenges that happen when multiple developers work on the same project. I also learned about common Git workflows used in DevOps teams to keep collaboration smooth and organised. ⸻ 🔀 Merging Branches After working on a feature or fix in a separate branch, you can merge it back into your main branch (usually master or main): git checkout master git merge feature-branch If everything goes smoothly, Git combines the changes automatically and creates a merge commit. To see which branches have already been merged: git branch --merged Once merged, you can delete the branch to keep things clean: git branch -d feature-branch ⚠️ Handling Merge Conflicts Conflicts occur when two branches edit the same part of a file differently. When this happens, Git pauses the merge and marks the conflicting sections like this: <<<<<<< HEAD Your version of the code ======= The other branch’s version >>>>>>> feature-branch To fix it: 1. Open the file and decide which version (or combination) to keep. 2. Remove the conflict markers. 3. Stage the file again with git add file. 4. Finish the merge with: git commit You can also use GUI tools like VS Code, GitHub Desktop, or GitKraken to resolve conflicts visually. ⸻ 🧩 Understanding Git Workflows 1️⃣ Feature Branch Workflow Each new feature or bug fix happens on its own branch. Once tested, it’s merged back into the main branch via a pull request — keeping main always clean and deployable. 2️⃣ Forking Workflow Used in open-source projects — you copy (fork) someone’s repo, make changes in your own version, then submit a pull request to merge it back into the original. 3️⃣ Gitflow Workflow A structured model with dedicated branches for features, releases, and hotfixes — used in larger teams to manage parallel development efficiently. ⸻ Learning how to merge confidently and handle conflicts made me realise Git is less about avoiding mistakes and more about managing collaboration safely. 🚀 Next Up: Advanced Git Tools & Bash Scripting I’ll be wrapping up my Git learning by briefly exploring: • Rebasing – keeping commit history clean and linear • Stashing – saving temporary work • Tags – marking specific versions • Cherry-picking – copying a single commit • Reverting – safely undoing changes • SSH keys – connecting securely to GitHub Then I’ll begin Bash scripting, where I’ll learn how to automate Linux tasks and build scripts to support DevOps workflows. #Git #GitHub #DevOpsJourney #VersionControl #LearningInPublic #CloudComputing #Bash

💻 - Git Week 2 Day 1 – Understanding Git & GitHub Today marks the start of Week 2, where I begin my journey into Git and Version Control — the backbone of modern DevOps collaboration. 🧠 Git vs GitHub • Git is a version control system — a tool that tracks changes to your code locally on your computer. • GitHub is a cloud-based hosting platform for Git repositories — where developers store, share, and collaborate on projects online. In short, Git is the tool, GitHub is the platform. ⸻ 🧩 Starting a Repository • git init — creates a new Git repository (a new timeline for your project). • git status — shows what’s happening right now in that timeline. When I first ran git status, I saw: On branch master No commits yet Nothing to commit Here’s what that means: • Branch master = your main timeline. • No commits yet = you haven’t created a save point yet. • Nothing to commit = there are no changes for Git to record. ⸻ 📂 Tracking Changes When you add a new file, Git notices it but marks it as untracked — it knows the file exists but isn’t monitoring it yet. To track it: • git add file — adds that specific file. • git add . — tracks all files in the current directory. Once files are staged, you can commit them (make a save point): • git commit -m "Initial commit" — commits the staged files and adds a short description of the change. To view your history of commits: • git log — shows all your save points (commits) in order. ⸻ ⚙️ Git Configuration & Identity Setup Git has three levels of configuration (or “dimensions” as I like to think of them): 1. System level – applies to every user on the system. 2. Global level – applies to all repositories for your user account. 3. Local level – applies only to the specific repository. View your settings: • git config --list Set your identity: git config --global user.name "Your Name" git config --global user.email "your@email.com" Other useful configurations: • git config --global color.ui auto → adds colour to command output. • git config --global core.editor [editor] → sets your preferred text editor. • git config --global core.autocrlf input → helps sync files correctly across systems. ⚡ Shortcuts & Aliases Create shorter custom commands for faster use: For example, git config --global alias.st status. Now git st. 🧭 The difference between: • git config --global user.name → global (applies everywhere). • git config user.name → local (applies only in the current repo). Today’s session was all about setting up Git, understanding how it works, and creating your first commits — essentially learning how to control time in your codebase. Next Up: I’ll be exploring how to: • Ignore files using .gitignore (like logs or environment files). • View changes using git diff. • Unstage files with git restore –staged. If you’re following my DevOps journey, connect and keep learning with me 🚀 #Git #DevOpsJourney #VersionControl #CloudComputing #LearningInPublic

💻 - Git Week 2 Day 7 – Advanced Git Tools & Final Wrap-Up As I wrap up my second week of the DevOps journey, I explored some of the advanced Git commands and tools that make version control more powerful, flexible, and reliable in real-world environments. These are the commands that help developers clean up history, undo mistakes, and manage changes efficiently — especially in team-based projects. ⸻ 🧠 1️⃣ Rebasing vs Merging • git rebase rewrites commit history to make it linear and clean. • It’s best used for your local feature branches, while merging is safer for shared branches. Example: git rebase master This moves your branch commits on top of the latest commits from master. 💾 2️⃣ Stashing Sometimes you’re in the middle of work and need to switch branches — but don’t want to commit unfinished changes. git stash Temporarily stores your modifications so you can come back to them later. Restore them with: git stash pop 🏷️ 3️⃣ Tags & Releases Tags mark specific commits as version points (like v1.0 or v2.0): git tag v1.0 git push origin v1.0 They’re great for releases or snapshots of stable versions in production. ⸻ 🍒 4️⃣ Cherry-Picking If you need one specific commit from another branch without merging the entire branch: git cherry-pick [commit-id] This copies just that commit into your current branch. ⏪ 5️⃣ Undoing & Reverting Changes • git revert [commit-id] safely undoes a commit by creating a new one that reverses its effects. • git reset --hard [commit-id] rolls back your repository to a previous commit, use carefully as it changes history. 🔒 6️⃣ SSH Authentication Instead of entering your username and password each time you push or pull, you can connect to GitHub securely using SSH keys: ssh-keygen -t rsa -b 4096 -C "your@email.com" Add the public key to GitHub → Settings → SSH and GPG Keys. This makes Git operations faster and more secure — especially when automating with scripts or CI/CD pipelines. 🧩 Final Thoughts on Git & GitHub Over these seven days, I’ve learned how to: ✅ Initialise and configure Git ✅ Manage commits and branches ✅ Handle merges and conflicts ✅ Sync repositories with GitHub ✅ Explore advanced tools for clean version control Git has become a tool I can now use confidently to track, collaborate, and maintain cleaner project histories, a key foundation for every DevOps engineer. ⸻ Next Up: I’ll be diving into Bash scripting such as learning how to automate Linux commands, handle input/output, and build scripts to support real DevOps workflows. #Git #GitHub #DevOpsJourney #VersionControl #LearningInPublic #Bash #CloudComputing

⚙️ Git Workflow 1️⃣ Initialize Git git init Creates a hidden .git folder to track changes. Check it using: ls -la 2️⃣ Check Repo Status git status Shows if files are tracked, untracked, or committed. 3️⃣ Add Files git add filename Adds files to the staging area for tracking. Add all files: git add . 4️⃣ Commit Changes git commit -m "Added new feature" Saves a checkpoint with your message. 5️⃣ View Changes git diff # Show modifications git log # Show commit history 6️⃣ Undo or Go Back git reset --hard <commit-id> Goes back to a specific commit version. 🚀 Push Code to GitHub Steps: Create a GitHub account. Create a new repository. Connect local repo to GitHub: git remote add origin <repo_URL> Push your code: git push -u origin main 🔄 Pull and Fetch git pull Fetch and merge latest changes from remote git fetch Fetch updates but don’t merge automatically Use pull to get updates + merge. Use fetch when you just want to see new updates before merging. ⚙️ .gitignore File .gitignore tells Git which files to ignore while tracking. 🌿 Git Branching Strategy Why Use Branches? To work on new features or bug fixes without breaking main code. Makes teamwork smoother and organized. Common Branch Types Main / Master Branch: Always stable and production-ready. Feature Branch: Used to develop new features. Release Branch: Used for preparing code for deployment. Hotfix Branch: Used for urgent fixes in production. 🔄 Branch Commands git branch # List all branches git checkout -b feature1 # Create and switch to new branch git checkout main # Switch back to main branch git merge feature1 # Merge feature branch into main 🔁 Merge, Rebase, and Cherry-Pick 🔸 Merge Combines code from one branch into another. Keeps all commit history. 🔸 Rebase Rewrites commits in a straight line (clean history). Commonly used in professional DevOps workflows. 🔸 Cherry-Pick Pick a specific commit from one branch to another: git cherry-pick <commit-id> 👥 Pull Requests (PR) Used on GitHub when one branch wants to merge into another. Allows code review and approval before merging. Ensures quality and teamwork. 🧩 Example Git Workflow in Real Projects Developer creates a feature branch → works on code. Runs tests and commits changes. Pushes the branch to GitHub. Opens a Pull Request (PR) for review. Once approved → merged into main branch → deployed. Done😎 😎 #GitGithub #Devops

Today’s session with CloudDevOpsHub under the guidance of Vikas Ratnawat was packed with hands-on learning! I explored and practiced 20+ Git commands — from repository setup to code versioning and collaboration. Here’s what I learned and what each command actually means in simple terms: echo "# day-2-devops" >> README.md → Creates a new README file with the project name. git init → Starts a new Git repository in the current folder. git status → Shows what’s changed, what’s staged, and what’s not. git add README.md → Adds the README file to the staging area (prepares it for commit). git add . → Adds all modified or new files for commit. git commit -m "first commit" → Saves the staged changes with a message. git branch -M main → Renames the default branch to “main”. git remote add origin <repo-link> → Connects your local repo to a remote GitHub repository. git push -u origin main → Pushes your commits to GitHub for the first time. git clone <repo-link> → Copies an existing repo from GitHub to your system. git pull → Fetches and merges the latest changes from GitHub. git config --global user.name "<your name>" → Sets your global Git username. git config --global user.email "<your email>" → Sets your global Git email ID. git remote → Displays the connected remote repositories. git branch <branchname> → Creates a new branch for feature or fix development. .gitignore → Tells Git which files/folders to ignore (like credentials, logs, etc.). git rm file1.txt → Removes a file from the repo and prepares that removal for commit. git log → Shows the history of commits made in the repository. git log -p -2 → Displays detailed changes (patches) for the last two commits. git reset HEAD <filename> → Unstages a file that was added by mistake. Each command made me realize how powerful Git is — it’s not just version control, it’s the foundation of every DevOps workflow. Big thanks to Vikas Ratnawat and Cloud DevOps Hub for the clear, practical, and energetic teaching style. The pace, hands-on tasks, and real-world context made Git feel natural to use. Feeling confident that I can now handle almost all DevOps operations related to Git with ease 💪 #DevOps #Git #LearningJourney #CloudDevOpsHub #VikasRatnawat #ContinuousLearning #AWS #Cloud #VersionControl

🚀 Writing Your First Jenkinsfile — A Complete Beginner’s Guide! If you’re getting started with Jenkins, one of the most powerful DevOps automation tools, the first big step is learning how to write a Jenkinsfile — the backbone of your CI/CD pipeline. Let’s break it down 👇 🧩 What is a Jenkinsfile? A Jenkinsfile is a text file that defines your entire build pipeline — from building and testing your code to deploying it automatically. It uses a Groovy-based DSL (Domain-Specific Language) and can be stored right inside your project repo. This means your CI/CD pipeline becomes code — versioned, auditable, and easy to maintain. 💡 ⚙️ Why You Should Use a Jenkinsfile ✅ Keeps your CI/CD configuration in version control (Git). ✅ Enables collaboration — everyone can review pipeline changes via pull requests. ✅ Reduces manual setup on the Jenkins UI. ✅ Makes pipelines portable and reproducible. 🧱 Two Pipeline Types 1️⃣ Declarative Pipeline (Recommended) Simpler, structured, and beginner-friendly. Written using the pipeline {} syntax. 2️⃣ Scripted Pipeline Based on Groovy scripting — highly flexible, but more complex. Great for advanced users or dynamic pipelines. 🧠 Best Practices for Jenkinsfiles ✅ Keep Jenkinsfiles in the root of your repo. ✅ Use Declarative Pipelines unless you need dynamic logic. ✅ Define environment variables with environment {} blocks. ✅ Store secrets securely using Jenkins Credentials — never hardcode passwords! ✅ Use post blocks for cleanup or notifications. ✅ Modularize — use shared libraries for reusable pipeline code. 💡 Pro Tips & Tricks 🔹 Use when conditions to skip unnecessary stages (e.g., only deploy on main branch). 🔹 Add Slack or email notifications for build status. 🔹 Use agent { docker { ... } } to run your pipeline inside Docker containers. 🔹 Combine with GitHub or GitLab hooks to trigger builds automatically on every push. 🔹 Implement parallel stages to speed up builds (e.g., run tests in parallel). 🧭 Quick Debugging Guide Use echo generously to log progress. Check Blue Ocean view for better visualization. Validate your Jenkinsfile using the Jenkinsfile Runner or the Jenkins web UI (“Pipeline Syntax” generator). 📘 In Short A Jenkinsfile brings your automation to life. It’s not just code — it’s the bridge between your developers and production systems. Start simple, version it, and evolve it as your project grows. 💬 Your Turn: What was the first pipeline you ever built? Share your Jenkins journey or challenges below — let’s learn together! 👇 🧠 Read more: https://lnkd.in/g6c96adg #Jenkins #DevOps #CICD #Automation #JenkinsPipeline #Jenkinsfile #GitOps #Cloud #Engineering

🚀 Most Useful Git Commands Every DevOps Engineer Should Know Whether you’re starting your Git journey or brushing up for professional work, mastering these commands will boost your productivity and confidence. 1️⃣ Repository Management git init → Initialize a new repository git clone <repo> → Clone an existing repository git remote -v → View remote repository details git remote add origin <url> → Link local repo to remote 2️⃣ Staging & Committing git add <file> → Stage specific changes git add . → Stage all changes git commit -m "message" → Commit changes with a message git commit --amend → Edit the last commit 3️⃣ Branching & Merging git branch → List all branches git branch <branch> → Create a new branch git checkout -b <branch> → Create & switch to a branch git merge <branch> → Merge a branch into current branch git branch -d <branch> → Delete a branch git checkout <branch> → Switch to a branch 4️⃣ Viewing History & Changes git log → View commit history git log --oneline → View commit history in one line git diff → View unstaged changes 5️⃣ Undoing Changes git reset <file> → Unstage a file (changes remain) git restore <file> → Restore a file to last committed state git reset --hard <commit> → Reset branch to a commit, discarding local changes git revert <commit> → Create a new commit that undoes a previous commit 6️⃣ Remote Collaboration git push origin <branch> → Push changes to remote git pull origin <branch> → Pull changes from remote 7️⃣ Status Check git status → Shows current working directory and staging area status 💡 Pro Tip: Practice these commands daily. The more you use them, the more fluent you become in Git. These commands are the foundation for efficient version control in real-world DevOps workflows. Follow my #GitRevision journey for step-by-step Git tips, commands, and strategies! #Git #DevOps #VersionControl #GitCommands #CloudComputing #LearningGit #100DaysOfDevOps