Chamith Kavinda’s Post

GitHub or Gitea......which do you prefer? Every developer knows the Git workflow, it’s the heartbeat of our projects. But when it comes to where we host that code, we often find ourselves choosing between two very different paths: the giant, cloud-powered hub or the lightweight, self-hosted champion. Let’s talk about them. GitHub: The Powerhouse GitHub is the industry leader, and for good reason. It’s cloud-hosted, meaning it’s ready to go the moment you sign up. Its community is massive, its integrations (like Jira, Slack, Jenkins) are endless, and features like GitHub Actions and Copilot are industry standards for scaling quickly. It’s polished, modern, and built for teams that need to collaborate globally without managing any infrastructure. Gitea Gitea is the self-hosted alternative that puts you back in the driver's seat. It’s incredibly lightweight, you can run it on a small server, a VPS, or even a Raspberry Pi. Because you host it, you have total privacy, no vendor lock-in, and full control over your data and security. It’s simple, minimalist, and feels surprisingly like GitHub, making it a favorite for homelabs, privacy-focused teams, or anyone who wants to own their infrastructure. Both platforms speak the same "Git language" and handle pull requests, issue tracking, and wikis. Hosting: GitHub is cloud-managed, while Gitea is self-hosted by you. Resources: GitHub scales for you, while Gitea is very lightweight and perfect for small hardware. Community: GitHub has a massive global community, whereas Gitea has a passionate, growing user base. Integrations: GitHub offers thousands via its Marketplace, while Gitea relies on customizable, plugin-based setups. If you’re building open-source projects or need a robust, plug-and-play environment for a large team, GitHub is hard to beat. But if you want to learn the DevOps side of infrastructure, keep your code off big-tech servers, or run lean setups in a homelab, Gitea is an absolute gem. I’ve spent plenty of late nights working on both. GitHub is my go-to for speed and community, but there’s something empowering about having your own Git instance running on a server you control. Now, I want to hear from you: Are you team Cloud-Everything with GitHub, or do you prefer the control of self-hosting with Gitea? #DevOps #GitHub #Gitea #CloudEngineering #SelfHosting #SoftwareDevelopment #TechCommunity

Git Repo Naming Standards and Best Practices Messy git repository naming conventions can turn your codebase into a confusing maze where developers waste time hunting for the right project. This guide helps software development teams, DevOps engineers, and project managers establish clear repository naming best practices that improve collaboration and streamline workflows. https://lnkd.in/gykUTSCu Amazon Web Services (AWS) #AWS, #AWSCloud, #AmazonWebServices, #CloudComputing, #CloudConsulting, #CloudMigration, #CloudStrategy, #CloudSecurity, #businesscompassllc, #ITStrategy, #ITConsulting, #viral, #goviral, #viralvideo, #foryoupage, #foryou, #fyp, #digital, #transformation, #genai, #al, #aiml, #generativeai, #chatgpt, #openai, #deepseek, #claude, #anthropic, #trinium, #databricks, #snowflake, #wordpress, #drupal, #joomla, #tomcat, #apache, #php, #database, #server, #oracle, #mysql, #postgres, #datawarehouse, #windows, #linux, #docker, #Kubernetes, #server, #database, #container, #CICD, #migration, #cloud, #firewall, #datapipeline, #backup, #recovery, #cloudcost, #log, #powerbi, #qlik, #tableau, #ec2, #rds, #s3, #quicksight, #cloudfront, #redshift, #FM, #RAG

