Git Fundamentals for Developers: Essential Commands and Best Practices

Day 29 Of DevOps 🚀 All Important Bitbucket Commands (Git + CLI + Pipelines) Bitbucket is built on top of Git, so most Bitbucket operations use Git commands. Below is a complete practical command reference for DevOps engineers 👇 🔹 1️⃣ Repository Setup git clone https://lnkd.in/gCKqsdNX git init git remote add origin <repo-url> git remote -v 🔹 2️⃣ Basic Workflow Commands git status git add . git add <file> git commit -m "PROJ-101 added login API" git push origin main git pull origin main git fetch origin 🔹 3️⃣ Branching Commands git branch git branch feature/PROJ-101-login git checkout feature/PROJ-101-login git checkout -b bugfix/PROJ-102-timeout git switch main git merge feature/PROJ-101-login git branch -d feature/PROJ-101-login 🔹 4️⃣ Tagging (Releases) git tag git tag v1.0.0 git push origin v1.0.0 🔹 5️⃣ Undo / Reset Commands git reset --soft HEAD~1 git reset --hard HEAD~1 git revert <commit-id> git checkout -- <file> git reflog 🔹 6️⃣ Stashing Changes git stash git stash list git stash apply git stash pop 🔹 7️⃣ Pull Request (CLI via REST API Example) Bitbucket PRs are usually created via UI, but can also be created using API: curl -X POST -u username:app_password \ https://lnkd.in/gAaPDwSS \ -d '{"title": "PR for PROJ-101", "source": {"branch": {"name": "feature/PROJ-101-login"}}, "destination": {"branch": {"name": "main"}}}' 🔹 8️⃣ Bitbucket Pipelines Commands Bitbucket uses a bitbucket-pipelines.yml file in the repo root. Example: pipelines:  default:    - step:        name: Build & Test        script:          - echo "Running build"          - mvn clean install Push code → Pipeline triggers automatically. 🔹 9️⃣ Best Practice (Jira Integration) Always include Jira ticket key in: Branch name → feature/PROJ-101-description Commit message → PROJ-101 fixed issue This auto-links to Jira. 🔥 Real DevOps Workflow 1️⃣ Create branch 2️⃣ Commit changes 3️⃣ Push to Bitbucket 4️⃣ Create Pull Request 5️⃣ Pipeline runs 6️⃣ Merge after approval 7️⃣ Deploy 🎯 Most Used Daily Commands ✔ git clone ✔ git checkout -b ✔ git add ✔ git commit ✔ git push ✔ git pull ✔ git merge ✔ git rebase #Bitbucket #Git #DevOps #CICD #Atlassian #VersionControl #Automation #SoftwareDevelopment #CloudEngineering #TechCareers

Git repositories are really good sources of truth. But right now the interfaces for working with them are almost exclusively designed for engineers. A git repository is really just a folder—a collection of files. We think of them as places to store code, but that’s a limitation we impose, not of the technology. Files could be almost anything—structured data, narrative prose, photos, diagrams… At Button School, we keep all of our learning materials, our internal tools, our website content, and our experiments in a monorepo. We aren’t unique in this: many companies keep documentation in their repo alongside their apps and services. This means that the whole team, me, our learning designer, our product lead, and even our content advisor all work with our repo. Our content can be versioned, we use pull requests to review changes before we finalize them. There are points of friction working this way: it means everyone has an IDE set up on their machines, which is not everyone’s natural working environment. It’s right there in the name Integrated Development Environment. We accept it because of all the other benefits we get from working this way. Non-engineers are already coming into our repos, and there are only going to be more of them. The question of if they should is being answered on its own. We need to answer the question of what kind of tools they need. Where are the content environments, design environments, management environments, product environments that can work with a local repository? What’s the amount of abstraction these kinds of environments should apply? How can environments shaped for these perspectives feel like a working homebase for non-engineers to work with git-based workflows, branches and worktrees and remotes and pull requests and all? What will concepts like linting, package management, environment management, automated testing, project scaffolding look like for content, project management, design concepts, scenario and strategy planning, research ops? How will these environments handle sensitive data that shouldn’t be committed to a repository? How can we make a seamless experience for pulling in data sources and media assets from outside of the repository without them having to set up Docker and environment variables? Can we? As technologists, we’ve spent a ton of energy on developer experience (DX) for the past decade-plus. It’s time to expand that idea outside of this narrow idea that a developer is someone who writes code. Content, strategy, insights, planning, design, experiments: these are all developed as well. Let’s turn our attention to making what has traditionally been our home feel welcoming for everyone else involved in developing digital products. The robots absolutely will not do this for us. This project will take all of us in the same way DX has taken countless small side projects, long conversations, advocacy, standards governance, and education. I really hope we are up for the challenge.

