Git Workflow: Init, Status, Add, Commit, Push, Pull, Branch, Merge, Cherry-Pick, Pull Requests

💻 - Git Week 2 Day 7 – Advanced Git Tools & Final Wrap-Up As I wrap up my second week of the DevOps journey, I explored some of the advanced Git commands and tools that make version control more powerful, flexible, and reliable in real-world environments. These are the commands that help developers clean up history, undo mistakes, and manage changes efficiently — especially in team-based projects. ⸻ 🧠 1️⃣ Rebasing vs Merging • git rebase rewrites commit history to make it linear and clean. • It’s best used for your local feature branches, while merging is safer for shared branches. Example: git rebase master This moves your branch commits on top of the latest commits from master. 💾 2️⃣ Stashing Sometimes you’re in the middle of work and need to switch branches — but don’t want to commit unfinished changes. git stash Temporarily stores your modifications so you can come back to them later. Restore them with: git stash pop 🏷️ 3️⃣ Tags & Releases Tags mark specific commits as version points (like v1.0 or v2.0): git tag v1.0 git push origin v1.0 They’re great for releases or snapshots of stable versions in production. ⸻ 🍒 4️⃣ Cherry-Picking If you need one specific commit from another branch without merging the entire branch: git cherry-pick [commit-id] This copies just that commit into your current branch. ⏪ 5️⃣ Undoing & Reverting Changes • git revert [commit-id] safely undoes a commit by creating a new one that reverses its effects. • git reset --hard [commit-id] rolls back your repository to a previous commit, use carefully as it changes history. 🔒 6️⃣ SSH Authentication Instead of entering your username and password each time you push or pull, you can connect to GitHub securely using SSH keys: ssh-keygen -t rsa -b 4096 -C "your@email.com" Add the public key to GitHub → Settings → SSH and GPG Keys. This makes Git operations faster and more secure — especially when automating with scripts or CI/CD pipelines. 🧩 Final Thoughts on Git & GitHub Over these seven days, I’ve learned how to: ✅ Initialise and configure Git ✅ Manage commits and branches ✅ Handle merges and conflicts ✅ Sync repositories with GitHub ✅ Explore advanced tools for clean version control Git has become a tool I can now use confidently to track, collaborate, and maintain cleaner project histories, a key foundation for every DevOps engineer. ⸻ Next Up: I’ll be diving into Bash scripting such as learning how to automate Linux commands, handle input/output, and build scripts to support real DevOps workflows. #Git #GitHub #DevOpsJourney #VersionControl #LearningInPublic #Bash #CloudComputing

✅ *Git & GitHub Interview Questions & Answers* 🧑💻🌐 *1️⃣ What is Git?* *A:* Git is a distributed version control system to track changes in source code during development. *2️⃣ What is GitHub?* *A:* GitHub is a cloud-based platform that hosts Git repositories and supports collaboration, issue tracking, and CI/CD. *3️⃣ Git vs GitHub* - *Git:* Version control tool (local) - *GitHub:* Hosting service for Git repositories (cloud-based) *4️⃣ What is a Repository (Repo)?* *A:* A storage space where your project’s files and history are saved. *5️⃣ Common Git Commands:* - `git init` → Initialize a repo - `git clone` → Copy a repo - `git add` → Stage changes - `git commit` → Save changes - `git push` → Upload to remote - `git pull` → Fetch and merge from remote - `git status` → Check current state - `git log` → View commit history *6️⃣ What is a Commit?* *A:* A snapshot of your changes. Each commit has a unique ID (hash) and message. *7️⃣ What is a Branch?* *A:* A separate line of development. The default branch is usually `main` or `master`. *8️⃣ What is Merging?* *A:* Combining changes from one branch into another. *9️⃣ What is a Pull Request (PR)?* *A:* A GitHub feature to propose changes, request reviews, and merge code into the main branch. *🔟 What is Forking?* *A:* Creating a personal copy of someone else’s repo to make changes independently. *1️⃣1️⃣ What is .gitignore?* *A:* A file that tells Git which files/folders to ignore (e.g., logs, temp files, env variables). *1️⃣2️⃣ What is Staging Area?* *A:* A space where changes are held before committing. *1️⃣3️⃣ Difference between Merge and Rebase* - *Merge:* Keeps all history, creates a merge commit - *Rebase:* Rewrites history, makes it linear *1️⃣4️⃣ What is Git Workflow?* *A:* A set of rules like Git Flow, GitHub Flow, etc., for how teams manage branches and releases. *1️⃣5️⃣ How to Resolve Merge Conflicts?* *A:* Manually edit the conflicted files, mark resolved, then commit the changes.