In real-world development, work rarely happens in a straight line. You start working on something… then suddenly need to switch branches, debug another issue, or check something in the main codebase. That’s where many people get stuck with Git. This blog focuses on two concepts that act as safety nets when your workflow gets interrupted: Git Stash and Git History. It explains both in a simple and practical way so you can handle interruptions and explore past code without confusion. Here’s what this Blog/Attached PDF covers: 1) The problem Git stash is designed to solve 2) What git stash actually does 3) Why Git blocks branch switching with uncommitted changes 4) How to stash your work safely 5) Switching branches and returning without losing changes 6) Restoring changes using git stash pop 7) Using stash within the same branch for debugging 8) Why stash should be used only as a temporary tool 9) What commit hashes are and why they matter 10) How to read commit history using git log 11) Checking out specific commits from the past 12) Understanding detached HEAD state 13) Practical use cases like debugging and verification 14) How to return to the latest state of your code One key idea: Git stash lets you temporarily set aside your work so you can switch context without committing incomplete changes. Git history lets you move through different points in your project’s timeline and understand how things evolved. Together, they give you control over both your present work and your past changes. This blog helps you build that confidence so you can work more freely without worrying about losing progress or getting stuck. You can read the complete blog using the link below, or you can review the attached document—both contain the same information: https://lnkd.in/gJeRKiPm Quick takeaway: Understanding stash and history makes it much easier to handle interruptions, debug issues, and explore your code safely. Comment what should I write about next? Feel free to comment below & I’ll try to create a post on your suggestion within a day. I can cover topics like: Git, Ansible, Jenkins, Groovy, Terraform, AWS, Networking, Linux, DevOps practices, Cloud architecture, CI/CD pipelines, Infrastructure as Code, or anything related. If you find the content useful, please share it with your network and drop a like, it really helps these posts reach more Linux, DevOps, and Cloud professionals. Your support helps me continue creating consistent content. Thanks in advance for your ideas and feedback. #Git #VersionControl #DevOps #Linux #SoftwareDevelopment #GitStash #LearningJourney #TechCareers

𝗔𝗻𝘁𝗵𝗿𝗼𝗽𝗶𝗰 𝗷𝘂𝘀𝘁 𝘀𝗵𝗶𝗽𝗽𝗲𝗱 𝗖𝗹𝗮𝘂𝗱𝗲 𝗥𝗼𝘂𝘁𝗶𝗻𝗲𝘀 - 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗚𝗶𝘁𝗛𝘂𝗯 𝗶𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝘁𝗵𝗲 𝗽𝗮𝗿𝘁 𝗻𝗼 𝗼𝗻𝗲 𝗶𝘀 𝘁𝗮𝗹𝗸𝗶𝗻𝗴 𝗲𝗻𝗼𝘂𝗴𝗵 𝗮𝗯𝗼𝘂𝘁. Claude Routines are saved Claude Code configurations - a prompt, one or more repos, and a set of connectors - that run on Anthropic's cloud infrastructure on autopilot. You set them up once, and they keep working when your laptop is closed. Three trigger types: scheduled (hourly, daily, weekly), API (webhook from your CI pipeline), and GitHub events (pull requests, releases, merges). You can stack multiple triggers on a single routine. So is this real value or just another AI feature announcement? The GitHub integration is where it gets interesting. Here is what it actually does well: • 𝗣𝗥 𝗿𝗲𝘃𝗶𝗲𝘄 𝗼𝗻 𝗮𝘂𝘁𝗼𝗽𝗶𝗹𝗼𝘁: Trigger on pull_request.opened, apply your team's review checklist, leave inline comments for security, performance, and style. Human reviewers focus on design decisions rather than on mechanical checks. • 𝗕𝗮𝗰𝗸𝗹𝗼𝗴 𝗴𝗿𝗼𝗼𝗺𝗶𝗻𝗴: Run nightly, read new issues, apply labels, assign owners based on code area, post a summary to Slack. Team starts the day with a clean queue. • 𝗔𝗹𝗲𝗿𝘁 𝘁𝗿𝗶𝗮𝗴𝗲: Your monitoring tool hits the API endpoint when an error threshold crosses. The routine pulls the stack trace, correlates with recent commits, and opens a draft PR with a proposed fix. • 𝗗𝗼𝗰𝘀 𝗱𝗿𝗶𝗳𝘁 𝗱𝗲𝘁𝗲𝗰𝘁𝗶𝗼𝗻: Weekly scan of merged PRs, flag documentation that references changed APIs, and open update PRs for review. But let's be honest about what is already here. GitHub Actions with Copilot, OpenClaw cron jobs, and well-written CI pipelines cover much of this ground. The difference is friction: Routines package the prompt, the repo, the environment, and the trigger into a single config, rather than stitching together workflows, permissions, and API tokens yourself. The honest take? It is not hype, but it is early. Research preview means behavior and limits can change. The runs count against your personal account allowance. Everything the routine does shows up as you - commits, PRs, Slack messages. That last part is either a feature or a liability, depending on how much you trust an autonomous agent with your GitHub identity. Worth setting up for repetitive, low-risk work like code review checklists and issue triage. Would not hand over production deploy decisions yet. What repetitive coding task would you automate first? #ClaudeRoutines #AIEngineering #GitHub

