Basavaprabhu patil’s Post

🚀 𝟗𝟎 𝐃𝐚𝐲𝐬 𝐨𝐟 𝐃𝐞𝐯𝐎𝐩𝐬 | 𝐋𝐞𝐚𝐫𝐧𝐢𝐧𝐠 𝐢𝐧 𝐏𝐮𝐛𝐥𝐢𝐜 | 𝐇𝐚𝐧𝐝𝐬-𝐎𝐧 | 𝐏𝐫𝐨𝐣𝐞𝐜𝐭𝐬 🌳 Unlocking the Power of Git: Branching & GitHub! Day 23 of #90DaysOfDevOps is done! ✅ Today I learned why Git is truly a superpower for teams. If you are still committing directly to `main`, you are living dangerously! ⚠️ ✅ Created feature-1, feature-2 branches ✅ git switch vs git checkout ✅ Pushed main + feature branch to GitHub ✅ Learned origin vs upstream Key takeaway:  Branches = Safe experimentation! 💥 👨💻 What I mastered today: 🔹 Branching: Created parallel timelines (`git switch -c`) to build features in total isolation without touching the stable production code. 🔹 GitHub Integration: Connected my local terminal to the cloud (`git remote add origin`) and pushed my first branches to the web! 🔹 Forking vs. Cloning: Understood the difference between downloading a repo to my laptop (Clone) vs. creating a personal cloud copy of an open-source project (Fork) to contribute to it via Pull Requests. 💡 Mind-Blowing Moment: Watching a file physically disappear from my folder when I switched back to `main`, and then reappear instantly when I switched back to my `feature-1` branch. Git is essentially time travel for your files. ⏳ 🔗💻 GitHub Repo: https://lnkd.in/eQQbES74 #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #Git #GitHub #OpenSource #DevOpsJourney

𝗗𝗮𝘆 𝟮𝟮 𝗼𝗳 𝗺𝘆 𝗗𝗲𝘃𝗢𝗽𝘀 𝗝𝗼𝘂𝗿𝗻𝗲𝘆 💻 Bringing code to life — cloned a Git repository to create a working copy for development 📥 𝗧𝗮𝘀𝗸: Clone Git Repository on Storage Server 𝗪𝗵𝗮𝘁 𝗜 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 𝘁𝗼𝗱𝗮𝘆: • Difference between bare repository and working repository • How `git clone` creates a local working copy • Cloning repositories from local paths (not just GitHub) • Importance of using correct user permissions • Safe handling of shared repositories in production environments 𝗪𝗵𝗮𝘁 𝗜 𝗯𝘂𝗶𝗹𝘁 / 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝗱: • Logged into Storage Server (`ststor01`) as `natasha` • Verified existence of repository `/opt/games.git` • Created destination directory `/usr/src/kodekloudrepos` • Cloned repository using `git clone /opt/games.git` • Verified working copy using `git status` 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀: • Understanding local path-based cloning • Ensuring no permission or structure changes were made • Being careful to use the correct user (`natasha`) 𝗙𝗶𝘅 / 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴: • Learned that cloning from local repositories works the same as remote • Understood importance of maintaining repository integrity • Gained clarity on how working copies are used in development 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆: Cloning is where development begins — it bridges the gap between a central repository and actual coding work. This felt like a real-world Git workflow setup 🚀 Do you mostly clone from local repos, GitHub, or enterprise tools like GitLab/Bitbucket? #Day22 #DevOps #Git #VersionControl #Linux #Automation #CloudComputing #AWS #DevOpsJourney #LearningInPublic #100DaysOfDevOps

#100DaysOfDevOps - Day Forty - Three So today I focused on connecting GitHub and Jenkins through a webhook. What I worked on today: ✅ understood what a webhook really is ✅ looked at webhooks as an event-driven communication mechanism ✅ connected the idea of: developer pushes code GitHub detects the event Jenkins receives the trigger Jenkins runs the pipeline automatically ✅ configured a webhook in the GitHub repository settings ✅ learned the Jenkins webhook endpoint format ✅ discovered why local IPs and localhost do not work for GitHub callbacks ✅ used ngrok to expose my local Jenkins service publicly ✅ authenticated ngrok and mapped it to the Jenkins port ✅ updated the webhook with the public URL ✅ confirmed successful delivery with a 200 response Big takeaway: CI/CD is not just about writing a pipeline. It is also about creating the event flow that tells the pipeline when to run. That small webhook setup makes a very big difference. YouTube Video Link: https://lnkd.in/eJW2gSPf #DevOps #100DaysOfDevOps #Jenkins #GitHub #Webhooks #CICD #ContinuousIntegration #Automation #ngrok #PipelineAsCode #PlatformEngineering #CloudEngineering #LearningInPublic #TechdotSam