🧹 Day 13 – “Git Cleanup Crew – Keeping Your Repo Clean & Deployment-Ready 🧼💻” A messy Git repo is like a messy kitchen… you can cook, but you’ll suffer while doing it. 😂 Today’s toolkit is all about cleaning, ignoring, tagging, and maintaining your codebase — just like a true DevOps engineer. 🚮 .gitignore – The Gatekeeper This file decides what should never enter Git. Logs, temp files, build artifacts — keep all that junk out. Add it once. Your repo stays clean forever. Use case: Exclude unwanted files/folders from Git tracking. 💡 DevOps tip: Use https://gitignore.io to generate perfect templates. 🧽 git clean -fd – The Deep Cleaner Deletes all untracked files and directories in seconds. “Are these files important?” Git: Nope. DELETE. 😂 Use case: Remove leftover files after merges, builds, or experiments. ⚠️ Be careful: This permanently deletes files — no recycle bin! 🏷️ git tag -a v1.0 -m "Release 1.0" – The Bookmark Tags important points in history like releases, milestones, rollbacks. “This is the version we deployed to production!” Use case: Mark stable releases and deployments. 💡 Pro tip: git push --tags to push all your tags to remote. 🔧 git fsck – The Repo Doctor Scans your repository and reveals issues like missing objects or corrupt data. It’s like a health checkup for Git itself. Use case: Validate repo integrity; essential in large, long-running projects. 💡 Pro tip: Run this in old monolithic repos — you’ll be shocked. 🗑️ git gc – The Garbage Collector Reclaims space, removes unused objects, and optimizes the repo. Think of this as clearing cache + vacuuming + healing broken commits. 😅 Use case: Make your repo smaller, cleaner, faster. 💡 Pro tip: git gc --aggressive for deeper optimization (use less often). 💬 Moral of the Story A clean repo = faster deployments + fewer surprises + happier DevOps engineers. 😎 Your Cleanup Crew: .gitignore → Stop junk at the door git clean → Remove untracked mess git tag → Mark milestones git fsck → Check repo health git gc → Optimize everything Treat your Git repo like production — keep it clean. 💯 ❓ Your Turn What’s the worst kind of file you’ve accidentally pushed before the .gitignore era? 😅 .env? node_modules? 400 MB zip file? Confess below 👇

