Git Stash & Release Tags for DevOps Engineers

📝 Day 5 of Sharing my DevOps Series... *Git Basics What is Git? Git is a distributed version control system used to: Track code changes Collaborate with teams Manage project history *Why Git is Used? Track code changes Maintain version history Work with multiple developers Rollback to previous versions Work in parallel using branches *Git Architecture Working Directory Where you create/edit/delete files Staging Area Middle layer between working directory & Local repository Stores changes before commit Git Repository Stores all versions, history & metadata Initialize repository git init Check status git status Add file to staging git add file.txt Commit changes git commit -m "First commit" *File States in Git Untracked → New file (not added) Modified → Changed but not staged Staged → Ready to commit *Commands ls # List files ls -a # Show hidden files mkdir folder # Create directory cd folder # Change directory *Git Commit Options git commit -m "message" # Normal commit git commit -am "message" # Add + commit (tracked files only) *What is a Branch? A branch in Git is used to work on features independently without affecting the main code. *List Branches git branch - Shows all available branches Create a New Branch - git branch dev Creates a new branch named dev *Switch Branch git checkout dev git switch dev Move from one branch to another Create + Switch (Shortcut) git checkout -b feature Delete Branch git branch -d dev Deletes branch (safe delete) git branch -D dev Rename Branch git branch -m old-name new-name Rename a branch View All Branches (Local + Remote) git branch -a *Git Logs git log # Full history git log --oneline # Short history *Remote Repository (GitHub) git remote add origin <repo_url> git push origin master- Push local commits to remote repository *main information about git: git init → Initialize repo git add → Stage changes git commit → Save changes git status → Check status git branch → Manage branches git merge → Combine branches git push → Upload to remote git clone → Copy repo #DevOps #CareerGrowth #Cloud #AWS #Infrastructure #CloudComputing #AWS #TechLearning #DevOps #LearningInPublic #TechJourney #git #github

Git in Real Life: When I started using Git, I thought it’s just for pushing code. But in real production environments, Git becomes the single source of truth. Let me share a real-world scenario Scenario: Production Issue One day, a critical service started failing after deployment. Everything looked fine in CI/CD, but users were facing errors. First step? Not logs… Git history. Using: git log --oneline We traced a recent commit where a config file was modified. Use Case: Root Cause Analysis We compared changes using: git diff <commit-id> Found that: - Environment variable was changed - API endpoint misconfigured A small change, but huge impact. Fix Strategy Instead of manually fixing, we rolled back safely: git revert <commit-id> git push origin main Production stabilized within minutes Daily Use Cases of Git in DevOps - Managing infrastructure code (Terraform, Kubernetes YAMLs) - Version controlling CI/CD pipelines - Tracking configuration changes - Enabling team collaboration - Supporting GitOps workflows Must-Know Commands (Real Usage) git clone <repo> git checkout -b feature-branch git add . git commit -m "feature update" git push origin feature-branch git pull origin main git merge main Troubleshooting Scenarios 1. Merge Conflict git pull origin main Fix conflicts manually → then: git add . git commit -m "resolved conflict" 2. Wrong Commit Made git reset --soft HEAD~1 3. Lost Changes git stash git stash apply 4. Check Who Changed What git blame <file> Key Learning Git is not just a tool. It’s your safety net, audit system, and collaboration engine. In production, debugging often starts from Git, not from code. Final Thought A single commit can: - Break production - Or save hours of debugging So always: Commit smart. Review carefully. Deploy confidently. #Git #DevOps #Troubleshooting #VersionControl #Cloud #Git Lab #MLOPS #devsecops

