Git & GitHub Essentials for Developers

𝑼𝒏𝒅𝒆𝒓 𝒕𝒉𝒆 𝑯𝒐𝒐𝒅: 𝑮𝒊𝒕 & 𝑩𝒊𝒕𝒃𝒖𝒄𝒌𝒆𝒕 — the clarity I wish I had earlier I spent almost 2 days trying to truly understand Git and Bitbucket. Not commands. Not diagrams. But what actually happens under the hood. Here’s the clarity that finally clicked — sharing it so someone else gets it in the first read. 🔹 1. 𝐓𝐡𝐞𝐫𝐞 𝐚𝐫𝐞 𝐓𝐖𝐎 𝐆𝐢𝐭 𝐫𝐞𝐩𝐨𝐬𝐢𝐭𝐨𝐫𝐢𝐞𝐬, 𝐧𝐨𝐭 𝐨𝐧𝐞 𝐋𝐨𝐜𝐚𝐥 𝐆𝐢𝐭 → on your laptop 𝐒𝐞𝐫𝐯𝐞𝐫-𝐬𝐢𝐝𝐞 𝐆𝐢𝐭 → on Bitbucket’s server 👉 Bitbucket does not replace Git 👉 Bitbucket wraps and exposes a server-side Git repository Git exists on both sides. 🔹 2. 𝐆𝐢𝐭 𝐢𝐬 𝐭𝐡𝐞 𝐞𝐧𝐠𝐢𝐧𝐞. 𝐁𝐢𝐭𝐛𝐮𝐜𝐤𝐞𝐭 𝐢𝐬 𝐭𝐡𝐞 𝐢𝐧𝐭𝐞𝐫𝐟𝐚𝐜𝐞. 𝐆𝐢𝐭 𝐢𝐬 𝐫𝐞𝐬𝐩𝐨𝐧𝐬𝐢𝐛𝐥𝐞 𝐟𝐨𝐫: tracking file changes creating commits managing branches merging code 𝐁𝐢𝐭𝐛𝐮𝐜𝐤𝐞𝐭 𝐩𝐫𝐨𝐯𝐢𝐝𝐞𝐬: UI permissions Pull Requests code review & approvals 👉 All real work is done by Git 👉 Bitbucket adds visibility and control 🔹 3. 𝐂𝐨𝐦𝐦𝐢𝐭 𝐡𝐚𝐩𝐩𝐞𝐧𝐬 𝐎𝐍𝐋𝐘 𝐢𝐧 𝐆𝐢𝐭 (𝐥𝐨𝐜𝐚𝐥𝐥𝐲) When you modify files → Git sees changes When you commit: Git saves a snapshot Git creates a commit ID This happens only in local Git Bitbucket has no role here 👉 Commits are Git objects, not Bitbucket actions 🔹 4. 𝐏𝐮𝐬𝐡 𝐜𝐨𝐩𝐢𝐞𝐬 𝐜𝐨𝐦𝐦𝐢𝐭𝐬 𝐭𝐨 𝐬𝐞𝐫𝐯𝐞𝐫-𝐬𝐢𝐝𝐞 𝐆𝐢𝐭 git push does NOT create new commits 𝐈𝐭 𝐜𝐨𝐩𝐢𝐞𝐬 𝐭𝐡𝐞 𝐬𝐚𝐦𝐞 𝐜𝐨𝐦𝐦𝐢𝐭𝐬: from local Git to server-side Git (on Bitbucket) 👉 After push: Server-side Git already has updated files Changes exist in the feature branch Bitbucket UI just shows what Git already has. 🔹 5. 𝐅𝐞𝐭𝐜𝐡 𝐯𝐬 𝐏𝐮𝐥𝐥 (𝐢𝐦𝐩𝐨𝐫𝐭𝐚𝐧𝐭 𝐝𝐢𝐬𝐭𝐢𝐧𝐜𝐭𝐢𝐨𝐧) 𝐅𝐞𝐭𝐜𝐡: Downloads information from server Git Does NOT change your files 𝐏𝐮𝐥𝐥: Fetch + merge Updates your local files 👉 Both are Git operations, not Bitbucket logic. 🔹 6. 𝐏𝐮𝐥𝐥 𝐑𝐞𝐪𝐮𝐞𝐬𝐭 𝐢𝐬 𝐍𝐎𝐓 𝐆𝐢𝐭 𝐏𝐮𝐥𝐥 𝐑𝐞𝐪𝐮𝐞𝐬𝐭 (𝐏𝐑): belongs to Bitbucket is for comparison, review, and approval 𝐏𝐑: does NOT create commits does NOT change code does NOT copy files 👉 PR is a decision layer, not an execution layer 🔹 7. 𝐌𝐞𝐫𝐠𝐞 𝐢𝐬 𝐰𝐡𝐞𝐫𝐞 𝐜𝐨𝐝𝐞 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐦𝐨𝐯𝐞𝐬 𝐛𝐫𝐚𝐧𝐜𝐡𝐞𝐬 When PR is approved and merged: Bitbucket UI triggers the action Git performs the merge Feature branch commits are applied to target branch (main/develop) 👉 Merge is Git’s job 👉 PR only controls when merge is allowed #git #bitbucket