🚀 Deep Dive into Git: Tags, Forks, Merge Conflicts & Bitbucket As part of DevOps and version control, There are some essential Git concepts that play a critical role in real-world development workflows. Here’s a detailed breakdown 👇 🔖 1. Git Tags – Managing Releases Efficiently Git tags are used to mark specific points in the repository history, typically to represent stable releases like v1.0, v2.0. There are two types of tags: ✔️ Lightweight Tags – Simple references to a commit ✔️ Annotated Tags – Include metadata like author name, date, and message 📌 Why Tags Matter: Help in release management Provide easy rollback points Widely used in CI/CD pipelines for deployments 💻 Common Commands: git tag v1.0 → Create tag git tag -a v1.0 -m "First release" → Annotated tag git push origin v1.0 → Push tag 🍴 2. Fork – Working Independently on Projects Forking allows you to create your own copy of a repository, enabling you to experiment or contribute without affecting the original project. This concept is commonly used in platforms like Bitbucket for open-source contributions. 📌 Typical Fork Workflow: 1️⃣ Fork the repository 2️⃣ Clone it to your local system 3️⃣ Create a new branch 4️⃣ Make changes and commit 5️⃣ Push changes to your fork 6️⃣ Create a Pull Request (PR) 🎯 Use Cases: Open-source contributions Safe experimentation Learning from real-world projects ⚔️ 3. Merge Conflicts – Handling Code Conflicts Merge conflicts occur when multiple developers modify the same lines of code or related parts of a file. Git cannot automatically decide which change to keep. 📌 How Conflicts Look: <<<<<<< HEAD Code from main branch ======= Code from feature branch >>>>>>> feature 🔧 Steps to Resolve Conflicts: ✔️ Check status using git status ✔️ Open the conflicted file ✔️ Manually edit and keep correct code ✔️ Remove conflict markers ✔️ Stage and commit changes 💡 Best Practices: Pull latest changes before starting work Commit frequently Keep branches small and focused Communicate with team members 🔀 4. Bitbucket – Git-Based Collaboration Platform Bitbucket is a Git repository hosting service that enables teams to collaborate efficiently. 🌟 Key Features: Repository hosting Pull requests & code reviews Branch permissions Integration with CI/CD pipelines Secure access control 📌 Basic Workflow in Bitbucket: 1️⃣ Create repository 2️⃣ Clone repository 3️⃣ Create feature branch 4️⃣ Make changes & commit 5️⃣ Push code 6️⃣ Create Pull Request 7️⃣ Review & merge 💼 Real-World Development Scenario In a team environment: Developers work on separate feature branches Code is pushed to remote repositories Pull Requests are created for review Merge conflicts (if any) are resolved Stable versions are tagged (e.g., v1.0) Code is deployed via CI/CD pipelines Mastering Git concepts like Tags, Forks, Merge Conflicts, and platforms like Bitbucket is essential for: ✔️ Efficient collaboration ✔️ Clean version control ✔️ Faster and safer deployments