Day 10 of DevOps — Git Branching Strategy👨💻📈 A branch is a parallel version of your codebase. Let's a developer work on a new feature, a bug fix, or a major change in complete isolation without touching the code that is currently running in production. The main codebase stays stable. The new work happens separately. When it is ready and tested, it gets merged in. The four types of branches — and what each one is for $ Main / Master Branch: The primary branch. Always stable. Always production-ready. This is the source of truth for the current state of the product. Nobody commits experimental work directly here. $ Feature Branches: Short-lived branches created for a specific piece of work. When development is complete and tests pass, it gets merged back into main. Then it is deleted. Feature branches are not meant to live long. $ Release Branches: This one was new to me. > When a version is ready to ship, a release branch is cut from main. Final stabilisation and testing happen here and not on main. > The release goes to customers from this branch. Main continues moving forward with new development while the release branch is locked down for that version. > Let's say Shipping version 1.2 to customers while simultaneously building version 1.3 on main without the two interfering with each other.😮 $ Hotfix Branches: Also new to me.😦 > A critical bug is found in production. You cannot wait for the normal development cycle. > A hotfix branch is created directly from the release branch, the fix is applied, tested, and merged back into both the release branch and main. Production gets the fix fast. Main stays up to date. Coming from backend: I've used feature branches on every project. Main branch protection, PR-based merges, which is a standard practice. But I'd never used release branches or hotfix branches. Working solo on portfolio projects, I never needed them. One thing is for sure: You cannot ship new features and patch production bugs on the same branch. That's what release and hotfix branches solve.👍🏾 #DevOps #Git #BranchingStrategy #GitHub

Git isn't just a version control tool — it's the starting point of your entire delivery pipeline. Every CI/CD pipeline, every deployment, every infrastructure change begins with a Git event. A push, a merge, a pull request. Here are the Git commands that actually matter in DevOps: The daily basics: → git clone — copy a repo to your local machine → git pull — get the latest changes from remote → git add . — stage all changes → git commit -m " " — save your changes with a message → git push — send your changes to remote Branching: → git branch — list all local branches → git checkout -b name — create and switch to a new branch → git merge branch-name — merge changes from one branch into another Debugging and recovery: → git log --oneline — see commit history in a clean format → git diff — see exactly what changed between states. → git revert <commit> — undo a commit safely without rewriting history → git stash — temporarily save changes you're not ready to commit Status: → git status — Run git status constantly. It tells you exactly where you are, what's staged, what's not, and what branch you're on. It saves so much confusion. Understanding Git properly means understanding how the entire delivery process begins. What Git command do you wish you had learned earlier? 👇 #DevOps #Git #VersionControl #CICD #LearningDevOps #BeginnerDevOps #TechCareers #LearningInPublic

🚀 Git & GitHub – Essential Concepts Every DevOps Engineer Should Know Version control is the backbone of modern development. Whether you're working on Terraform, CI/CD, or cloud automation—Git & GitHub are must-have skills. 🔹 What is Git? Git is a distributed version control system that helps track changes, collaborate efficiently, and manage code across teams. 🔹 What is GitHub? GitHub is a platform built on Git that enables collaboration, code hosting, and version management. 📌 Key Concepts • Repository (Repo): Where your code lives • Commit: Snapshot of your changes • Branch: Parallel version of your code • Pull Request (PR): Way to propose and review changes ⚙️ Basic Git Commands ✔️ git init → Initialize a repository ✔️ git clone → Copy repo from GitHub ✔️ git add . → Stage changes ✔️ git commit -m "message" → Save changes ✔️ git status → Check repo state ✔️ git push → Upload changes ✔️ git pull → Fetch & merge updates 🌿 Branching & Merging ✔️ git branch → Manage branches ✔️ git checkout -b feature → Create & switch branch ✔️ git merge feature → Merge changes ✔️ git rebase main → Reapply commits cleanly 📦 Stashing & Cleaning ✔️ git stash → Save changes temporarily ✔️ git stash pop → Reapply changes ✔️ git clean -f → Remove unwanted files 🌍 Remote Repositories ✔️ git remote -v → View remotes ✔️ git fetch → Download updates ✔️ git remote add origin → Add repo 📊 History & Debugging ✔️ git log --oneline → View history ✔️ git diff → See changes 🏷️ Tagging & Releases ✔️ git tag v1.0 → Mark version ✔️ git push origin --tags → Push tags ⚠️ Advanced (Use Carefully) ✔️ git reset --hard → Remove commits ✔️ git revert → Undo safely ✔️ git rebase -i → Clean commit history 💡 Why Git Matters? ✔️ Better collaboration ✔️ Version tracking ✔️ Faster delivery ✔️ Safer deployments 📘 Based on core Git concepts and commands #Git #GitHub #DevOps #VersionControl #Cloud #Terraform #CI_CD #Automation #TechLearning