This weekend I tested whether GitHub Copilot's cloud coding agent could take a rough prototype and evolve it into a deployable, enterprise-ready application — with minimal manual intervention. 𝗛𝗲𝗿𝗲'𝘀 𝘄𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝗲𝗱. I set up a GitHub project, organized the work using a Kanban board, and applied a BMAD to convert the entire epic into scoped, detailed issues. Each issue had clear expected outcomes and deliverables for example:   • Documenting the current prototype state   • Designing the data model   • Building backend APIs including authentication   etc I assigned each issue to cloud agents, and watched the work begin. Agents picked up scoped issues independently — created branches, built implementation artifacts, captured proof via screenshots, and pushed work into review workflows without being prompted at each step. After 2–3 hours, all tasks were marked complete with test evidence attached. 𝗧𝗵𝗲 𝗿𝗲𝗮𝗹𝗶𝘁𝘆 𝗰𝗵𝗲𝗰𝗸? Not everything was clean. Some tasks were marked done without the expected artifacts actually being there — a known limitation of LLM-based agents today, where confidence doesn't always equal correctness. I had to leave review comments, ask agents to relook, and loop back on a few issues. When I pulled the code locally, the frontend threw errors despite tests passing in GitHub's cloud environment. This also apparently is a well-known gap — GitHub Copilot coding agents run inside isolated GitHub Actions runners, which can behave differently from a local dev setup. About 45 minutes of Copilot-assisted debugging later, the application was finally up — and it looked great. From there, I assigned infra provisioning issues to deploy to cloud. That too required iteration, but eventually the full application was live end-to-end. 𝗛𝗼𝘄 𝗱𝗼𝗲𝘀 𝘁𝗵𝗶𝘀 𝗰𝗼𝗺𝗽𝗮𝗿𝗲 𝘁𝗼 𝗗𝗲𝘃𝗶𝗻 𝟮.𝟬 𝗯𝘆 𝗖𝗼𝗴𝗻𝗶𝘁𝗶𝗼𝗻? Having used both, here's my honest take: Environment maturity: Devin operates inside its own sandboxed compute environment with access to a browser, shell, and code editor. GitHub's coding agent runs within GitHub Actions runners, which is powerful but more constrained. Traceability: Devin's step-by-step execution visibility — including video playback and interactive progress tracking — makes it significantly easier to understand agent decisions and course-correct in real time. Reusability: Devin 2.0 allows you to convert completed workflows into reusable playbooks, enabling easy replication Multi-repo handling: GitHub Copilot's coding agent is scoped to a single repository per session. Devin handles broader codebase navigation across repositories more naturally. 𝗠𝘆 𝗼𝘃𝗲𝗿𝗮𝗹𝗹 𝘁𝗮𝗸𝗲: Agents are already genuinely useful for structured, scoped execution. Breaking work into well-defined issues with clear outcomes is not just helpful — it's essential. The more specification-driven your input, the better the agent output.

A few weeks ago, Fabric Git integration improved the branching out to another workspace, as announced in Fabcon. Your team has a shared dev workspace connected to the main branch in your Git repo. When you need to build or change something, you go to Source Control ➡️ open the Branches tab ➡️ select "Branch out to another workspace". Fabric creates a new Git branch based on the latest commit of main and a brand new workspace connected to that branch, or you can point it to an existing workspace and replace the branch connected to it. The result is your own isolated copy of the environment. Same items, same structure, completely separate from the shared workspace. By default, Fabric pulls every item from the source branch into your new workspace, but there is also a preview option called 👉"Select items individually" This lets you pick only the items you actually need. If you are working on one report and one semantic model, you do not need to bring over 40 other items. Fabric checks for dependencies too. If the item you selected depends on something you did not select, it flags it and asks you to include the related items. Once your workspace is ready, the workflow is very simple. You work in your branched workspace. You make the changes you need. You commit them to your feature branch through the Source Control panel. When everything looks good, you create a Pull Request to merge back into main. The review and merge process will happen then in your Git provider, Azure DevOps, GitHub, whatever your team uses. After the merge, a new commit appears on main. Fabric prompts the shared dev workspace to update. The team pulls in your changes and everyone sees the new version. A few things to know 👇 ➡️Commit everything before you branch out. Items not saved to Git at the time of branching can get lost. Fabric warns you, but it is easy to skip that warning. ➡️If you branch out into an existing workspace, some items may be deleted. Fabric replaces the branch connection and items that do not exist in the new branch get removed. ➡️If you used selective branching and later switch branches, the item selection resets. All items from the new branch get synced, not just the ones you picked originally. ➡️And if you need more items later, you do not have to start over, you can just go back into Source Control, select "Select additional items," pick what you need, and update. Great to see that CI/CD is becoming easier in Microsoft Fabric than it used to be. _______ Follow for more Data Engineer content. #msfabric #cicd