Day 2 of #30DaysOfDevOps — Git & GitHub Basics Every DevOps engineer lives inside Git. If you don't understand how Git works, collaboration and CI/CD pipelines become a nightmare. Let's break it down. 1. What is Version Control? Version control tracks every change made to your codebase over time. Think of it as an unlimited undo button for your entire project — roll back anything, see who changed what, and work on multiple features in parallel. 2. Why Git? Git is distributed — every developer has a full copy of the repo locally. No internet? You can still commit, branch, and diff. It's the industry standard that every CI/CD tool integrates with natively. 3. The Three States of Git Working Directory — where you edit files Staging Area — where you prepare changes before committing Commit History — permanent snapshots of your project git add index.html git commit -m "Add landing page structure" 4. Essential Git Commands git init — create a new local repository git status — see what's changed and what's staged git add . — stage all modified files git commit -m "msg" — save a snapshot git log --oneline — view a clean commit history git diff — see exactly what changed before staging 5. Branching & Merging Branches let you work in isolation without touching the main codebase. git checkout -b feature/user-auth git checkout main git merge feature/user-auth 6. Connecting to GitHub git remote add origin https://lnkd.in/gQZps_k7 git branch -M main git push -u origin main 7. Resolving Merge Conflicts Conflicts happen when two branches edit the same lines. Git marks them: <<<<<<< feature/user-auth const port = 4000 ======= const port = 3000 >>>>>>> main Open the file, pick the correct version, remove the markers, then: git add app.js git commit 8. Challenges for Today 1. Configure your Git username and email globally. 2. Create a folder, initialize a repo, add files, and make your first commit. 3. Create a branch called feature-branch, make a change, and commit it. 4. Merge the feature branch into main and push to GitHub. Try them out and share what you build. Post 2 drops later today — Git Advanced: Rebase, Cherry-pick & Conflict Resolution. #DevOps #Git #GitHub #VersionControl #30DaysOfDevOps #LearningInPublic #DevOpsEngineer #CloudComputing

Day 18: Mastering Git Basics (Clone, Commit, Push, Pull) 🚀 Git is not just about commands — it’s the backbone of real-time development and team collaboration. 🔹 What is Git? Git is a distributed version control system that helps track code changes, manage versions, and collaborate efficiently across teams. 🔹 Core Git Commands with Real-Time Usage: ✅ git clone Download a remote repository to your local machine 👉 First step when joining a project "git clone <repo-url>" ✅ git commit Captures a snapshot of your changes locally 👉 Like saving your work with a meaningful message "git commit -m "Fixed login validation bug"" Tip: Always write clear and meaningful commit messages ✅ git push Uploads your local commits to the remote repository 👉 Makes your code visible to your team "git push origin main" ✅ git pull Fetches and merges latest changes from remote 👉 Always do this before starting work "git pull origin main" 🔹 Understanding Git Workflow (Important for Interviews): ✔️ Working Directory → where you write code ✔️ Staging Area → "git add" moves changes here ✔️ Repository → "git commit" saves permanently 🔹 Important Supporting Commands: ✔️ "git status" → check current changes ✔️ "git add ." → stage all changes ✔️ "git log" → view commit history ✔️ "git branch" → list branches ✔️ "git checkout -b feature/login" → create & switch branch 🔹 Real-Time Workflow: 1️⃣ Pull latest code → "git pull" 2️⃣ Create branch → "git checkout -b feature-name" 3️⃣ Do changes 4️⃣ Stage → "git add ." 5️⃣ Commit → "git commit -m "message"" 6️⃣ Push → "git push origin feature-name" 🔹 Branching Strategy (Real Projects): ✔️ main/master → stable production code ✔️ develop → integration branch ✔️ feature branches → for new features 🔹 Pull Request (PR) Flow 👉 After pushing code: ✔️ Create Pull Request ✔️ Code review by team ✔️ Fix comments (if any) ✔️ Merge into main branch 🔹 git fetch vs git pull: 👉 "git fetch" → only downloads changes 👉 "git pull" → fetch + merge 💡 Use fetch when you want to review before merging 🔹 Merge Conflict (Real Scenario): 👉 When two developers edit the same line 👉 Git cannot auto-merge → conflict occurs 👉 Needs manual resolution 🔹 Undo & Utility Commands: ✔️ "git reset" → undo commits ✔️ "git restore" → discard changes ✔️ "git stash" → save changes temporarily 🔹 .gitignore (Important in Projects): Used to ignore unnecessary files like: ✔️ node_modules ✔️ logs ✔️ environment files 🔹 Best Practices: ✔️ Pull before starting work ✔️ Never push directly to main ✔️ Use feature branches ✔️ Write meaningful commits ✔️ Resolve conflicts carefully 💡 Key Learning: Git is not just a tool — it’s about collaboration, code safety, and disciplined development workflow. #Day18 #Git #GitHub #VersionControl #SoftwareDevelopment #InterviewPreparation #LearningJourney