Git Series | Day 9: Optimization & Deployment — Squash, Cherry-Pick, and .gitignore 🚀 As I near the end of this series, I am focusing on the "polishing" tools that professional DevOps Engineers use to ensure their repositories are clean, secure, and ready for production. 1. Squash: Consolidating the Journey Why show 10 "work-in-progress" commits when one clean commit will do? Squash allows me to combine multiple commits into a single, meaningful entry. The Command: git rebase -i HEAD~number The Workflow: In the interactive editor, I keep the first commit as "pick" and change the others to "squash." The Benefit: It keeps the master branch history concise and high-level for senior reviewers. 2. Cherry-Pick: Surgical Precision Sometimes you don't want an entire branch; you just want one specific fix or feature. The Concept: Picking a single commit from one branch and applying it to another. The Command: git cherry-pick <commit-id> The Use Case: Great for pulling a critical hotfix from a development branch directly into production without bringing unfinished features along. 3. .gitignore: The Silent Guardian A professional repository should never contain logs, environment variables, or temporary build files. The Mechanism: By creating a .gitignore file, I tell Git which files to permanently ignore from tracking. Standard Exclusions: I typically exclude *.log, .env (security), and folders like /db or node_modules. The Result: Smaller repository size and zero risk of pushing sensitive credentials to GitHub. 4. Deployment: Hosting via GitHub Pages Git isn't just for tracking; it’s for delivering. I practiced hosting static web applications directly from a repository. Push your code to a new GitHub repository. Navigate to Settings > Pages. Select the master branch and save. Your application is live and accessible via a public URL! My use of .gitignore ensures that sensitive configuration data and "garbage" files never enter the version control system. I Streamline Code Reviews: By squashing messy development commits before merging. #Git #DevOps #100DaysOfCode #WebDeployment #GithubPages #CleanCode #SoftwareEngineering #SysAdmin #GitIgnore

📝 Day 6 Sharing my DevOps Series..... *git config is used to set and manage Git settings like your username, email, editor, and more. git config --global user.name "Your Name" git config --global user.email "your@email.com" *View commit history git log git log --oneline *Git Branch git branch git branch feature git checkout feature Branch = separate workspace *Git Merge - Combine changes git merge feature Merges feature branch into main Watch for conflicts *Git Clone Copy a repository git clone <repo-url> Downloads project to your system *Git Pull vs Fetch git fetch git pull Fetch = download changes Pull = fetch + merge *Git Push Upload your code git push origin main Sends commits to remote repo *Git Tag Mark important versions git tag v1.0 git push origin v1.0 Useful for releases *Git Stash Save work temporarily git stash git stash pop Useful when switching tasks *Git Rebase vs Merge Two ways to integrate code Merge → keeps history Rebase → cleaner history git rebase main *Git Fork (GitHub Workflow) Post: Contribute to open source Fork → copy repo Clone → local copy Push → your repo PR → contribute git cherry-pick git cherry-pick is used to pick a specific commit from one branch and apply it to another branch. git cherry-pick <commit-id> #GitHub #OpenSource #DevOps #git #cloud #repository.....

