Irusri Group’s Post

🚀 𝐃𝐚𝐲 𝟑𝟗/𝟏𝟓𝟎 – 𝐃𝐞𝐯𝐎𝐩𝐬 𝐋𝐞𝐚𝐫𝐧𝐢𝐧𝐠 𝐉𝐨𝐮𝐫𝐧𝐞𝐲 📘 𝐓𝐨𝐝𝐚𝐲’𝐬 𝐅𝐨𝐜𝐮𝐬: 𝐓𝐞𝐚𝐦 𝐂𝐨𝐥𝐥𝐚𝐛𝐨𝐫𝐚𝐭𝐢𝐨𝐧 𝐰𝐢𝐭𝐡 𝐆𝐢𝐭 (𝐇𝐚𝐧𝐝𝐬-𝐎𝐧) Today was a fully practical, project-based day where I worked on real Git collaboration workflows with my team — exactly how things happen in real DevOps projects. 📚 𝐖𝐡𝐚𝐭 𝐈 𝐃𝐢𝐝 𝐓𝐨𝐝𝐚𝐲 ✅ Created a Git repository for the project ✅ Asked team members to fork the repository ✅ Made changes locally and pushed them using: git add git commit git push ✅ Helped team members clone the repository ✅ Guided them to push their changes ✅ Reviewed and merged pull requests ✅ Pulled merged changes into my local repository ✅ Explained and practiced git fetch with the team 🧠 𝐊𝐞𝐲 𝐔𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝𝐢𝐧𝐠 🔹 Fork → Clone → Change → Commit → Push → Pull Request → Merge 🔹 Fetch vs Pull (keeping local repo updated safely) 🔹 Team collaboration without conflicts 🔹 Real version control workflow used in projects 🌱 𝐊𝐞𝐲 𝐓𝐚𝐤𝐞𝐚𝐰𝐚𝐲 Git is not just about commands — it’s about collaboration, communication, and clean workflows. Practicing this with a team gave me much deeper confidence in version control and DevOps collaboration 🚀 𝐃𝐞𝐯𝐎𝐩𝐬 𝐢𝐬 𝐚 𝐭𝐞𝐚𝐦 𝐬𝐩𝐨𝐫𝐭. 𝐆𝐢𝐭 𝐢𝐬 𝐭𝐡𝐞 𝐩𝐥𝐚𝐲𝐛𝐨𝐨𝐤. ⚙️🔥 #DevOps #150DaysOfDevOps #Git #GitHub #TeamWork #VersionControl #LearningInPublic #HandsOn #ProjectWork

How Git branching strategy that balances collaboration, velocity, and stability in software delivery within a DevOps environment? ✳️ Three Objectives of Branching: 1️⃣ Isolation: Ensuring parallel development without blocking developers. 2️⃣ Collaboration: Seamless code reviews and integration. 3️⃣ Stability: Maintaining a deployable main branch as the "North Star." ✳️ Branching Spectrum: 🔸 Strategies range from Trunk-Based Development (high velocity, simplicity) to Git Flow (high control, complexity). 🔸 Trade-offs between speed and control are highlighted. ✳️ Comparative Analysis: 🔸 Trunk-Based Development: Best for high-frequency deploys; requires discipline and robust testing. 🔸 GitHub Flow: Lightweight and ideal for web apps/startups; not suitable for multiple product versions. 🔸 Git Flow: Provides structure for enterprise and packaged software; has high overhead and risks "merge hell." 🔸 GitLab Flow: Best for multi-environment setups; requires maintenance of synced environments. ✳️ Scaling Reality: 🔸 Teams should start simple (GitHub Flow), add structure as they grow (Git Flow), and adopt automation for large teams to revert to Trunk-Based Development. ✳️ Collaborative Hygiene: 🔸 Naming conventions, pull requests, conflict resolution, and CI/CD integration are critical for effective collaboration. ✳️ Strategic Takeaways: 🔸 Start with simplicity, prioritize automation, and focus on communication to ensure reliable and efficient software delivery. #usecase #cicd #github #intergration #gitflow #githubflow #bestpractices