Once I understood the core commands, everything changed, here is the GitHub Crash Course for you . . If you're still stuck on "how to use GitHub properly"? Here's a simple breakdown that helped me (and will help you too): - Repository = Project folder (local or remote) - Commit = Save a snapshot of your changes - Branch - Parallel version of your project - Merge = Combine branches - Clone / Push/Pull = Sync local and remote repos Most Useful Git Commands (with purpose): git init: # Start a new Git repo git clone <url>: # Copy repo to your local system git status: # See current changes git add.: # Stage all files for commit git commit -m "msg": # Save changes with message git push: # Upload changes to GitHub git pull: # Fetch latest from GitHüb git branch: # List branches git checkout -b dev: # Create & switch to new branch git merge dev: # Merge dev into main Connect Swadesh Kumar for more such content Repost it to share in your network Save it if you don't wanna miss it Comment "GitHub" & I'll DM it to you directly. Bonus Tips: ✅ Always write meaningful commit messages ✅ Never push directly to main in a team project ✅ Use.gitignore to avoid uploading junk files

Let me explain Git and GitHub the most simplest way possible. 🥰🥰 You know when you are writing an important document and you save it like this 📄 Document v1 📄 Document v2 📄 Document FINAL 📄 Document FINAL FINAL 📄 Document THIS IS THE ONE You do this because you are scared of losing your work. Or because you might need to go back to an older version. Git does exactly this for your code. Automatically. Professionally. Without the chaos. Every time you save your progress in Git (called a commit) Git takes a snapshot of your entire project. So if you break something today? You can go back to yesterday’s version instantly. And GitHub? GitHub is simply where you store all of that online. So your work is safe even if your laptop crashes. And other developers can collaborate with you too. Git = your personal save history GitHub = the cloud where that history lives ☁️ Every developer needs both. Did you understand Git and GitHub before reading this? Drop YES or NO below. ⬇️ #Git #GitHub #WebDevelopment #FrontendDeveloper

🚀 CI/CD with Jenkins vs GitHub Actions — what should you actually use? I’ve been exploring CI/CD while working on backend projects, and one thing became clear — both Jenkins and GitHub Actions solve the same problem, but in very different ways. Here’s how I see it: 🔧 Jenkins Feels like the “full control” option. You can customize almost everything, build complex pipelines, and manage it exactly the way you want. But… you also have to set it up, maintain it, and deal with plugins and servers. ⚡ GitHub Actions Much simpler to start with. If your code is already on GitHub, you just write a workflow file and you’re good to go. No server setup, no extra headache. 🧠 The real difference (in simple terms): Jenkins → more control, more responsibility GitHub Actions → less setup, faster to start 🔥 One important thing I misunderstood earlier: Docker helps you run your app consistently, but tools like Jenkins or GitHub Actions decide: 👉 when to build 👉 when to test 👉 when to deploy 💡 So what should you use? If you’re working on large or complex systems → Jenkins makes sense If you want quick setup and clean workflow → GitHub Actions is a great choice At the end of the day, both are powerful. It just depends on your use case. #cicd #devops #jenkins #githubactions #docker

🚀 Day 25 – Git Reset vs Revert & Branching Strategies Today was all about fixing mistakes the right way in Git 🔧 Hands-on with Git Reset: 🔹 Explored --soft, --mixed, and --hard 🔹 Learned how each affects commits, staging, and working directory 🔹 Understood why --hard is destructive 🔄 Git Revert: 🔹 Reverted a specific commit safely 🔹 Learned that history is preserved (no deletion) 🔹 Realized why revert is preferred for shared branches Reset vs Revert: Reset = rewrite history Revert = create a new undo commit Revert is safer for collaboration Branching Strategies: 🔸 GitFlow – structured, multiple branches 🔸 GitHub Flow – simple and fast 🔸 Trunk-Based Development – short-lived branches, fast integration Key Takeaways: Never use reset --hard on pushed code Use revert when working in teams Branching strategy depends on team size & release cycle #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #Git #GitHub #DevOps #LearningInPublic #TechJourney #SoftwareEngineering #Cloud #OpenSource #DeveloperJourney #BuildInPublic #CareerGrowth #EngineeringLife #Linux #Automation #CI_CD