🚀 From Zero to Version Control: My Journey into Git & GitHub  In my journey toward becoming a DevOps Engineer, one of the most fundamental (yet powerful) skills I’ve been focusing on is Version Control using Git and GitHub.  At first, it felt like just “commands" but soon I realized it’s the backbone of modern software development and DevOps workflows. --> What I’ve Learned So Far:   - Understanding Version Control – tracking changes, collaboration, and code history.   - Git Basics – initializing repositories, staging, committing changes.   - Branching & Merging – working on features without breaking main code.   - GitHub – remote repositories, pushing code, pull requests, collaboration.  --> Key Commands I Practiced Daily:   - git init # Start a repository   - git clone # Copy a remote repo   - git add / git commit # Track and save changes   - git push / git pull # Sync with remote repositories   - git branch / git checkout # Work with branches   - git merge # Combine code changes  --> Why This Matters for DevOps & Cloud:   Version control is not just about code - it’s about collaboration, automation, and CI/CD pipelines. Every deployment, every infrastructure change, and every release starts here.  Learning Git has helped me understand how teams manage code at scale and how DevOps ensures smooth integration and delivery.  This is just the beginning - next step: integrating Git workflows with CI/CD tools and cloud platforms.   #DevOps #Git #GitHub #VersionControl #CloudComputing #LearningJourney #CI_CD #TechSkills

🚀 Day 9/100 – Git Fundamentals (Clone, Commit, Push) If you're in DevOps or development, Git is not optional… it’s your daily driver 🚗 Let’s break down the 3 most important commands 👇 🔍 What is Git? Git is a version control system that helps you track changes in your code and collaborate with others. ⚙️ 1. git clone – Get the code git clone https://lnkd.in/gG8mt6kE 👉 Copies a remote repository to your local machine ✍️ 2. git commit – Save your changes git add . git commit -m "Added new feature" 👉 Captures a snapshot of your changes 💡 Think of it as a save point in your project 🚀 3. git push – Upload your changes git push origin main 👉 Sends your commits to the remote repository 🔄 Complete Flow git clone → make changes → git add → git commit → git push 👉 That’s your daily DevOps workflow 🔁 💡 Why Git Matters ✅ Track changes ✅ Collaborate with teams ✅ Rollback if something breaks ✅ Integrates with CI/CD pipelines ⚠️ Common Mistakes ❌ Forgetting git add before commit ❌ Pushing directly to main branch ❌ Writing unclear commit messages ❌ Merge conflicts panic 😅 📌 Key Takeaway 👉 Clone → Work → Commit → Push Master this flow and you’ve mastered Git basics. 💬 What’s your most used Git command daily? #Git #DevOps #VersionControl #CI_CD #100DaysOfDevOps #LearningInPublic

What happens after you push your code to Git? 🤔 Day 16 of my DevOps Journey Today I started learning Jenkins and understood the backbone of DevOps — CI/CD ⚙️🚀 Until now, I was just pushing code… But what happens after that? That’s where CI/CD comes in. CI/CD explained simply: Continuous Integration (CI) → Combination of build + test Whenever a developer commits code to Git: • Code is automatically fetched • Build process starts • Unit tests are executed This helps us quickly know whether new code works with existing code or breaks it Continuous Delivery vs Continuous Deployment: • Continuous Delivery → Code is ready for deployment (manual approval needed) • Continuous Deployment → Code is automatically deployed to production after build & test CI/CD Pipeline stages: Version Control • Code is pushed using tools like Git Build • Code is compiled and prepared for execution Unit Testing • Code is tested to validate functionality Deploy • Application is deployed to environments (Dev/Test/Prod) After deployment, we can see the actual output of the application Tools used for CI/CD pipelines: Jenkins, GitHub Actions, GitLab CI, Azure Pipelines, AWS Pipelines, Travis CI, CircleCI, Harness Day 16 realization💡 Writing code is just the beginning. The real power lies in what happens after the commit. CI/CD makes sure: ✔ Code is tested instantly ✔ Issues are caught early ✔ Deployment becomes fast and reliable Now imagine: The moment code is committed It automatically builds → tests → deploys That’s CI/CD. That’s automation replacing manual effort. This is where DevOps actually begins⚡ Next — I’ll go deeper into Jenkins pipelines🔥 See you on Day 17 with Jenkins Installation and Access🚀 #DevOps #Jenkins #CICD #Automation #LearningInPublic #100DaysOfDevOps #Day16 #Git #Linux