In the last 2 days, I gained a deeper understanding of how multiple developers collaborate on a single project using Git & GitHub in a professional environment. Here’s a detailed breakdown of the complete workflow used in organizations: 🔹 1. Repository Creation & Access Control The project repository is created on GitHub by the organization. Team members are given access (read/write) based on their roles. 🔹 2. Clone the Repository (Local Setup) Each developer copies the remote repository to their local machine: git clone <repository-url> ➡️ This creates a local working copy of the project. 🔹 3. Branching Strategy (Very Important) Developers do NOT work directly on the main/master branch. Instead, they create their own feature branch: git checkout -b feature/developer1-task ➡️ This ensures isolated development without affecting the main codebase. 🔹 4. Development Phase Developers write code, fix bugs, or add features in their branch. Useful commands: git branch → Check current branch git status → Check modified files 🔹 5. Staging Changes After completing work, changes are added to the staging area: git add . ➡️ Prepares files for commit. 🔹 6. Commit Changes (Version Tracking) Developers save their work with a meaningful message: git commit -m "Added login feature with validation" ➡️ Each commit acts as a checkpoint in the project history. 🔹 7. Connect to Remote Repository (if not already) git remote add origin <repository-url> git remote -v ➡️ Links local repo with GitHub. 🔹 8. Push Code to Remote Branch Developers push their branch to GitHub: git push origin feature/developer1-task ➡️ Now code is available online for review. 🔹 9. Pull Request (PR) Process 🔥 (Most Important in Organizations) Instead of directly merging, developers create a Pull Request on GitHub. ➡️ PR allows: Code Review by team members Discussion & feedback CI/CD checks (build/test) 🔹 10. Code Review & Approval Senior developers or team leads review the code. They may: Suggest changes Approve the PR 🔹 11. Merge to Main Branch Once approved, the branch is merged into main/master. ➡️ Ensures only tested and reviewed code goes to production. 🔹 12. Sync Local Repository After merge, developers update their local repo: git checkout master git pull origin master ➡️ Keeps local code up-to-date. 🔹 13. Clean Up Branches Delete unused branches: git branch -d feature/developer1-task ➡️ Maintains a clean repository. 💡 Key Learnings: ✔ Branching prevents conflicts ✔ Pull Requests improve code quality ✔ Collaboration becomes structured and efficient ✔ Version control ensures complete history tracking #Git #GitHub #DevOps #SoftwareDevelopment #LearningJourney #VersionControl #OpenSource #devopsjourney #fresher
Git and GitHub Collaboration Workflow for Developers
More Relevant Posts
-
🚀 Git Workflow Explained Clearly – 4 Stages Sharing practical knowledge on Git Workflow in a simple way. Many people use commands like git add, git commit, and git push, but knowing what happens behind the scenes makes Git easier to learn and use confidently. 💡 Git mainly works in 4 stages, and each stage has file states every developer should know. 🔹 1️⃣ Working Directory / Working Tree Your project folder where files are created, edited, renamed, or deleted. 👉 Common file states: ✅ Untracked Files – New files created by you, but Git has not started tracking them yet. ✅ Tracked Files – Files already known to Git from previous commits. ✅ Modified Files – Tracked files that were changed after the last commit. ✅ Deleted Files – Tracked files removed from the folder. 📌 Command: git status 📌 Note: Changes exist only in your system. Nothing saved in Git history yet. 🔹 2️⃣ Staging Area / Index Place where selected changes are prepared for the next commit. Review area before saving permanently. 👉 Common terms: ✅ Staged Changes – Files added using git add and ready for commit. ✅ Partially Staged Changes – Only selected changes from a file are staged. 📌 Commands: git add filename → Add one file git add . → Add all files git restore --staged filename → Remove from staging 📌 Note: Only staged changes go into next commit. 🔹 3️⃣ Local Repository Git’s local database where commits are stored. 👉 Important terms: ✅ Commit – A saved version of your project changes. ✅ HEAD – Points to the latest commit in your current branch. ✅ Branch – A separate line of development such as main, dev, or feature. ✅ Commit History – Record of all previous commits. 📌 Commands: git commit -m "Added login page" git log 📌 Note: Changes are saved locally, not shared online yet. 🔹 4️⃣ Remote Repository Online repository like GitHub, GitLab, or Bitbucket. Used for backup and collaboration. 👉 Common terms: ✅ origin – Default remote repository name. ✅ Push – Upload local commits to remote repository. ✅ Pull – Download latest changes from remote repository. ✅ Fetch – Check updates from remote without merging. ✅ Clone – Copy remote repository to your local system. 📌 Commands: git push origin main git pull origin main git clone <repo-url> 📌 Note: This is where teams collaborate securely. 💼 Real-Time Example A developer creates a new file called login.html 1️⃣ File starts as Untracked 2️⃣ git add login.html → becomes Staged 3️⃣ git commit -m "Added login page" → saved locally 4️⃣ git push origin main → uploaded to remote repository This is the same workflow used in real projects every day. #Git #GitHub #DevOps #VersionControl #LearningGit #Developers #Automation #CareerGrowth #TechCommunity
To view or add a comment, sign in
-
-
Last week we faced a small issue in our project, but it clearly showed the real importance of Git. We were working on a Maven project. One change was pushed directly to the main branch without proper testing. After deployment, the application started failing. Later we found that a small configuration change caused the issue. What actually went wrong? - No proper branching strategy - Direct push to main branch - No proper code review Use Case of Git If we had followed a proper flow: - Create a feature branch - Test the changes - Then merge into main This issue could have been avoided. What is Git? Git is a Version Control System (VCS) It helps to: - Track changes in code - Maintain history - Roll back when something breaks Types of Version Control - Centralized (CVCS) → Single server dependency - Distributed (DVCS - Git) → Everyone has full copy of repo Git Repository A repository is where your project lives. Types: - Local Repository (your system) - Remote Repository (GitHub) Git Lifecycle (Simple Flow) Working Directory → Staging Area → Repository File states: - Untracked → Not tracked by Git - Staged → Ready to commit - Committed → Saved in repo Unstage example: git restore --staged file Basic Git Commands git init git clone <url> git status git add . git commit -m "message" git log git fetch vs git pull - git fetch → Downloads changes, does not merge - git pull → Fetch + Merge Best practice: Use fetch first, then review changes Branching Strategy (Very Important) Never work directly on main branch. git checkout -b feature-login Common flow: - main (production) - develop - feature branches Merge vs Rebase - Merge → Keeps history, safer - Rebase → Cleaner, linear history git merge feature git rebase main Git Branches & Merging - Create branches for features - Merge after testing - Avoid conflicts by regular updates. Useful Commands (Real Work) git fetch git pull git rebase git cherry-pick <commit> git stash Git Clone Used to copy remote repository to local system: git clone <repo-url> Git Environment Setup - Install Git - Use Git Bash - Configure: git config --global user.name "Your Name" git config --global user.email "your@email.com" Working with GitHub - Create repository on GitHub - Connect local repo - Push code Maven Project to GitHub (Step-by-Step) git init git add . git commit -m "Initial commit" git branch -M main git remote add origin <repo-url> git push -u origin main Final Learning That day, one small mistake caused a big issue. If we had: - Used proper branching - Avoided direct push - Followed review process We could have avoided the failure. Git is not just commands, it is a discipline and process. What do you prefer in your projects? Merge or Rebase? #Git #DevOps #VersionControl #GitHub #Maven #Learning #devsecops #terraform
To view or add a comment, sign in
-
-
*** Day 6 *** 📌 how Git works between multiple developers using push and pull. When multiple developers work on the same project, they use a shared remote repository (like GitHub) to sync their work. Each developer: ▪️ Works locally on their own system ▪️ Uses pull to get latest changes ▪️ Uses push to send their changes Step-by-Step Workflow 1. Clone the Repository (First Time Only) Each developer copies the project: git clone <repo-url> This creates a local copy of the remote repo. 2. Pull (Get Latest Changes) Before starting work, always update your code: git pull origin main What happens: ▪️ Downloads latest changes from remote ▪️ Merges them into your local branch 3. Make Changes Locally ▪️ Edit files ▪️ Add new features or fix bugs 4. Stage & Commit Changes git add . git commit -m "Added new feature" Now changes are saved locally, not yet shared. 5. Push (Send Changes to Remote) git push origin branchname What happens: ▪️ Uploads your commits to remote repository ▪️ Other developers can now access your work Full Flow Between Developers Developer 1: git pull Make changes git commit git push Developer 2: git pull (gets dev 1 changes) Make new changes git commit git push Summary: ▪️ Developers work independently ▪️ Use push to send code ▪️ Use pull to get latest updates ▪️ Central repo keeps everything in sync 📌 Making Changes Only Through GitHub (Web UI) 1. Open Repository in GitHub ▪️ Go to your project repository in GitHub ▪️ You will see all files 2. Edit File Online ▪️ Click on any file ▪️ Click ✏️ Edit (pencil icon) ▪️ Make changes directly in browser 3. Commit Changes Scroll down → you’ll see commit options: ◾ Add commit message (example: "Updated README") ◾ Choose: ▪️ ✅ Commit directly to main ▪️ OR ✅ Create a new branch Then click Commit changes 4. (Recommended) Create Pull Request (PR) If you created a branch: ◾ Click Compare & pull request ◾ Add description ◾ Click Create PR ◾ Review → Click Merge How Multiple Developers Work (GitHub Only) Developer 1: ▪️ Edits file on GitHub ▪️ Commits / creates PR ▪️ Merges changes Developer 2: ▪️ Opens same repo ▪️ Sees updated code instantly ▪️ Makes new changes No need for git pull manually — GitHub always shows the latest version. Important Limitations ❌ Not ideal for: Large projects Frequent changes Complex conflict resolution ✅ Best for: Small edits Documentation Quick fixes Final Tip: Even if you use the GitHub UI, learning Git commands gives you: ▪️ Better control ▪️ Faster workflow ▪️ Industry-standard practice Frontlines EduTech (FLM) #flm #github
To view or add a comment, sign in
-
🚀 Top 20 Git Commands Every Developer Must Know In Tech, Change = Deploy In today’s IT world, development doesn’t end with writing code. I used to struggle with Git… Random errors, messy commits, and confusion everywhere 😅 👉 If you change something today… 👉 You must deploy it today. That’s the reality of modern software development. 💡 Why Deployment is Critical? ✔️ Users expect real-time updates ✔️ Bugs need instant fixes ✔️ Features must reach users quickly ✔️ Businesses move at high speed ⚙️ Modern Development Mindset Gone are the days of: ❌ Build → Wait → Deploy later Now it’s: ✅ Build → Test → Deploy → Repeat That’s why Git and GitHub is helps in Deployment part : But once you understood these 20 essential commands, everything changed. If you’re a developer, this is your Git cheat sheet 👇 🧠 Git Basics (Start here) 🔹 git init – Initialize a new repository 🔹 git config – Set username & email 🔹 git clone – Copy a remote repo 🔹 git remote – Manage remote connections ⚙️ Daily Workflow Commands 🔹 git status – Check current changes 🔹 git add – Stage changes 🔹 git commit – Save changes locally 🔹 git push – Upload to remote repo 🔄 Syncing with Remote 🔹 git pull – Fetch + merge changes 🔹 git fetch – Download without merging 🌿 Branching & Collaboration 🔹 git branch – Create/view branches 🔹 git checkout – Switch branches 🔀 Advanced Operations 🔹 git merge – Combine branches 🔹 git rebase – Cleaner commit history 🔹 git log – View commit history 🔹 git diff – Compare changes 🧰 Undo & Recovery Tools 🔹 git stash – Save changes temporarily 🔹 git reset – Undo commits 🔹 git revert – Safe undo with new commit 🔹 git cherry-pick – Apply specific commits 🔥 Why Git is Important? ✔️ Tracks every change in your code ✔️ Makes collaboration easy in teams ✔️ Helps you recover from mistakes ✔️ Industry standard for version control 🛠️ How to Master Git? ✅ Practice daily with real projects ✅ Break things → then fix using Git 😄 ✅ Learn branching & merging deeply ✅ Contribute to open source 🔥 What This Means for Developers 👉 Learn CI/CD pipelines 👉 Understand Git workflows 👉 Write deployable & clean code 👉 Think beyond coding → think production 🎯 Big Lesson: Code is not done when it runs on your machine… It’s done when it runs in production 🚀 🎯 Pro Tip: 👉 Don’t memorize commands 👉 Understand when & why to use them 💡 “Git is not just a tool, it’s a superpower for developers.” 💬 Are you focusing only on coding, or also on deployment #Git #GitHub #VersionControl #Developers #SoftwareEngineering #Coding #TechSkills #OpenSource #LearningInPublic
To view or add a comment, sign in
-
-
Git & GitHub Complete Cheat Sheet 🧠 From git init to Pull Requests — A Handwritten Visual Guide This isn’t just another command list. It’s a handwritten, visual cheat sheet that makes Git & GitHub easy to understand, remember, and apply 🧠✍️ Whether you’re a beginner or a team lead, this guide helps you master version control — without the confusion. 🔍 What’s Inside? 🟢 Git Basics (Visual & Simple) ✅ Why version control? – Undo + history for code ✅ Git vs GitHub – Local tool vs cloud platform (with analogy diagrams) ✅ How Git works internally – Snapshots, not differences (explained visually) ✅ Git areas – Working Directory → Staging Area → Local Repo → Remote Repo 🟡 Essential Commands (With Visual Flow) ✅ git init – Start a new repo ✅ git clone – Copy from GitHub ✅ git status – See what’s modified/staged ✅ git add – Stage changes (file or all) ✅ git commit -m – Save a snapshot ✅ git push / git pull – Sync with remote 🔴 Branching & Merging (The Visual Way) ✅ Why branches? – Protect main code, parallel work ✅ git branch – List/create branches ✅ git checkout -b – Create & switch ✅ git merge – Combine branches ✅ Conflicts – Not errors → decision points (with diagrams) 📌 Best Practices & Interview Tips ✅ Commit message mastery – Good vs bad examples ✅ Branch strategy – Feature branches, safe code flow ✅ Pull before push – Sync with team ✅ Interview Q&A – Git workflow, reset vs revert, merge conflicts ⚡ Why This Cheat Sheet Stands Out 🧩 Handwritten style – More memorable than plain text 🎯 Visual diagrams – Git areas, snapshot model, merge flow 📚 One-page quick reference – No fluff, just what you need 🧠 Beginner + interview prep – Concepts + commands + best practices 🔁 Git vs GitHub analogy – Understand the difference forever 🎯 Perfect For: 👨💻 New developers learning version control 🧪 Developers preparing for Git interview questions 🔁 Open-source contributors who need a quick reference 🎓 Students who learn better with visuals 📌 Anyone tired of Googling “git cheat sheet” every week 🔥 Example Topics You’ll Master: Why version control? Git snapshot model vs delta model Working Directory → Staging → Local → Remote git init, git clone, git status git add, git commit, git push, git pull Branching & merging (with diagrams) Merge conflicts = decision points Good vs bad commit messages git reset vs git revert (interview prep) Best practices: branch for features, pull before push 📌 Pro Tips from the Guide: “Clean history = a respectable developer.” “Conflict is not an error — it’s a decision point.” “Git for the machine, GitHub for the cloud.” #Git #GitHub #VersionControl #CheatSheet #DevTools #OpenSource #CodingInterview #GitCommands #Branching #Merging #PullRequest #DevProductivity #LearnGit #InterviewPrep #HandwrittenNotes #TechGuide
To view or add a comment, sign in
-
Git & GitHub Complete Cheat Sheet 🐙 From git init to Pull Requests — A Handwritten Visual Guide This isn’t just another command list. It’s a handwritten, visual cheat sheet that makes Git & GitHub easy to understand, remember, and apply 🧠✍️ Whether you’re a beginner or a team lead, this guide helps you master version control — without the confusion. --- 🔍 What’s Inside? 🟢 Git Basics (Visual & Simple) ✅ Why version control? – Undo + history for code ✅ Git vs GitHub – Local tool vs cloud platform (with analogy diagrams) ✅ How Git works internally – Snapshots, not differences (explained visually) ✅ Git areas – Working Directory → Staging Area → Local Repo → Remote Repo 🟡 Essential Commands (With Visual Flow) ✅ git init – Start a new repo ✅ git clone – Copy from GitHub ✅ git status – See what’s modified/staged ✅ git add – Stage changes (file or all) ✅ git commit -m – Save a snapshot ✅ git push / git pull – Sync with remote 🔴 Branching & Merging (The Visual Way) ✅ Why branches? – Protect main code, parallel work ✅ git branch – List/create branches ✅ git checkout -b – Create & switch ✅ git merge – Combine branches ✅ Conflicts – Not errors → decision points (with diagrams) 📌 Best Practices & Interview Tips ✅ Commit message mastery – Good vs bad examples ✅ Branch strategy – Feature branches, safe code flow ✅ Pull before push – Sync with team ✅ Interview Q&A – Git workflow, reset vs revert, merge conflicts --- ⚡ Why This Cheat Sheet Stands Out · 🧩 Handwritten style – More memorable than plain text · 🎯 Visual diagrams – Git areas, snapshot model, merge flow · 📚 One‑page quick reference – No fluff, just what you need · 🧠 Beginner + interview prep – Concepts + commands + best practices · 🔁 Git vs GitHub analogy – Understand the difference forever --- 🎯 Perfect For: · 👨💻 New developers learning version control · 🧪 Developers preparing for Git interview questions · 🔁 Open‑source contributors who need a quick reference · 🎓 Students who learn better with visuals · 📌 Anyone tired of Googling “git cheat sheet” every week --- 🔥 Example Topics You’ll Master: # Topic 1 Why version control? 2 Git snapshot model vs delta model 3 Working Directory → Staging → Local → Remote 4 git init, git clone, git status 5 git add, git commit, git push, git pull 6 Branching & merging (with diagrams) 7 Merge conflicts = decision points 8 Good vs bad commit messages 9 git reset vs git revert (interview prep) 10 Best practices: branch for features, pull before push --- 📌 Pro Tips from the Guide: “Clean history = a respectable developer.” “Conflict is not an error — it’s a decision point.” “Git for the machine, GitHub for the cloud.” --- #Git #GitHub #VersionControl #CheatSheet #DevTools #OpenSource #CodingInterview #GitCommands #Branching #Merging #PullRequest #DevProductivity #LearnGit #InterviewPrep #CodeWithAswin #HandwrittenNotes #TechGuide
To view or add a comment, sign in
-
To simplify learning, I created a Git Commands Cheat Sheet covering all the essentials: 💡 Key Areas Covered: ✔ Setup & Configuration ✔ Adding & Committing Changes ✔ Branching & Merging ✔ Working with Remote Repositories (GitHub) ✔ Undoing Mistakes (reset, revert) ✔ Stashing Changes ✔ Using Tags for Versioning 🎯 Why this matters: – Helps students quickly understand Git fundamentals – Improves team collaboration in real-world projects – Essential skill for internships and software development roles FULL GIT COMMANDS CHEAT SHEET • 1. Setup Git (First Time Only) git config --global user.name "Your Name" → Set your name git config --global user.email "you@email.com" → Set your email git config --list → Show Git settings 2. Start a Repository git init → Create new Git repo git clone <repo-url> → Download project from GitHub 3. Check Status & Files git status → Check file status git Is-files → List tracked files 4. Add & Commit Changes git add file.txt → Add one file git add. → Add all files git commit -m "message" → Save changes git commit -am "message" → Add + commit tracked files 5. View History git log → Show commit history git log --oneline → Short history git show <commit-id› → Show commit details 6. Compare Changes git diff → Show file changes git diff --staged → Compare staged files 7. Branching git branch → Show branches git branch name → Create branch git checkout name → Switch branch git checkout -b name → Create + switch branch git branch -d name → Delete branch 8. Merge Branches git merge branch-name → Merge branch into current branch git rebase branch-name → Reapply commits on another branch 9. Remote (GitHub) git remote add origin URL → Connect GitHub repo git remote -v → Show remote URL git push origin branch → Upload code git push -u origin main → First push git pull origin branch → Download updates git fetch → Get updates without merging 10. Undo & Fix Mistakes git reset HEAD file → Unstage file git reset --soft HEAD~1 → Undo commit (keep changes) git reset --hard HEAD~1 → Delete commit & changes git revert commit-id → Undo commit safely 11. Temporary Save git stash → Save changes temporarily git stash list → View stash list git stash apply → Restore stash 12. Tags (Versions) git tag v1.0 → Create version tag git tag → List tags git push origin v1.0 → Push tag #Git #GitHub #SoftwareEngineering #ComputerScience #Internship #WebDevelopment #Programming #Developers #TechSkills #Learning
To view or add a comment, sign in
-
-
“Using Git only for backup is wrong.” I heard this recently, and honestly, I don’t fully agree. Git is a tool. How you use it depends on your team, project size, and workflow. While working on a recent Laravel project, our team used Git mainly for: • Tracking changes • Knowing who changed what • Reverting safely if something broke We were not using complex collaboration workflows. Each developer handled specific files/modules and pushed to main after completing their work. Was it perfect? No. Was it wrong? Also no. Let’s break down the common ways Git is used 👇 🔹 1. Basic Version Control (What we used) How it works: • Direct commits to main • Minimal branching • Focus on history and backup Pros: • Very simple • Fast workflow • Easy for small teams • No overhead of managing branches Cons: • Risk of conflicts if not coordinated • No structured code review • Can become messy as team grows 👉 Best for: • Small teams • Clear file/module ownership • Short-term or internal projects 🔹 2. Feature Branch Workflow How it works: • Each feature gets its own branch • Merged into main via pull request Pros: • Clean separation of work • Safer merges • Enables code reviews • Industry standard Cons: • Slightly slower workflow • Requires discipline • Can feel heavy for small tasks 👉 Best for: • Growing teams • Active development • Projects needing stability 🔹 3. Git Flow (Structured Branching) How it works: • Separate branches for features, develop, release, hotfix Pros: • Very organized • Good for release cycles • Clear process Cons: • Complex • Too heavy for many teams • Slows down development 👉 Best for: • Large teams • Products with planned releases 🔹 4. Trunk-Based Development How it works: • Everyone works on main (or short-lived branches) • Frequent small commits Pros: • Fast development • Less merge pain • Encourages small changes Cons: • Needs strong discipline • Requires good testing • Mistakes can impact everyone quickly 👉 Best for: • Experienced teams • CI/CD environments 💡 What people miss Not every project needs the same level of process. In our case: • Small team • Clear responsibility per file/module • No heavy parallel development So a simple Git usage worked fine: • We had history • We had accountability • We had rollback safety 📌 Final thought “Best practices” are important, but blindly applying them without context is also a mistake. The right question is not: ❌ “Is this the correct way to use Git?” But: ✅ “Is this the right workflow for this team and this project?” Curious to know — how does your team use Git? 👇 #Git #Laravel #SoftwareDevelopment #TeamWork #BestPractices
To view or add a comment, sign in
-
-
Git worktree > Git stash (and it’s not even close) Ever had to pause a feature midway… just to fix something urgent? Your brain probably goes: • git stash • checkout main • create branch • fix → commit • come back → stash pop Works… but it’s fragile. You risk: • Merge conflicts during stash pop • Losing untracked changes • Breaking your mental context • Accidentally committing half-baked work I’ve been there more times than I’d like to admit. Then I started using git worktree — and it completely changed how I handle parallel work. What git worktree actually does Git lets you check out the same repository into multiple directories simultaneously. Not branches switching inside one folder. Multiple folders. Multiple working states. Same repo. git worktree add ../hotfix-branch main This creates a new directory: → Clean checkout → Separate working tree → Independent changes Your original feature branch? Untouched. Exactly as you left it. How this changes your workflow Instead of context switching: • Feature A → stays in /project • Urgent fix → /hotfix-branch • Experiment → /experiment-xyz Each task lives in its own isolated workspace No stashing. No juggling. Under the hood (what’s actually happening) Git internally separates: • Working Tree → your files • Index (staging area) • HEAD (current branch reference) git worktree creates: → New working tree → New HEAD pointer → Shared .git object database So: • Commits are shared • History is shared • But working directories are isolated This is why it’s lightweight — no repo duplication. Why it’s insanely useful • Work on multiple features in parallel • Keep long-running branches untouched • Debug production issues without disturbing local state • Run multiple dev servers for different branches And the big one: 👉 Perfect for AI-assisted workflows If you’re using agents/tools: • Worktree 1 → Feature implementation • Worktree 2 → Refactor • Worktree 3 → Bug fix All running in parallel. No branch pollution. No conflicts from half-done work. Cleanup is simple git worktree remove ../hotfix-branch Gone. Clean. The tradeoff (the “secret sauce”) Worktrees shift complexity from Git → filesystem. You now manage: • Multiple folders • Awareness of where you’re working • Disk structure discipline But in return, you get: 👉 Zero context switching overhead The real takeaway Most developers use Git like a linear tool. But Git is actually built for parallelism. git worktree unlocks that. Question If you’re still using git stash as your default escape hatch… Are you solving the problem—or just working around it? #git #softwareengineering #webdevelopment #developerworkflow #productivity
To view or add a comment, sign in
-
-
🚀 Git Commands Every Developer Should Actually Know Whether you’re a student, working professional, or preparing for interviews - these are the Git commands you’ll use in real projects. 🔹 1️⃣ Getting Started (The Basics) 📌 git init – Start a new repository 📌 git clone <repo_url> – Copy a repo locally 📌 git status – See what’s changed 📌 git add <file> – Stage changes 📌 git commit -m "message" – Save your changes 📌 git push – Send commits to remote 📌 git pull – Fetch & merge remote updates 🔹 2️⃣ Branching & Collaboration 📌 git branch – View branches 📌 git branch <name> – Create a branch 📌 git checkout <name> – Switch branches 📌 git checkout -b <name> – Create + switch 📌 git merge <branch> – Merge branches 🔹 3️⃣ Working with Remotes 📌 git remote -v – List remotes 📌 git remote add <name> <url> – Add a remote 📌 git push origin <branch> – Push to specific branch 📌 git pull origin <branch> – Pull specific branch 🔹 4️⃣ Inspecting Changes 📌 git log – Full commit history 📌 git log --oneline – Compact history 📌 git diff – See code differences 📌 git blame <file> – Track line-by-line changes 🔹 5️⃣ Undoing Mistakes (Very Important) 📌 git reset --soft HEAD~1 – Undo commit, keep changes 📌 git reset --hard HEAD~1 – Remove commit + changes 📌 git revert <commit_id> – Safely undo with history 📌 git restore <file> – Discard file changes 🔹 6️⃣ Stashing Work 📌 git stash – Temporarily save changes 📌 git stash list – View stashes 📌 git stash pop – Reapply latest stash 🔹 7️⃣ Tags & Releases 📌 git tag <name> – Create tag 📌 git tag -a <name> -m "message" – Annotated tag 📌 git push origin --tags – Push all tags 🔹 8️⃣ Handling Conflicts & Advanced Ops 📌 git mergetool – Resolve conflicts visually 📌 git merge --abort – Cancel merge 📌 git fetch --all – Fetch from all remotes 📌 git rebase <branch> – Reapply commits cleanly 📌 git cherry-pick <commit_id> – Apply specific commit You don’t need to memorize everything. But mastering these commands will make you 10x more confident in real-world projects. 👉 Follow Ritik Jain for practical developer workflows, interview prep, and tech content. #Git #VersionControl #SoftwareEngineering #Developers #Coding #DevOps #TechCareers
To view or add a comment, sign in
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development