day-22 | 🚀 The World Before Git: How Developers Managed Code History Today, it’s hard to imagine software development without Git. Branching, merging, pull requests, and distributed collaboration feel completely natural. But Git is relatively young. Before it, developers spent decades experimenting with ways to track code changes. Here’s a quick journey through VCS history: 🧠 1. The Manual Era (1970s) Developers managed versions manually: Save copies like program_v1.c, program_v2.c Maintain backup folders Write change notes As software grew, this became unmanageable and error-prone. ⚙️ 2. SCCS — First Real VCS (1972) Created by Marc J. Rochkind at Bell Labs, SCCS introduced: ✔ Automatic revision tracking ✔ Retrieve older versions ✔ Basic branching & merging It used forward delta storage — storing the first version fully, then only changes. Efficient for storage, but slow to reconstruct older versions. ⚡ 3. RCS — Smarter Versioning (1982) Walter F. Tichy created RCS, improving SCCS: Reverse delta storage (latest version fully, older versions as changes) Faster operations for daily work Simpler commands, better branching, improved workflow 🌐 4. CVS — Collaborative VCS (1986) CVS added: ✔ Multi-file tracking ✔ Client–server architecture ✔ Remote team collaboration Limitations remained: file locking, no atomic commits, hard to manage large projects. 🏢 5. 1990s — Enterprise VCS Proprietary systems like ClearCase, SourceSafe, Perforce emerged: Advanced branching Enterprise workflow support High performance Mostly closed-source and costly. 🔄 6. SVN vs BitKeeper (2000s) SVN: Centralized, introduced atomic commits and better storage BitKeeper: Distributed VCS, full local copies, inspired Git 🐧 The Linux Kernel Crisis Linux used BitKeeper for distributed development but had licensing conflicts. No open-source alternative could match its performance. 🔥 2005 — Git Is Born Linus Torvalds created Git in two weeks: ✔ Extremely fast ✔ Distributed ✔ Strong data integrity ✔ Efficient branching & merging Git jokingly called the “stupid content tracker,” now powers GitHub, GitLab, Bitbucket. 💡 Takeaway Git is the result of decades of VCS evolution: Manual → SCCS → RCS → CVS → SVN → BitKeeper → Git Understanding this history helps developers truly appreciate Git’s design. 💬 What was your first experience with version control? #Git #SoftwareDevelopment #VersionControl #OpenSource #Programming #DevHistory #TechLearning #Learning