If your Git & GitHub workflow feels chaotic, this is how you fix it. Here’s a simple, production-ready setup that gives you real results, not just rules: ✅ Cleaner commit history So you instantly understand what changed and why — even months later. ✅ Fewer bugs reaching production Because nothing goes to main without a pull request and automated checks. ✅ Faster code reviews Clear PR templates + labels = less back-and-forth, more signal. ✅ Confidence while deploying You always know what’s in main and what’s still in progress. The core setup (easy to follow) • main → production-ready • develop → active work • feature/*, bugfix/*, hotfix/* Commit messages that actually help Instead of: ❌ “fix bug” Use: ✔ fix(cart): correct total price calculation ✔ feat(auth): add OTP login Labels that save time (not waste it) • type: bug / feature / refactor • priority: high / medium / low • status: in-progress / blocked / ready Now issues tell a story at a glance. Automation that protects you Every pull request automatically: • installs dependencies • runs tests • blocks broken code from merging No memory. No reminders. Just safety. Works for everyone Solo developer? You get clarity, safety, and future-proof history. Team developer? You get predictable reviews, fewer conflicts, and calmer releases. This is the kind of Git setup that disappears into the background and lets you focus on building. If your current workflow causes: • stress before merges • fear of breaking production • confusion in Git history It’s time to simplify. How do you currently manage Git in your projects? #Git #GitHub #SoftwareEngineering #DeveloperProductivity #WebDevelopment Read full blog post here: https://lnkd.in/gSthbtmg

WHEN SHOULD I USE THESE GIT COMMANDS? GIT COMMANDS CHEAT SHEET FOR BEGINNERS 1. git init • Start a new local Git repository 2. git clone <url> • Copy an existing remote repository to your computer 3. git add <file> or git add . • Stage changes (tell Git which files to include in the next commit) 4. git commit -m "Your message" • Save a snapshot of your staged changes with a message 5. git branch • List, create, or delete branches 6. git checkout -b <branch-name> or git switch -c <branch-name> • Create and switch to a new branch 7. git checkout <branch-name> or git switch <branch-name> • Switch between branches 8. git merge <branch-name> • Combine changes from one branch into your current branch 9. git push origin <branch-name> • Upload your local commits to the remote repository 10. git pull • Fetch latest changes from remote and merge them into your current branch 11. git status • Show what files are changed, staged, or untracked 12. git log • View commit history Quick Workflow Most Teams Use Daily: 1. git pull origin main Get latest code 2. git checkout -b feature/new-login Start your work 3. (code, code, code...) 4. git add . Stage everything 5. git commit -m "Add login page" Save your work 6. git push origin feature/new-login Share it 7. Create Pull Request on GitHub/GitLab 8. After review & approval merge into main Happy coding,! 🚀 #Git #DevOps #90DaysOfDevOps

From Changes to History: How Git Records Your Work If you’ve been following my Git series, welcome back: Post 1: From Zero to GitHub Beginner Friendly Workflow Post 2: Essential Git Commands (With Short Notes) Today, let’s talk about **commits the heart of Git** ❤️ A commit is like pressing “save” on your project but smarter, it captures a snapshot of your work at a specific moment in time , with commits, you can: Track your progress Undo mistakes Collaborate with confidence Here’s a simple, human friendly walk through: Step 1: Create your project folder Create and name your folder, then open it in VS Code (or your preferred editor). Step 2: Configure Git (one-time setup) Open your terminal and tell Git who you are, this information will appear in your commits: git config --global user.name "Your Name" git config --global user.email "you@email.com" To confirm it worked: git config --list Step 3: Initialize your repository Inside your project folder: git init Then create a new repository on GitHub and connect it to your local project. Step 4: Check your project status Think of this as your Git dashboard: git status It shows new files, modified files, and what’s staged for commit. Step 5: Review what changed Before committing, double check your edits: git diff This shows line by line changes so nothing surprises you later. Step 6: Stage your changes Choose what goes into your next commit: git add filename git add --all git add -A Step 7: Commit your work Save your snapshot with a clear message: git commit -m "Describe your changes" Tip: Good commit messages saves you a lot of stress. Step 8: View your history See your project’s timeline: git log You’ll see all commits like a roadmap of your work. When you master git status, git diff, staging, and commits, your projects stop feeling messy and start feeling structured and traceable. Git doesn’t just store code it tells the story of your progress. 🌱 #Git #GitHub #VersionControl #DevTools #SoftwareDevelopment #BeginnerFriendly #CodingJourney #TechLearning #VSCode #Developers

My GIT - Cheat sheet 𝐏𝐫𝐨 𝐭𝐢𝐩 - To learn Git better, ditch the GUI and use the command line. 𝐖𝐡𝐚𝐭? A distributed version control system that tracks changes in files over time. 𝐖𝐡𝐲? Enables collaboration, branching, merging and a complete project history. 📌 𝐊𝐞𝐲 𝐓𝐞𝐫𝐦𝐢𝐧𝐨𝐥𝐨𝐠𝐢𝐞𝐬 - ◾ Repository A directory containing your project's complete history. ◾ Working Directory The current state of your project files. ◾ Staging Area (Index) Where you prepare changes for the next commit. ◾ Commit A snapshot of your project at a specific point in time. ◾ Branch A separate line of development. Remote: A version of your repository hosted on a server (e.g., GitHub, GitLab). 📌 𝐆𝐢𝐭 𝐁𝐞𝐬𝐭 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞𝐬 [1.] Commit Early, Commit Often ◾ Don't let changes pile up. ◾ Commit frequently to create smaller, more manageable snapshots of your work. ◾ This makes it easier to track progress, identify issues and revert if needed. [2.] One Change per Commit ◾ Keep your commits focused on a single logical change or feature. ◾ This improves readability and makes it easier to isolate and revert specific changes. [3.] Clear Commit Messages ◾ Write concise yet descriptive commit messages that explain what you changed and why. ◾ This makes it easier for you and your collaborators to understand the purpose of each commit in the future. ◾ Include some change or ticket # [4.] Merge or Rebase ◾ Use git merge to combine branches, or git rebase to apply your changes on top of another branch. ◾ Choose the method that best suits your workflow and preferences. [5.] Delete Merged Branches ◾ Once a branch has been merged, delete it to keep your repository tidy and avoid confusion. [6.] Pull Regularly ◾ Always fetch and merge the latest changes from the remote repository before starting new work. ◾ This helps avoid conflicts and keeps your local repository in sync with your team. [7.] Code Reviews ◾ Use pull requests or similar mechanisms to get feedback on your changes before merging them into the main branch. ◾ Code reviews help catch errors, improve code quality and ensure consistency across the codebase. [8.] Resolve Conflicts Carefully ◾ If conflicts arise when merging branches, resolve them carefully and thoroughly. ◾ Test your changes after resolving conflicts to ensure everything works as expected. git commit -m "works on my machine" 🙂 Follow Mayank for more such insights.

🚀 Master the Git Workflow: A Quick Guide Whether you're a seasoned dev or just starting, these 20 commands are your bread and butter. Here is the simple breakdown: 🛠️ The Basics git init: 🆕 Create a brand new local repository. git config: 👤 Set your identity (name & email). git clone: 👯 Copy an existing remote project to your machine. git remote: 🔗 Manage connections to external repositories. 📝 Daily Development git status: 👀 See what files you've changed or staged. git add: 📥 Move changes to the "staging area" (prepare for save). git commit: 💾 Save your staged changes to project history. git push: 📤 Upload your local saves to the cloud (GitHub/GitLab). 🔄 Staying Updated git pull: 📥 Download and merge updates from teammates. git fetch: 🔍 See what’s new on the remote without merging yet. git branch: 🌿 Create or list different versions of the project. git checkout: 🏃♂️ Jump between different branches. 🔀 Merging & Cleaning git merge: 🤝 Combine work from two different branches. git rebase: 🪜 Move your commits to a new starting point for a cleaner history. git log: 📖 View the "timeline" of every save ever made. git diff: 📋 Compare exactly what lines of code changed. 🆘 The "Oops" & Advanced Tools git stash: 📦 Temporarily hide messy work to fix a quick bug elsewhere. git reset: ⏪ Unstage files or undo commits entirely. git revert: 🛡️ Create a "counter-commit" to undo a past mistake safely. git cherry-pick: 🍒 Grab one specific commit from another branch and apply it here. Which Git command do you use most often? Let me know in the comments! 👇 #SoftwareDevelopment #CodingTips #Git #Programming #WebDev #TechCommunity

What I Learned About Git & GitHub (Hands-On) Recently, I practiced Git & GitHub hands-on and learned how real version control works beyond basic theory. Here are some of the key Git commands and concepts I worked with 👇 🔹 Repository setup: git init, git status, git config 🔹 Tracking changes: git add, git commit, git diff, git diff --staged 🔹 Branching & navigation: git branch, git switch, git switch -c 🔹 Merging & conflict handling: git merge, resolving merge conflicts manually 🔹 History & safety concepts: git stash, git log, understanding staged vs unstaged changes 🔹 Remote operations: git push, git pull, handling README conflicts, git push --force 🔹 Advanced understanding: git rebase vs git merge, clean vs preserved history, file encoding issues, .gitattributes 💡 Key takeaway: Git makes much more sense when you actually face errors, fix them, and understand why they happen. Looking forward to applying this knowledge in real projects #Git #GitHub #VersionControl #LearningByDoing #DeveloperJourney #DataEngineering

If anyone is interested in developing their skills in Git, here’s a quick thought based on experience that might be helpful. 💬 Tips for developing strong Git skills: Learn the basics deeply: Understand init, clone, add, commit, status, log, diff, branch, merge, and rebase. Depth matters more than speed early on. Use Git daily: Even for small personal projects. Real learning happens through repetition and mistakes. Write meaningful commit messages: Treat commits as documentation. Clear messages make collaboration and debugging easier. Practice branching workflows: Learn Git Flow, feature branches, and hotfix branches to understand real-world team workflows. Get comfortable with conflicts: Don’t avoid merge conflicts—resolve them manually to understand how Git actually works. Explore GitHub/GitLab: Use pull requests, code reviews, issues, and CI tools to simulate professional environments. Read Git history: Use git log, blame, and bisect to trace bugs and understand project evolution. Break things on purpose: Experiment in test repos. Recover using reset, reflog, and stash. Learn from others’ repositories: Study how experienced developers structure commits and branches. Understand Git conceptually: Commits, HEAD, pointers, and DAGs—once these click, Git becomes much easier. Mastering Git isn’t about memorizing commands; it’s about understanding how version control thinks.

𝗚𝗶𝘁 𝗕𝗮𝘀𝗶𝗰𝘀 𝗠𝗮𝗱𝗲 𝗦𝗶𝗺𝗽𝗹𝗲 You want to learn Git basics. Git is a version control system that helps you track your code. It keeps track of code changes in your project along with the author information. Here's why you need Git: - It helps you collaborate with your team - It allows you to work on multiple features at the same time - It helps you fix mistakes in your code Some key terms you should know: - Repository: your project folder - Add: start tracking your file - Commit: make your changes permanent - Head: a pointer to your latest commit - Branch: separate different features from your main code To use Git, you need to install it on your computer. Then you can initialize Git in your project with the command: git init This sets up an empty Git repository in your project. You can then track your code changes with these commands: - git add: add a file to the staging area - git commit: make your changes permanent - git status: see the status of your files - git log: see all your commit details - git diff: see the difference between two commits - git revert: revert a commit - git reset: move back to a previous commit Remember to use these commands to manage your code and recover from mistakes. In the next post, we'll explore more about Git's file structure. Source: https://lnkd.in/g9JvYWJ3

Git vs GitHub. They're not the same thing Up until recently I thought they were basically the same thing or just different versions of each other. Turns out, not quite. Git is the actual version control tool that tracks and manages your code changes. It lives on your machine and lets you do things like commit changes, create branches, and roll back code when needed. GitHub is the online platform where you host those Git repositories. It's where teams share code, collaborate, review each other's work, and hook into tools like CI/CD pipelines. Simple way to think about it: Git is the tool, GitHub is the platform. Now I’m understanding the difference, version control starts making more sense. It also made it clear why Git is such a core part of development workflows.