Git Submodules for Scalable Monorepo Architectures

 What Happens When We Start Coding a New Feature in a Microservices Project? Today I explored the complete real-time development flow followed in IT companies while working on a new feature in a Spring Boot microservice. Here’s the structured workflow: 🔹 1️⃣ Sprint Begins Microservice repository already exists in Bitbucket main and integration branches are available Feature development starts from the integration branch 🔹 2️⃣ Create Feature Branch Login to Bitbucket Create a new feature branch from integration Follow proper naming convention 🔹 3️⃣ Clone to Local Install Git Install SourceTree Connect SourceTree with Bitbucket Clone the feature branch to local system 🔹 4️⃣ Import into IDE Open project in IDE Build and run to ensure everything works 🔹 5️⃣ Development Flow Code the feature Unit testing Developer testing Fix bugs Regular git add, commit, and push to feature branch 🔹 6️⃣ Pull Request & Code Review Raise PR to integration Mandatory code review Many companies enforce 80% unit test coverage Some organizations use automated AI code reviewers 🔹 7️⃣ Merge After Approval Once approved, feature is merged into the integration branch ✅ This structured workflow ensures: Code quality Collaboration Controlled releases Fewer production issues 🌱 What I Revised About Spring Boot Today While exploring the workflow, I also revised core concepts of Spring Boot: 🔹 Auto-Configuration Automatically creates beans based on dependencies in pom.xml Uses sensible defaults Backs off if the developer defines a custom bean 🔹 Starter Dependencies Opinionated dependency bundles Example: Web starter includes REST support, embedded server, logging, etc. 🔹 Embedded Server Comes with embedded Tomcat No need for external server deployment 🔹 Production-Ready Features Actuator (health checks, metrics, monitoring) 🔹 Stand-Alone Application Runs using main() method No external deployment needed Self-contained executable JAR 🔹 How Spring Boot Starts SpringApplication.run() Initializes application context Loads beans into the container Starts embedded server 💡 Understanding both real project workflow and framework internals gives a complete picture of how enterprise applications are built and maintained. Grateful for the guidance and structured learning from my mentor Tausief Shaikh ☑️ who constantly pushes me to understand not just how things work, but why they work that way. 🙏 #SpringBoot #Microservices #Git #Agile #Java #BackendDevelopment #Mentorship #ContinuousLearning

When everything gets knotted together, it becomes impossible to find the beginning of the thread - Eventually, you get so frustrated you just want to cut the whole knot with scissors. I see this happen constantly in DevOps. We build a Docker image, deploy it, and then... something breaks. But because the Image Version wasn't strictly coupled to the App Version, we can't find the "head of the thread." We are left staring at a spaghetti mess of artifacts, forced to guess (or cut the knot) just to get production back up. I wrote this article to show you how to keep that thread unbroken. #DevOps #Gitlab #CICD #Docker #TechTips

🚀 Day 11 of Git & GitHub Mastery – Submodules (Manage External Repos Like a Pro) As projects grow… one repository is rarely enough. Shared libraries. Common utilities. Reusable services. Copy-pasting code? ❌ Professional teams use Git Submodules ✅ Submodules let you embed and manage external repositories inside your main project — cleanly, versioned, and controlled. Today’s essentials: ✅ git submodule add → Add external repo ✅ git submodule init → Initialize after clone ✅ git submodule update → Sync to correct commit ✅ git submodule status → Track versions ✅ git submodule update --remote → Pull latest ✅ git submodule foreach → Run commands across all 💡 Why this matters: • Better code reuse • Separate version control • Cleaner architecture • Production-grade dependency management This is how real enterprise projects manage shared components. If you’re aiming for Senior Dev / DevOps / Platform Engineer roles, Submodules are a skill you shouldn’t skip. 📌 Save this post 📌 Try adding one submodule today 📌 Follow the series for Day 12 Level up your Git. Level up your career 🚀 #Git #GitHub #DevOps #SoftwareEngineering #BackendDevelopment #DeveloperTools #CodingLife #TechSkills #OpenSource #VersionControl #SystemDesign #EngineeringLife #LearnInPublic #BuildInPublic #100DaysOfCode

 Git & GitHub | Merge Conflict During Pull 🚨 Common Team Issue: Merge conflict while pulling code Merge conflicts are one of the most frequent challenges developers face when working in shared repositories—especially when multiple people modify the same files Typical error: CONFLICT (content): Merge conflict in app.py This usually happens when Git is unable to automatically merge changes from different branches. Basic commands involved in resolving conflicts: 1. git pull: You initiate the update, and Git informs you of the conflict. 2. git status: Always your friend! It shows you which files are in conflict. 3. Open the Conflicted File: You'll see special markers (<<<<<<<, =======, >>>>>>>) indicating the conflicting sections. The code between <<<<<<< HEAD and ======= is your change. The code between ======= and >>>>>>> [branch_name] is the incoming change. 4. Resolve Manually: Edit the file to include the correct code, combining or choosing between 'ours' and 'theirs'. 5. Add & Commit: Once resolved, git add <conflicted_file> and then git commit -m "Resolve merge conflict" to finalize. Understanding how to identify and resolve merge conflicts correctly is essential for maintaining code quality and avoiding accidental overwrites in collaborative DevOps environments. This visual simplifies the concept and helps beginners understand what’s actually happening behind the scenes. #Git #GitHub #DevOps #VersionControl #DevOpsLearning #TeamCollaboration #MultiCloudDevOps