🚀 Mastering Unique Git Commands Every Developer Should Know Most developers use Git daily—but only a small percentage go beyond the basic commands like git add, git commit, and git push. Let’s explore some unique and powerful Git commands that can level up your workflow and make you stand out as a developer 💡 🔍 1. git reflog – Your Secret Backup System Ever lost a commit or messed up a branch? 👉 git reflog shows every action you’ve done in your repository—even deleted commits. Why it’s powerful: Recover lost commits Undo hard resets Debug your mistakes 💬 Think of it as your Git “history of history” ⏪ 2. git reset --soft / --mixed / --hard This command is misunderstood but extremely powerful. --soft → Keeps changes staged --mixed → Keeps changes unstaged --hard → Deletes everything (use carefully ⚠️) Use case: Fix wrong commits without losing work. 🧹 3. git clean -fd Want to remove unwanted files? 👉 This deletes: Untracked files Untracked folders Best for: Cleaning messy projects quickly. 🧠 4. git stash – Save Work Without Committing Switching branches but not ready to commit? 👉 Use git stash Save changes temporarily Switch branches safely Reapply later Pro Tip: Use git stash pop to bring changes back. 🔎 5. git bisect – Find Bugs Like a Detective This is one of the most underrated commands. 👉 git bisect helps you: Find the exact commit that introduced a bug Uses binary search internally Why it’s amazing: Saves hours of manual debugging. 🔄 6. git cherry-pick Want to copy a specific commit from another branch? 👉 Use git cherry-pick <commit-id> Use case: Move only important fixes Avoid merging entire branches 🧾 7. git blame Not about blaming people 😄 👉 Shows: Who wrote each line of code When it was written Best for: Understanding legacy code. 🧬 8. git rebase – Clean Commit History Instead of messy merge commits: 👉 Use git rebase Benefits: Cleaner history Linear commit structure Better for collaboration 🌳 9. git log --graph --oneline --all Want to visualize your Git history? 👉 This command shows a beautiful tree view Why it’s useful: Understand branches easily Track merges visually 🔐 10. git commit --amend Made a mistake in your last commit? 👉 Fix it without creating a new commit. Use case: Update commit message Add missed changes 💡 Final Thought Git is not just a version control tool—it’s a powerful time machine. Most developers only use 20% of Git’s capabilities. But mastering these unique commands can: ✔ Save time ✔ Reduce errors ✔ Make you a better engineer 🔥 Hashtags for LinkedIn #Git #SoftwareEngineering #Developers #Coding #TechTips #VersionControl #Programming #LearnGit #DeveloperTools #CareerGrowth

12 Most Common Git Commands: Every developer uses Git every single day. But most developers only know 4 or 5 commands and google the rest when they need them. That is fine until you are in a production incident, a merge conflict, or a collaborative codebase and you need to move fast with confidence. Here are the 12 commands that cover 95 percent of everything you will ever do in Git: -> git init Creates a new local repository in your current directory. This is where every project starts. One command to initialize version control from scratch. -> git clone Copies an existing remote repository to your local machine. The first thing you do when joining a project or starting work from an existing codebase. -> git status Shows the current state of your working directory and staging area. Which files are modified, which are staged, which are untracked. Run this constantly. It tells you exactly where you are. -> git add Moves changes from your working directory into the staging area. The staging area is your preparation zone before committing. You choose exactly what goes into the next snapshot. -> git commit Records the staged changes as a new snapshot in your local repository with a message describing what changed. Your message matters. Future you will thank present you for writing a clear one. -> git push Uploads your local commits to the remote repository on GitHub, GitLab, or wherever your team keeps the shared codebase. -> git pull Downloads the latest commits from the remote repository and merges them into your local branch. Always pull before you start new work to avoid unnecessary conflicts. -> git branch Lists, creates, renames, or deletes branches. A branch is a pointer to a specific commit. It lets you work on features or fixes in isolation without touching the main codebase. -> git checkout Switches your working directory to a different branch or commit. Be careful: it discards uncommitted changes in your current working directory. -> git merge Combines changes from one branch into another. If there are no conflicts, Git creates a new merge commit automatically. Conflicts require manual resolution. -> git diff Shows the differences between two commits, branches, files, or between your working directory and the staging area. Essential for reviewing what changed before committing. -> git log Shows the full history of commits in the current branch including messages, authors, and dates. Use it to understand what happened, when, and who did it. These 12 commands are the foundation. Everything else in Git builds on top of them. Which Git command took you the longest to fully understand? #Git #GitHub #VersionControl #Developers #SoftwareEngineering #Programming #DevTools