🚀 Learning Git & GitHub | Hands-on + Real-World Perspective Over the past few days, I’ve been learning Git and GitHub and understanding how version control works in real-world projects. Here’s what I covered 👇 🔹 Git & Version Control What version control is and why it’s essential Why GitHub is so popular in the industry How Git helps teams collaborate efficiently 🔹 GitHub APIs & Automation Worked with a script that interacts with the GitHub API Learned how similar scripts can be adapted for tools like GitLab, Jira, and other platforms 🔹 Branching Strategy (Real-World Example) Studied a real production-level project Explored the Kubernetes GitHub repository Understood how large projects manage branching strategies at scale This learning really helped me understand how open-source projects and enterprise teams manage code, collaboration, and releases. 📌 Still learning, still building, and sharing the journey. #Git #GitHub #VersionControl #DevOps #OpenSource #Kubernetes #LearningInPublic #SoftwareEngineering

Sometimes life pauses your plans. But it doesn’t cancel your goals. After a short gap, I’ve restarted my journey toward becoming a DevOps Engineer. I Completed Git fundamentals and strengthened my understanding of version control, branching strategies, and collaboration workflows. From Service Management to DevOps — building my skills step by step. Consistency > Motivation. #DevOps #Git #DevOpsJourney #CareerGrowth #Learning 🚀 Git Commands I Learned (DevOps Journey) Here are the Git concepts I’ve learned and practiced: 🔹 git init - Initializes a new Git repository in your project folder. 🔹 git add - Moves files from Working Directory to the Staging Area. 🔹 git commit - Saves the staged changes into the Local Repository with a message. 🔹 git push - Uploads local commits to the Remote Repository (like GitHub). 🔹 git status - Shows the current state of files (modified, staged, untracked). 🔹 git log - Displays the commit history. 🔹 git merge - Combines changes from one branch into another branch. 🔹 git rebase - Moves or reapplies commits on top of another branch to maintain a clean history. 🔹 git cherry-pick - Applies a specific commit from one branch to another branch. 🔹 git config - Sets configuration details like username and email. 🔹 git diff - Shows the differences between file versions or commits. 🔹 git branch- Creates or lists branches. 🔹 git checkout- Switches between branches (or restores files). 🔹 git fetch - Downloads updates from the remote repository but does not merge them. 🔹 git pull - Fetches and merges the latest changes from the remote repository. 🔹 git clone - Creates a copy of a remote repository on your local machine. 🔹 git revert - Creates a new commit that undoes changes from a previous commit. 🔹 git reset - Moves the branch pointer to a previous commit (can remove commits depending on the mode used). 🔹 git reflog - Shows the history of all actions performed in Git (useful to recover deleted commits). 🔹 git tag - Adds a version label to a specific commit (like v1.0). 🔹 git stash - Temporarily saves uncommitted changes so you can switch branches safely. 🔹 git squash - Combines multiple commits into a single commit (usually done during rebase).

🚀 Understanding Git Workflow – Simple & Clear Today I revised the complete Git workflow, covering all key areas from clone to push 👇 🔹 Git Areas Explained 1️⃣ Remote Repository (GitHub / GitLab) This is the central repository where the project code is stored online and shared with the team. 2️⃣ Local Repository (.git folder) A copy of the remote repository on your local machine. All commits are permanently stored here. 3️⃣ Working Directory This is where you edit files and write code. Changes here are not tracked until you add them. 4️⃣ Staging Area (Index) A temporary area where you prepare changes before committing. It helps control what goes into the next commit. 🔄 Git Commands Flow git clone → Copies the remote repository to your local machine git add → Moves changes from Working Directory to Staging Area git commit → Saves staged changes to the Local Repository git push → Sends commits from Local Repository to Remote Repository git pull → Fetches latest changes from Remote Repository to Local 🎯 One-Line Summary Code is written in the Working Directory, staged carefully, committed locally, and finally pushed to the remote repository for collaboration. #Git #GitWorkflow #GitHub #DevOps #VersionControl #LearningJourney #SoftwareEngineering