💻 - Git Week 2 Day 1 – Understanding Git & GitHub Today marks the start of Week 2, where I begin my journey into Git and Version Control — the backbone of modern DevOps collaboration. 🧠 Git vs GitHub • Git is a version control system — a tool that tracks changes to your code locally on your computer. • GitHub is a cloud-based hosting platform for Git repositories — where developers store, share, and collaborate on projects online. In short, Git is the tool, GitHub is the platform. ⸻ 🧩 Starting a Repository • git init — creates a new Git repository (a new timeline for your project). • git status — shows what’s happening right now in that timeline. When I first ran git status, I saw: On branch master No commits yet Nothing to commit Here’s what that means: • Branch master = your main timeline. • No commits yet = you haven’t created a save point yet. • Nothing to commit = there are no changes for Git to record. ⸻ 📂 Tracking Changes When you add a new file, Git notices it but marks it as untracked — it knows the file exists but isn’t monitoring it yet. To track it: • git add file — adds that specific file. • git add . — tracks all files in the current directory. Once files are staged, you can commit them (make a save point): • git commit -m "Initial commit" — commits the staged files and adds a short description of the change. To view your history of commits: • git log — shows all your save points (commits) in order. ⸻ ⚙️ Git Configuration & Identity Setup Git has three levels of configuration (or “dimensions” as I like to think of them): 1. System level – applies to every user on the system. 2. Global level – applies to all repositories for your user account. 3. Local level – applies only to the specific repository. View your settings: • git config --list Set your identity: git config --global user.name "Your Name" git config --global user.email "your@email.com" Other useful configurations: • git config --global color.ui auto → adds colour to command output. • git config --global core.editor [editor] → sets your preferred text editor. • git config --global core.autocrlf input → helps sync files correctly across systems. ⚡ Shortcuts & Aliases Create shorter custom commands for faster use: For example, git config --global alias.st status. Now git st. 🧭 The difference between: • git config --global user.name → global (applies everywhere). • git config user.name → local (applies only in the current repo). Today’s session was all about setting up Git, understanding how it works, and creating your first commits — essentially learning how to control time in your codebase. Next Up: I’ll be exploring how to: • Ignore files using .gitignore (like logs or environment files). • View changes using git diff. • Unstage files with git restore –staged. If you’re following my DevOps journey, connect and keep learning with me 🚀 #Git #DevOpsJourney #VersionControl #CloudComputing #LearningInPublic

# DevOps: Day 14 - Git Interview Questions and Answers * Q: How to create or initialize a git repository A: git init * Git helps tracks changes, and helps with versioning. * Use git diff to see the changes that is being made to a file. * Use git status to check for status of your file. * Whenever git is initialized locally, for us to be able to link it to github so that we can always push to github, we have to add a remote reference. * git remote -v: used to check for remote reference to a an existing git file. * git remote add "<repository name>". * git clone <repository url>: used to clone a git repository. * git clone is used to download repository while fork is used to create a copy of a repository. * using git branching, one can separate the development activities. * git checkout -b "name-of-branch": to create and switch to a branch. * git checkout "name-of-branch": to switch to a branch. * To move code from other branch to the main branch we can: - git merge - git rebase - git cherry-pick (easiest). * To get the log of a branch, we don't have to switch to that branch. We can simply just do: git log <name-of-branch>. * on the main branch or whatsoever branch you want to bring it changes to the main branch, just do: git cherry-pick <hash of the commit you are bringing in> * Cherry-pick is easy when there are just like one, two or three commits. * In a situation where there are multiple commits, it's best one makes use of git merge or git rebase. * If you don't want to see lengthy logs, once can use: `git log --oneline`. * To merge from one branch to another. Let's say I am on main branch, and I want to merge feature branch to main branch, I will just do: `git merge feature` * To use rebase, just: git rebase feature. That is assuming one is on main branch and wants to bring the changes in the feature branch into the main branch. * merge and rebase practically does the same thing. The only difference is that merge makes all your changes created at the top, that is your changes are created after all your existing changes. That is the changes are not in a linear way. Where as for the rebase will still maintain that linear order. That is which commit comes before which commits, hence it is always advisable to make use of rebase in order to get a linear commit history. #devops #git #github #rebase #merge #cherry-pick