🚀 Day 8 – Git & GitHub Series | Tags (Managing Versions Like a Pro) In real projects, we don’t deploy “latest commit”. We deploy versions. 👉 v1.0 👉 v1.1 👉 v2.0 That’s exactly what Git Tags are for. Tags = release checkpoints They mark important commits so you can track, deploy, or rollback anytime. 🔹 Essential Tag Commands View all tags git tag Create a tag git tag v1.0 Create annotated tag (recommended for releases) git tag -a v1.0 -m "Production release" Delete local tag git tag -d v1.0 Push one tag git push origin v1.0 Push all tags git push origin --tags Fetch tags git fetch --tags 💡 Real-world DevOps workflow Code → Test → Tag → Push → CI/CD → Deploy Need rollback? Just deploy the previous tag. Done. ✅ No guesswork. No chaos. Clean release management. 📌 This is Day 8 of my Git Mastery Series Daily practical Git + GitHub tips for Developers | DevOps | SREs. If you want to work like real engineering teams: 👉 Follow for the next post Next: Git Workflows & Branching Strategies (GitFlow vs Trunk) #Git #GitHub #DevOps #SRE #SoftwareEngineering #VersionControl #CI_CD #CloudComputing #Developers #TechLearning #BackendDeveloper #OpenSource #ProgrammingLife #CareerGrowth #LearnInPublic

Most developers can use Git. Fewer understand how it actually works internally. And that gap shows up the moment things go wrong: -> A bad git reset --hard -> A messy rebase -> Duplicate commits after rewriting history -> Lost work after a detached HEAD The turning point for me was this: Git is not a “change tracker.” It’s a content-addressable snapshot database backed by a Directed Acyclic Graph (DAG). Once you internalize that: -> A commit = snapshot + metadata + parent pointer -> A branch = mutable reference to a commit hash -> HEAD = pointer to a reference (or directly to a commit in detached mode) -> Rebase = replaying diffs to create new commits (new hashes) -> Reset = moving a branch reference -> Revert = creating inverse history without rewriting -> Reflog = reference movement journal (your real recovery tool) Git stops feeling magical. It becomes deterministic. I wrote a deep technical breakdown covering: -> How Git constructs the commit DAG -> Why rebasing changes commit identity -> What actually happens in soft vs mixed vs hard reset -> Why merge commits have two parents -> How conflicts arise from overlapping snapshots -> When history rewriting is safe vs dangerous -> How to recover “lost” commits using reflog If you care about clean history, safe collaboration, and understanding what your tooling is doing under the hood — this is for you. 🔗 Read the full guide here: https://lnkd.in/dYWjk3g9 For the engineers here — what’s your rule around rebase vs merge on shared branches? #git #distributedversioncontrol #softwareengineering #devops #backend #engineering

🚀 Mastering the Git Workflow: From Local Commits to GitOps Excellence Are you still managing infrastructure manually? It’s time to bridge the gap between development and operations using the power of GitOps. 🛠️ Git is no longer just for application code—it is the single source of truth for your entire infrastructure. Based on the comprehensive *Git Cheat Sheets* provided, here is your roadmap to mastering the modern workflow: 1. Master the Staging Area 📥 Understanding the lifecycle of a file is crucial. Use `git add` to move changes from your working directory to the Staging Area before finalizing them with `git commit`. If you need to revert a staged file without losing your progress, `git reset` is your best friend. 2. Isolate & Integrate with Branches🌿 Never work directly on the main branch. Create a feature branch with `git branch [branch-name]` and switch to it using `git checkout`. Once your feature is ready, use `git merge` to integrate that history back into your current branch. 3. The Power of Temporary Commits ⏱️ Caught in the middle of a task but need to switch branches? Use `git stash` to save your modified changes. You can view your stack with `git stash list` and bring those changes back later with git stash pop. 4. Transitioning to GitOps 🏗️ GitOps takes these tried-and-true Git processes and applies them to infrastructure. The formula is simple: GitOps = IaC + Merge Requests + CI/CD. Infrastructure as Code (IaC): Define your entire setup in declarative config files . Merge Requests (MRs): Use these for collaboration, peer reviews, and formal approvals to prevent costly errors *CI/CD:* Automatically enact changes in your environment whenever code is merged. Why make the switch? 📈 Beyond just automation, GitOps offers *improved access control* (only CI/CD needs credentials), *faster time to market* and *simplified auditing* because every change is documented in the git log. Pro-Tip: Keep your changes small! 🤏 Iterating with small, simple commits allows for faster feedback and easier rollbacks if something goes wrong. #Git #GitOps #DevOps #InfrastructureAsCode #Programming #TechTips #GitLab #CloudComputing #SoftwareEngineering