𝗗𝗮𝘆 𝟯𝟮 𝗼𝗳 𝗺𝘆 𝗗𝗲𝘃𝗢𝗽𝘀 𝗝𝗼𝘂𝗿𝗻𝗲𝘆 💻 Keeping history clean — used Git rebase to update a feature branch without creating extra merge commits 🔄 𝗧𝗮𝘀𝗸: Git Rebase 𝗪𝗵𝗮𝘁 𝗜 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 𝘁𝗼𝗱𝗮𝘆: • How `git rebase` helps maintain a clean, linear history • Difference between `merge` vs `rebase` • Why rebase avoids unnecessary merge commits • Importance of syncing feature branches with latest `master` • When to use force push after rebase 𝗪𝗵𝗮𝘁 𝗜 𝗯𝘂𝗶𝗹𝘁 / 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝗱: • Navigated to repo `/usr/src/kodekloudrepos/games` • Switched to feature branch • Pulled latest changes from `master` • Rebased feature branch using `git rebase origin/master` • Resolved conflicts (if any) • Verified clean commit history using `git log` • Pushed updated branch using `git push --force` 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀: • Understanding difference between merge and rebase • Handling conflicts during rebase • Knowing when force push is required 𝗙𝗶𝘅 / 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴: • Learned that rebase rewrites commit history • Understood why it creates a cleaner project timeline • Gained clarity on resolving conflicts step-by-step • Realized rebase is widely used in professional workflows 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆: Rebase isn’t just about updating branches — it’s about keeping your Git history clean and readable. This felt like working with real-world collaborative Git workflows 🚀 Do you prefer using rebase or merge in your projects — and why? #Day32 #DevOps #Git #VersionControl #Linux #Automation #CloudComputing #AWS #DevOpsJourney #LearningInPublic #100DaysOfDevOps

🚀 Day 6/30 – Merging & Pull Requests in Git Taking my Git & GitHub skills to the next level today! 💻🔥 After understanding branching, today I explored how everything comes together — Merging & Pull Requests 🔀 Initially, I thought merging is simple… but conflicts made me realize the real challenge 😅 🔹 What I learned today: • How merging works in Git • What are merge conflicts & why they happen • How to resolve conflicts step-by-step • What is a Pull Request (PR) in GitHub • How teams collaborate using PR workflow 💻 Hands-on: • Created multiple branches • Merged branches into main • Faced and resolved a merge conflict • Raised my first Pull Request on GitHub 💡 Key takeaway: Merging is not just about combining code — it’s about collaboration, problem-solving & clean workflows. Consistency + Practice = Growth 🚀 #Day6 #30DaysChallenge #DevOpsJourney #Git #GitHub #LearningByDoing #Consistency #AWS

#Day18 -Today’s session focused on understanding essential Git operations and efficiently managing repositories using the GitHub interface. (Part-6) 1. Git Operations 📌 Git Repository (Clone, Pull, Fetch) ✅ Clone (First time download) Used when you don’t have the project locally. git clone https://lnkd.in/gmiGHMgJ  What it does: ▪️ Downloads entire repo ▪️ Creates a local copy ▪️ Connects to remote ✅ Pull (Get latest changes) git pull origin main  What it does: ▪️ Downloads changes ▪️ Automatically merges into your branch ✅ Fetch (Only download, no merge) git fetch origin  What it does: ▪️ Downloads latest changes ▪️ Does NOT change your code 💠 Important Concept  ▪️ Pull = Fetch + Merge  🔷 See All Branches (Local + Remote) ▪️ git branch       # Local branches ▪️ git branch -r    # Remote branches ▪️ git branch -a    # All branches 2. GitHub UI 📌  Create / Delete / Rename Branch (GitHub UI) ✅ Create Branch 1. Open repo in GitHub 2. Click branch dropdown (top-left) 3. Type new branch name 4. Click Create branch ✅ Delete Branch 1. Go to Branches 2. Find branch 3. Click Delete icon ✅ Rename Branch 1.Go to Branches 2. Click Edit (✏️) 3. Enter new name   🔷 Rename Repository 1. Open repo in GitHub 2. Go to Settings 3. Change repository name 4. Click Rename 🔷 Rename Default Branch 1. Go to Settings → Branches 2. Change default branch (e.g., main → dev) 🔷 Change Repository to Private 1. Open repo → Settings 2. Scroll to Danger Zone 3. Click Change visibility 4. Select Private   🔷 Transfer Repository Ownership 1. Go to Settings 2. Scroll to Danger Zone 3. Click Transfer ownership 4. Enter: ▪️ New owner username ▪️ Repository name (for confirmation) Result: ▪️ New user becomes owner ▪️ You lose control (unless added back)    🔷 Delete Repository ⚠️ Dangerous action (permanent) Steps: 1. Go to Settings 2. Scroll to Danger Zone 3. Click Delete this repository 4. Type repo name 5. Confirm delete #DevOps #CloudComputing #AWS #LINUX #GIT #GITHUB #Frontlinesedutech #flm #CTA