New workflows for #SCM, or how to simplify DevX for tiny teams, and projects where the ratio of gitninja < gitphobic is skewed heavily towards people who really will never ever learn git. Call it skills deficiency, call it getting away with thumb drives and using web interfaces to upload files into github, it is akin to not learning to read as a developer. Not making a value judgement, but I have discovered a lot of devs over the years who have figured out how to not ever learn git, and secretly (or openly) refuse avoid using source control. There are a number of techniques I've seen to avoid using a git workflow: - use a thumb drive and hand the code to a coworker who will do the merge - start a merge or commit or push (usually some combo of this ... the commands were written down but never really understood so this gets dangerous fast) and call me (or someone) over to help when stuck - don't push code. Tell the boss bleep you. Excuse yourself for the day as you aren't in a good mood. I've seen this. - use unprotected main, and push using destructive techniques (seen this) - email the code to people (dangerous as you don't always get the right person in "outlook") - maintain a huge gigantic history at the header of the code, usually all in one file (never mind, git and any SCM will graciously maintain history) - uses a cheatsheet or notebook of commands, or an LLM to figure out what to do (see my last post) - never branch The list goes on. What is the answer to this? I agree the number of things you need to know as a person who works with an engineering team just to use git effectively is large, and vast. Brilliant people struggle with hit. So I will write this down: - In some cases you don't need git. But you need history. You need security of not losing work. Let this person use the SCM (Subversion/CVS) they remember. A good RE/DevOps person can mirror the repo to git. - Use a gatekeeper: In most companies now, there is a gatekeeper now. You can't simply push code. So quit torturing this person, but set up rules for how often and how code gets delivered - Or: I'm going to try out new SCMs that have the good features of git (namely distributed, low cost branching/forking) and leave out the features that most people don't need. The goal is not to create an elite force of people who all have the same skills. You need the designer. You need the EE. You need that i18n specialist. You need that marketing person (nah ... just kidding). So one goal for this coming year is to get familiar with other SCMs so I can quickly train up team members who are gitphobics and in situations where we can get by with a more simplified model of dev, something like Fossil SCM will work just great. You add files. You commit, and and wait, it already sync'd? No extra stuff. Nope. (credit: AI slop by Bing Image Creator using a prompt from human brain to make the perfect image DALL-3 or something. Writing by human intelligence slop).

🧠 Protecting Your Main/Master Branch — The Unsung Hero of a Healthy Git Workflow 🚀 Imagine pushing untested code directly to production. Or worse — accidentally deleting your main branch. 😱 That’s why branch protection is one of the most crucial (but often ignored) DevOps practices for maintaining code quality and team safety. 🔍 What Is Branch Protection? Branch protection is a set of rules and restrictions applied to critical branches like main or master in Git repositories (GitHub, GitLab, Bitbucket, etc.). 🏗️ Why It’s Important Without protection, anyone can: Force push changes and overwrite others’ commits Merge without reviews or testing Delete the main branch accidentally These lead to: ❌ Broken builds ❌ Lost commits ❌ Security risks ❌ Time wasted on rollback or debugging ⚙️ How to Protect Your Main/Master Branch (GitHub Example) You can enable this in GitHub → Settings → Branches → Add Rule ✅ Recommended settings: Require pull request reviews before merging Require status checks to pass (build/test must succeed) Require linear history (no messy merges) Disallow force pushes Disallow deletions Optional (but smart): Enforce signed commits Restrict who can push directly Require approvals from code owners 🧩 Example: Production-Safe Git Workflow main # Protected – production-ready code develop # Active dev branch for features feature/* # Feature-specific branches hotfix/* # Urgent bug fixes Flow: 1️⃣ Developer creates a feature branch 2️⃣ Pushes code and raises a PR 3️⃣ Code review + CI pipeline runs 4️⃣ Merge only after approval and tests pass 5️⃣ Main stays clean, tested, and deployable 🧠 Best Practices ✅ Protect main and develop branches ✅ Always merge via Pull Requests (never direct commits) ✅ Require at least one reviewer approval ✅ Run automated tests (CI) before merging ✅ Use branch naming conventions (feature/login, fix/api-timeout) ✅ Review branch protection rules regularly 💡 Pro Tips 💥 Add “CODEOWNERS” file for automatic reviewer assignment 💥 Combine protection rules with GitHub Actions or Jenkins pipelines 💥 Automate security scans before merging 💥 Use status checks to block PRs with failing tests 💥 Communicate branch policies clearly in README 🧠 Real-World Tip In production environments, large teams (like Netflix, Microsoft, or Amazon) treat main as “sacred code.” Every single change goes through: Peer review Automated build validation Security scan That’s how they prevent downtime or data breaches from small mistakes. “Protecting your main branch isn’t about blocking developers — it’s about protecting production and empowering quality delivery.” 🔐 🧠 Read more: https://lnkd.in/gSgb_jga #Git #GitHub #DevOps #CI/CD #BestPractices #SoftwareDevelopment #CodeReview #GitTips #EngineeringExcellence