Technical Deep Dive: Mastering Git Workflows for Enterprise DevOps Version control is more than just git add and git commit. As a DevOps Engineer, how you manage your commit history determines how easily your team can debug, audit, and deploy infrastructure. This week, I’ve been refining my Git strategy by moving beyond the basics and into advanced repository management. Here are my technical takeaways: 1. The Architecture of Merging: Merge vs. Rebase The debate between git merge and git rebase is about Traceability vs. Linearity. Git Merge: Creates a "Merge Commit." It preserves the exact chronological history of when a feature branch was integrated. It’s the safest approach for shared/public branches. Git Rebase: Rewrites the project history by moving the entire feature branch to the tip of the main branch. The DevOps Verdict: I’m adopting a "Rebase-then-Merge" workflow. Rebase local feature branches to keep a clean, linear history, but use Merge for the final pull request into main to maintain an audit trail. 2. Efficient Conflict Resolution Merge conflicts are inevitable when multiple engineers modify the same lines in an automation script. My technical approach to resolution: Identify the conflict markers (<<<< HEAD vs >>>> branch). Manually reconcile logic (e.g., ensuring both percentage and multiplication functions coexist in my calculator script). Finalize with git add and a clean git commit. 3. The Power of git cherry-pick Sometimes you don't want the whole branch—you just want that one critical fix. git cherry-pick <commit-hash> allows me to surgically grab a specific bug fix from a development branch and apply it directly to production without bringing in unfinished features. 4. Security with Git Hooks In DevOps, we "Shift Left." By utilizing the .git/hooks directory, I can implement Pre-commit Hooks. These automated scripts can scan for: Hardcoded AWS Access Keys. Syntax errors in Shell scripts. Large files that shouldn't be in the repo. 5. The "Time Machine": git reflog When a git reset --hard goes wrong, git reflog is the ultimate safety net. It tracks every movement of the HEAD, allowing for the recovery of "lost" commits that aren't visible in a standard git log. Key Skills Applied: ✅ VCS: Git, GitHub, Bitbucket ✅ Workflow: Git Flow, Trunk-based Development ✅ Scripting: Bash/Shell Automation Mastering these Git internals is essential for building robust CI/CD pipelines and ensuring collaboration doesn't turn into "Merge Hell." #DevOps #Git #VersionControl #SoftwareEngineering #Automation #GitHub #CloudEngineering #TechLearning #Programming

🚨 Most teams pick a Git branching strategy by accident. Then wonder why production breaks every Friday. Here is what actually happens in real teams: • Small startup using GitFlow — 3 weeks to ship a button change • Enterprise using GitHub Flow — no release control, staging = prod • Junior team doing Trunk-Based — incomplete code ships to users • Open source project with no fork policy — anyone can push to main • Library team with no release branches — v1 customers get v3 bugs Wrong strategy = broken releases ❌ Right strategy = predictable deployments ✅ Every DevOps pipeline depends on how your team branches. Every production incident has a branching story behind it. I built a complete Git Branching Strategies guide covering all 6: 🌿 GitFlow → main + develop + feature + release + hotfix branches → Best for: Banking, games, enterprise, scheduled releases → Complexity: High · CI/CD: Moderate 🚀 Trunk-Based Development → Everyone commits to main daily — feature flags hide incomplete work → Best for: Google, Netflix, microservices, 100+ deploys/day → Complexity: Low · CI/CD: Excellent 🐙 GitHub Flow → Branch → PR → merge to main → deploy immediately → Best for: Startups, web apps, small teams moving fast → Complexity: Very Low · CI/CD: Excellent 🦊 GitLab Flow → Code flows downstream: main → staging → production → Best for: Healthcare, finance, regulated multi-env teams → Complexity: Medium · CI/CD: Very Good 📦 Release Branch Strategy → Parallel branches for v1.x, v2.x, v3.x maintained simultaneously → Best for: Libraries, SDKs, Node.js, React, Ubuntu-style projects → Complexity: Very High · CI/CD: Complex 🍴 Forking Workflow → External contributors work on forks — nothing merges without review → Best for: Open source, Linux, React, Django, VS Code → Complexity: Medium · CI/CD: Good 💡 The Golden Rule: No strategy is universally best. The right choice depends on your release cadence, team size, and product type. Choose wrong → merge hell, broken releases, Friday incidents. Choose right → clean history, fast deploys, zero surprises. Practical DevOps. Real-world execution. 📞 +91 9966107782 | +91 8008258425 💬 Comment "BRANCH" if you find this useful ♻️ Repost to help someone on your team stop breaking production. #Git #GitHub #DevOps #DevSecOps #CICD #GitFlow #TrunkBased #VersionControl #AWS #Docker #Kubernetes #Terraform #CloudComputing #ShellScripting #CareerGrowth #SDLCTechAcademy