Stop wasting hours Googling Git commands. Here's your complete cheat sheet. After helping 100+ developers level up their Git game, I've compiled EVERY command you'll actually use — from basics to DevOps workflows. This isn't just another Git tutorial. It's 20 pages covering: → Basic commands (the 20% you use 80% of the time) → Branching & merging strategies → Undoing mistakes without panic → CI/CD integration patterns → GitOps workflows → Docker & Kubernetes deployments → Secrets management (because we've all committed an API key 😅) My favorites that saved me countless times: • git reflog — Your time machine when you mess up • git bisect — Find bugs in minutes, not hours • git push --force-with-lease — Force push the safe way • git stash — Context switch without losing work The guide includes hooks for automation, feature flag management, multi-environment deployments, and rollback strategies. Everything you need for production-grade workflows. The best part? It's organized by use case, not alphabetically. Find what you need when you actually need it. Bookmark this. Share it with your team. Stop context-switching to Stack Overflow every 5 minutes. What's the ONE Git command you wish you'd learned earlier? Drop it below. 📌 Don't forget to follow Narendra K. for more DevOps insights, practical guides, and career tips that actually work. #DevOps #Git #SoftwareEngineering #CICD #GitOps #Developer #TechTips #Kubernetes #Docker

🚀 Git & GitHub Series – Day 2 Master Git Branching Like a Pro (Stop breaking main 😅) One mistake I see everywhere: Developers committing directly to main/master → broken builds → failed deployments → production issues That’s NOT how teams work. Professional teams use branches. Because branching = safe development + clean releases 🔹 What you should know about Git Branching: ✅ Create feature branches git branch feature-login ✅ Switch branches git checkout feature-login ✅ Create + switch instantly git checkout -b feature-login ✅ Merge after testing git merge feature-login ✅ Rebase for clean history git rebase main ✅ Delete old branches git branch -d feature-login 🔥 Real-world DevOps workflow: main → production feature → development merge → CI/CD → deploy No conflicts. No risk. No drama. Just clean releases. I’m sharing daily Git & GitHub tips + posters to help you: 🔹 learn faster 🔹 crack interviews 🔹 work like real engineering teams 🔹 level up in DevOps/SRE 👉 Follow me for the full Git series #Git #GitHub #DevOps #SRE #CloudComputing #SoftwareEngineering #Developers #TechLearning #CareerGrowth 

✅ LinkedIn Post: Git vs TFVC — Which one should you choose? If your team is still debating Git vs TFVC, here’s the simplest way I explain it: 🔹 Git = Distributed + Modern Dev Workflows Git has become the default choice for most teams because it enables: Branching & merging at scale (feature branches, release branches, hotfixes) Pull Requests + code reviews as a habit, not an afterthought Offline work & faster local operations Better alignment with CI/CD and DevOps practices Easier integration with modern tools (pipelines, automation, GitHub ecosystem) 👉 Best for: agile product teams, microservices, DevOps maturity, CI/CD-heavy environments. 🔸 TFVC = Centralized + Simpler Mental Model (in some cases) TFVC can still make sense when: You need a centralized versioning model You have very large binary files and prefer centralized locking The codebase is legacy and stable, with minimal branching Your org has long-established TFVC workflows and governance 👉 Best for: legacy enterprise setups, highly controlled environments, binary-heavy repos (with strict lock/unlock workflows). 💡 My rule of thumb ✅ If your goal is speed + collaboration + modern engineering practices, choose Git. ✅ If your goal is central control + legacy compatibility, TFVC can still work—but it’s increasingly niche. 🔁 Migration thought (practical, not theoretical) If you're moving from TFVC to Git, focus less on “moving history perfectly” and more on: Clean repo structure Branch strategy PR culture Build + release automation Because that’s where the real productivity jump happens. 👋 Curious: Are you still using TFVC anywhere? What’s the biggest reason your team hasn’t moved to Git yet? #AzureDevOps #Git #TFVC #DevOps #SoftwareEngineering #EngineeringLeadership #CI_CD #VersionControl #DotNet