Is Your Git Strategy Slowing Down Deployment? If your team is buried in develop, QA, integration, and multiple feature branches, you need to read this article. https://lnkd.in/e2XisEPh The complexity of traditional branching strategies is often the "pebble in the shoe" that slows development, confuses deployments, and hides technical debt. A radical simplification: 1️⃣ Mono-repo: Consolidating source code removes cross-repository dependencies, enables consistent static analysis, and simplifies project referencing and unified debugging. No more checking if Repository A's binary shipped before Repository B's launch! 2️⃣ Trunk-Based Development (TBD): Eliminating long-lived feature branches and working directly on Trunk (main) ensures a stable environment and enables continuous, automated deployment. TBD forces developers to use feature flags for large changes, dramatically reducing the risk of broken builds and speeding up feedback loops. Result: Teams that shifted to this model saw their deployment frequency jump from monthly to weekly, and daily fix throughput significantly increased. Good engineering automates the things that make life difficult. Wait! Is this suitable for everyone? The Google/Meta mono-repo Model - How They Scale? Not because the mono-repo is inherently superior, but because they have custom-built systems that eliminate the downsides you would face with standard, open-source tools like Git and BitBucket Pipelines. 1. Specialized Version Control and File Systems Problem: Git performance degrades rapidly with the massive size (billions of lines of code) of a monorepo, making simple operations like cloning or checking status painfully slow. Solution: They do not use standard Git alone. Google uses a custom-built version control system and a Virtual File System (or Microsoft's GVFS) that allows engineers to only "see" and clone the parts of the repo they need to work on. 2. Intelligent Build and Test Tools Problem: Running all tests for all projects (Backend, Frontend, etc.) on every commit would make CI take hours or days, completely halting development. Solution: They use highly advanced build tools like Google's Bazel. These tools create a precise dependency graph and use intelligent caching to achieve selective building and testing. 3. Centralized Tooling and Standardization Problem: Managing inconsistent dependency versions and build scripts across thousands of teams is a massive overhead. Solution: The mono-repo enforces standardization. Every Python service, for example, is guaranteed to use the same linter, formatter, and often the same version of core internal libraries. Why may this NOT apply to you? Google invested in making the mono-repo work for their scale (10,000+ developers), whereas for you, the poly-repo approach with Docker gives you 90% of the scaling benefits with 1% of the infrastructure cost. #Monorepo #SoftwareEngineering #DevOps #TrunkBasedDevelopment #Git #ContinuousDelivery