"I don't use GitHub. I run my own Git server." It's a statement that usually gets one of two reactions: "Why bother?" or "Tell me more." For me, it wasn’t about paranoia—it was a calculated risk analysis. GitHub is the industry standard for a reason. It’s polished and convenient. But it also means: ↳ Your proprietary code is someone else's training data. ↳ Your entire workflow is a tenant on a platform you don’t own. ↳ Your account is subject to jurisdictions and automated flags you can't contest. As a DevOps Engineer, my priority is Sovereignty. I’ve tried Gitea for my personal projects and it's. But Gitea isn't the only player in the self-hosted game for 2026. If you’re looking to move "under your own roof," here is the breakdown of the landscape: 1. Gitea: The Lean Baseline The gold standard for "it just works." If you want GitHub parity with a footprint so small it runs on a Raspberry Pi, this is it. It’s my current choice for its simplicity and built-in container registry. 2. Forgejo: The Community Conscience Born from the Gitea fork, Forgejo is for those who want a platform governed by the community, not a corporation. It’s 100% "Soft-fork" compatible, so migrating is a breeze. If "Libré" software is your ethos, this is your forge. 3. OneDev: The Engineer’s Power Tool If you find YAML pipelines a bit dry, OneDev is a revelation. It features a visual pipeline builder that rivals commercial tools, combined with deep Kubernetes integration. It’s built for those who want high-concurrency performance without the GitLab bloat. 4. GitLab CE: The All-In-One Titan The closest you will get to a private "Cloud" experience. It handles everything from security scanning to Terraform state. Just be prepared to feed it plenty of RAM—it’s a heavyweight for a reason. The Bottom Line: Self-hosting isn't just about privacy; it's about resilience. When the "Big 3" have an outage, your deployment pipelines shouldn't have to stop. Are you still on GitHub for the "community," or are you staying because the migration feels like a chore? Let’s discuss below—would you ever go "Bare Metal" for your code? 🛡️ #DevOps #SelfHosting #Gitea #PlatformEngineering #Git #OpenSource #DataSovereignty #paragpallavsingh

🛠️ I built a tool that I wish existed when I was learning Git the hard way. The Problem: Most Git tutorials teach you git add, git commit, git push — and stop there. But in real production environments, that's where the easy part ends. I've seen engineers freeze when they accidentally commit AWS credentials to main. I've seen teams spend hours untangling a botched rebase on a release branch. I've seen 2AM hotfixes go wrong because no one had actually practiced that workflow before the incident happened. Reading about git reflog or git cherry-pick is not the same as doing it under pressure. And there was no tool that let you practice the hard stuff in a safe, realistic environment — without setting up a repo, a server, or anything at all. The Solution: I built GitPath — a fully browser-based, interactive Git learning platform designed around real production scenarios. It's built around the situations that actually matter on the job: 🔥 2AM hotfix on a live production system  🔐 AWS credentials accidentally pushed to main — revert, rotate, document  🚢 Full GitFlow release cycle from feature branch to tagged deployment  🧲 Recovering lost commits using git reflog  ⚔️ Resolving a merge conflict between two engineers on the same file Beyond scenarios, it covers 7 structured learning tracks and 28 guided lessons — from absolute basics all the way to Conventional Commits, Monorepo Git strategy, and Branch Protection rules used in enterprise CI/CD pipelines. Every lesson has a real-world story behind it, not just dry command documentation. How Easy Is It to Use: This is the part I'm most proud of. There is nothing to install. No npm. No server. No account. No configuration. You open one HTML file in your browser and you're inside a live Git terminal with a visual branch graph that updates in real time as you type commands. Your progress, XP, and streak are saved automatically in your browser. You can pick it up, put it down, and come back exactly where you left off. If you get stuck, there's a built-in hint system. If you want to explore freely, there's an open sandbox playground with no objectives at all. One file. Any browser. Zero friction. Built this as part of my DevOps portfolio — and it reflects the git workflows I rely on every day working on production AWS environments. 🔗 Try it in 10 seconds — no signup needed: https://lnkd.in/gVWKzBKd 🐙 GitHub: https://lnkd.in/gSD3SY_w If you're a DevOps, Platform, or SRE engineer — I'd genuinely love to hear what scenarios you'd add. Drop a comment or connect. #DevOps #Git #AWS #OpenSource #LearningInPublic #DevSecOps #SRE #PlatformEngineering #CloudEngineering #GitFlow