Git Workflow — Simple, but powerful This diagram is a great reminder of how clean Git habits keep teams productive and codebases stable. From working directory → staging → local repo → remote repo, every step has a purpose: ->git add to stage intent ->git commit to capture meaningful changes ->git push to collaborate ->git fetch / git pull to stay in sync ->git diff to understand what actually changed before it breaks something In fast-moving teams, Git isn’t just a tool. It’s a shared language that helps developers collaborate without stepping on each other’s work. If you’re mentoring juniors or onboarding new teammates, visuals like this make Git concepts click much faster than commands alone. Clean commits. Clear history. Fewer surprises in production.

🚀 Day 24 of #90DaysOfDevOps — Advanced Git: Merge, Rebase, Stash & Cherry-Pick Learning went beyond creating branches — it was about how work comes back together and how developers manage real-world workflows. Even though I’ve used these concepts throughout my industry experience, going back to basics always strengthens clarity and confidence. Here’s what I explored 👇 🔹 Git Merge ✔ Fast-forward merge keeps history simple ✔ Merge commit preserves branch history ✔ Learned how merge conflicts happen & how to resolve them 🔹 Git Rebase ✔ Rewrites commit history for a clean timeline ✔ Makes history linear and easier to read ✔ Reminder: never rebase shared commits 🔹 Squash vs Regular Merge ✔ Squash merge combines many small commits into one ✔ Regular merge preserves detailed history ✔ Trade-off between clarity and traceability 🔹 Git Stash ✔ Saved work-in-progress without committing ✔ Switched branches safely during urgent tasks ✔ Learned difference between stash pop and stash apply 🔹 Cherry-Pick ✔ Applied a specific commit from another branch ✔ Useful for hotfixes and selective updates ✔ Can cause duplicate history if overused 💡 Big takeaway: These commands separate beginners from confident practitioners. They help maintain clean history, support collaboration, and handle real-world interruptions effectively. Git isn’t just version control — it’s a collaboration engine. #Git #DevOps #VersionControl #SoftwareEngineering #90DaysOfDevOps #DevOpsJourney

Pull Request To The Rescue! What is a PR (Pull Request)? Initiates the process of merging new code changes into the main project repository. Pull requests are sent through git systems to notify the rest of your team that a branch or fork is ready to be reviewed. Why Are PR Important for Code Review? - Enables the leader to track your team’s review process as a whole. - Changes can be made without impacting the work of others - Powerful tool that can help teams build features faster. - Team members to work on code changes in parallel, which can speed up development. - Pull Request can be merged - Bugs and errors can be addressed before they cause any problems in the live code - With pull requests, you can always roll back to a previous version in case things go wrong - Improve code quality and performance image cred: Atlassian ♻ Repost 📢 Follow Hani Mao for more #git #devops

🚀 Day 23 of #90DaysOfDevOps – Git Branching & Working with GitHub Today I explored one of the most powerful concepts in Git: branching 🌿 Branches allow developers to work on new features, bug fixes, or experiments without breaking the main codebase — making collaboration safer and more organized. Even though I’ve used these concepts extensively in my industry experience, it always feels good to go back to basics. Revisiting fundamentals strengthens clarity, reinforces best practices, and often reveals insights we overlook in day-to-day work. 🔹 What I Practiced Today ✅ Understanding what Git branches are and why they matter ✅ Switching between branches & managing changes ✅ Using git switch vs git checkout ✅ Creating feature branches and isolating commits ✅ Deleting unused branches ✅ Connecting a local repo to GitHub & pushing branches ✅ Making changes directly on GitHub & pulling updates locally ✅ Learning origin vs upstream ✅ Understanding git fetch vs git pull ✅ Exploring clone vs fork and keeping forks in sync 💡 Key Learnings 🔹 A branch is an independent line of development 🔹 HEAD points to your current branch/commit 🔹 Switching branches changes your working directory files 🔹 origin = your remote repo, upstream = original source repo 🔹 fetch downloads changes, pull downloads + merges 🔹 Forking is essential when contributing to others’ projects Pushed my practice repo and feature branches to GitHub — seeing multiple branches live felt like leveling up! 💻✨ Every day I’m realizing that Git isn’t just a tool — it’s the backbone of collaborative development. #90DaysOfDevOps #DevOpsJourney #Git #VersionControl #LearningInPublic #DevOpsKaJosh #TrainWithShubham