✅ *Git & GitHub Interview Questions & Answers* 🧑💻🌐  *1️⃣ What is Git?*  *A:* Git is a distributed version control system to track changes in source code during development.*2️⃣ What is GitHub?*  *A:* GitHub is a cloud-based platform that hosts Git repositories and supports collaboration, issue tracking, and CI/CD.*3️⃣ Git vs GitHub*  - *Git:* Version control tool (local)  - *GitHub:* Hosting service for Git repositories (cloud-based)  *4️⃣ What is a Repository (Repo)?*  *A:* A storage space where your project’s files and history are saved.*5️⃣ Common Git Commands:*  - `git init` → Initialize a repo  - `git clone` → Copy a repo  - `git add` → Stage changes  - `git commit` → Save changes  - `git push` → Upload to remote  - `git pull` → Fetch and merge from remote  - `git status` → Check current state  - `git log` → View commit history  *6️⃣ What is a Commit?*  *A:* A snapshot of your changes. Each commit has a unique ID (hash) and message.*7️⃣ What is a Branch?*  *A:* A separate line of development. The default branch is usually `main` or `master`.*8️⃣ What is Merging?*  *A:* Combining changes from one branch into another.*9️⃣ What is a Pull Request (PR)?**A:* A GitHub feature to propose changes, request reviews, and merge code into the main branch.*🔟 What is Forking?*  *A:* Creating a personal copy of someone else’s repo to make changes independently.*1️⃣1️⃣ What is .gitignore?*  *A:* A file that tells Git which files/folders to ignore (e.g., logs, temp files, env variables).*1️⃣2️⃣ What is Staging Area?*  *A:* A space where changes are held before committing.*1️⃣3️⃣ Difference between Merge and Rebase*  - *Merge:* Keeps all history, creates a merge commit  - *Rebase:* Rewrites history, makes it linear  *1️⃣4️⃣ What is Git Workflow?*  *A:* A set of rules like Git Flow, GitHub Flow, etc., for how teams manage branches and releases.*1️⃣5️⃣ How to Resolve Merge Conflicts?*  *A:* Manually edit the conflicted files, mark resolved, then commit the changes. #ssekabirarobertsims💬 *like if you found this useful!*

“Everything as Code” Still Needs a Brain - Not Just a Git Repo —𝘮𝘺 𝘱𝘦𝘳𝘴𝘰𝘯𝘢𝘭 𝘷𝘪𝘦𝘸; 𝘰𝘱𝘪𝘯𝘪𝘰𝘯𝘴 𝘢𝘳𝘦 𝘮𝘺 𝘰𝘸𝘯. This week I read a post from my colleague Markus Rettstatt that lit up the comments. He was defending an “everything as code” mindset: • requirements as code • architecture as code • infrastructure as code • tests as code All living in a Git repository, versioned, reviewed, automated. And I agree with the core idea. But many people read it as: “So we don’t need requirements anymore.” “We don’t need architecture.” “We can throw away all the tools from the last 20 years.” That’s not what he said. And it’s not how I read it. In engineering, we still need the trio: • Requirements → the WHY • Architecture → the HOW • Source code → the WHAT “Everything as code” is not “forget the why and the how.” It’s “let the why, how, and what live closer together.” You can write a requirement in DOORS, in Polarion, in a Word file, in a Markdown file inside Git. You can draw an architecture in a modeling tool or describe it in a structured, versioned document next to the code. The form can change. The responsibility cannot. Another point that worried me in the comments: some people implied that “everything as code” would not fit standards like: • ASPICE • ISO 26262 • DO-178 From my experience (automotive, aerospace, energy, consumer electronics): these standards don’t care if your requirement is in a fancy enterprise tool or in a text file in Git. They care about: • traceability (requirement → architecture → code → test) • consistency • evidence that you followed a controlled process “Everything as code” can support all of that— sometimes even better, because you enable: • code review on requirements and architecture • automation for checks and traceability • shorter feedback loops You may have more work or less work depending on the tools you choose. If a tool becomes a bottleneck to speed, learning, or collaboration… then yes, it’s a good candidate to be replaced. But replacing a tool is very different from abandoning engineering discipline. So my view is simple: I’m for “everything as code” → when it helps us keep the WHY, the HOW and the WHAT aligned → and still respects the processes and evidence that ASPICE, ISO 26262, DO-178, etc. expect. Tools are negotiable. Good engineering is not. I’m curious: how far have you gone with “everything as code” in your teams—without losing traceability and rigor? #SoftwareEngineering #AutomotiveSoftware #EverythingAsCode #SoftwareArchitecture #ModernEngineeringPractices