If you're learning Git, there is one habit that makes your repository feel clean and easy to understand: 👉 Delete old branches after they are merged 👉 Use rebase to keep history readable This blog is a beginner-friendly guide that explains not just how to do these things, but why they matter in real team workflows. Here’s what this Blog/Attached Document covers: 1) What happens to a branch after it is merged 2) Why merged branches should usually be deleted 3) Why deleting a branch does not delete the code 4) How to delete a branch from the remote repository 5) Why remote deletion and local deletion are different 6) How to delete a branch locally with git branch -d 7) The full cleanup workflow after merging 8) Why git pull can create merge commits 9) What git pull --rebase does under the hood 10) How rebase keeps the history linear and easier to read 11) When to use rebase and when to be careful 12) Essential commands covered in this section One key idea: A branch is just a label for a line of work. When the work is finished and merged, the label can go away — the code still lives in master, and the history still remembers every change. A simple way to think about it: - A branch is like a working note for one task - Once the task is done, keeping the note around only adds clutter - Rebase is like arranging your steps neatly on a timeline instead of stacking extra notes in between This blog builds a strong foundation so that when you work with branches in real projects, your repository stays organized and your history stays easy to follow. You can read the complete blog using the link below, or you can review the attached document—both contain the same information: https://lnkd.in/gPwhVxUM Quick takeaway: Clean branches and clean history make Git much easier to manage. Comment what should I write about next? Feel free to comment below & I’ll try to create a post on your suggestion within a day. I can cover topics like: Git, Ansible, Jenkins, Groovy, Terraform, AWS, Networking, Linux, DevOps practices, Cloud architecture, CI/CD pipelines, Infrastructure as Code, or anything related. If you find the content useful, please share it with your network and drop a like 👍 it really helps these posts reach more Linux, DevOps, and Cloud folks. Your likes and shares are what keep me motivated to keep writing consistently. Thanks in advance for your ideas and support! #Git #VersionControl #DevOps #Linux #SoftwareDevelopment #GitRebase #BranchManagement #LearningJourney #TechCareers

🚀 Hi all, one of the most asked interview questions in DevOps & Git is: “Explain common Git commands with Daily usage.” Let’s break down some important Git commands line by line 👨💻👇 🔹 1. git init 👉 Initializes a new Git repository 📌 Used when starting a new project 💡 Creates a hidden .git folder to track changes 🔹 2. git clone <repo_url> 👉 Copies an existing repository from remote to local 📌 Example: cloning from GitHub 💡 Automatically sets remote origin 🔹 3. git status 👉 Shows current state of the repository 📌 Displays: Modified files Staged files Untracked files 🔹 4. git add <file> 👉 Adds changes to staging area 📌 Example: git add app.py 💡 Use git add . to add all files 🔹 5. git commit -m "message" 👉 Saves changes to local repository 📌 Message should be meaningful 💡 Represents a snapshot of your project 🔹 6. git push origin <branch> 👉 Uploads local commits to remote repo 📌 Example: git push origin main 💡 Used after committing changes 🔹 7. git pull 👉 Fetch + merge changes from remote 📌 Keeps your local repo updated 💡 Equivalent to git fetch + git merge 🔹 8. git branch 👉 Lists or creates branches 📌 Example: git branch feature-login 💡 Helps in parallel development 🔹 9. git checkout <branch> 👉 Switches between branches 📌 Example: git checkout main 💡 Use -b to create & switch 🔹 10. git merge <branch> 👉 Merges another branch into current branch 📌 Example: merging feature → main 💡 May cause conflicts (need resolution) 🔹 11. git log 👉 Shows commit history 📌 Useful for tracking changes 💡 Add --oneline for short view 🔹 12. git reset 👉 Undo changes (soft/hard reset) 📌 Used carefully ⚠️ 💡 Can remove commits or unstage files 🔥 If you found this helpful: 👉 Follow me for more DevOps & Cloud interview questions #DevOps #Git #Cloud #AWS #Kubernetes #InterviewPreparation #SoftwareEngineering #cloudinterviewquestions #devopsinterviewquestions #githubinterviewquestions