Cloning the Repo Right: My Day 1 Setup Workflow Yesterday I got added to a new project by my lead. Before touching any code, I focused on setup first. I created a local folder, opened terminal in that folder, and cloned the repo using HTTPS: git clone https://lnkd.in/dABQE_CS cd repo-name Then I asked my lead 3 things: - Which branch is the main/live branch? - Where should my code be merged? - What branch naming convention should I follow? Once clear, I created my feature branch from main and started working: git checkout -b feature/your-branch-name Before pushing, I sync with latest main to reduce merge conflicts: git stash -u git checkout main git pull origin main git checkout feature/your-branch-name git stash pop (Resolve conflicts if any) git push origin feature/your-branch-name This small habit has saved me from last-minute PR issues multiple times. How do you handle Day 1 setup when you join a new repo? #git #github #frontenddeveloper #webdevelopment #devlife
Cloning Repo Setup Workflow for New Projects
More Relevant Posts
-
Ever needed to switch branches… but your code isn’t ready to commit? 👀 That’s where git stash helps. It saves your current work (staged + modified tracked changes) and resets everything back to HEAD, so you can safely switch branches without committing incomplete code. Your stashes are stored like a stack (stash@{0} is the latest), and you can reuse them anytime. By default, only tracked files are saved: Add untracked files → git stash push -u Add ignored files → git stash push -a When you’re ready to continue: git stash apply → bring changes back (keep stash) git stash pop → bring changes + remove stash Need a specific one? git stash apply stash@{N} Want your staged changes back too? git stash apply --index git stash pop --index Manage everything easily: Save → git stash push -m "message" View → git stash list Inspect → git stash show -p stash@{N} Delete → git stash drop stash@{N} or git stash clear Think of it as putting your work on pause without losing a thing. 👉 Follow for more practical dev tips! #Git #GitHub #WebDevelopment #DevTips #Developers #Syncfusion
To view or add a comment, sign in
-
-
Most devs know 5 git commands. Then production diverges at 3 a.m. and those 5 aren't enough. Here are 10 I actually reach for every week. 1. git reflog Your undo button. rebase, reset, force-push — reflog remembers. 2. git log --oneline --graph --all See your branch topology without opening a GUI. 3. git commit --amend --no-edit Fix the last commit. Keep the message. 4. git stash push -m "wip: auth on /users" Stash with context. Future You will thank you. 5. git blame -L 42,58 services/auth.py Blame a line range, not the whole file. 6. git rebase -i HEAD~5 Clean your PR history before review, not during it. 7. git cherry-pick <sha> Port one commit across branches. No full-branch merge. 8. git worktree add ../hotfix origin/main Two branches checked out at once. Zero context switch. 9. git bisect start HEAD v1.2 Binary-search your way to the commit that broke prod. 10. git push --force-with-lease The safe force push. Pair with --force-if-includes on git 2.30+. None of these are niche. They are the difference between a 10-minute fix and a 2-hour war room. Save this before your next git emergency. Which one saved you first — and what was the incident? One command, one sentence. #Git #SoftwareEngineering #DeveloperTips #CodingTips
To view or add a comment, sign in
-
I hit a common Git situation this week and finally understood rebase properly. I created a feature branch from main, started coding, and then: 1. Took latest pull from main 2. Stashed my local changes 3. Pulled again 4. Ran stash pop 5. Pushed to my branch and raised a PR Everything looked fine, but before my PR got merged, someone else’s PR merged into main. Now my PR couldn’t merge cleanly. So I had to rebase. ### What rebase means (simple) git rebase main takes my branch commits and replays them on top of the latest main, so my branch is now based on updated history. ### How it affects branches - My feature branch: commit hashes change (history rewritten on my branch) - Main branch: no change at all (until PR is merged) ### Why it helps - Cleaner commit history - Fewer unnecessary merge commits - Easier PR review and merge ### Typical flow I used git checkout my-branch git fetch origin git rebase origin/main # resolve conflicts if any git push --force-with-lease Big learning: rebasing early and often keeps PRs healthier. How do you handle this in your team: frequent rebases or merge-from-main strategy? #git #rebase #github #frontenddeveloper #webdevelopment
To view or add a comment, sign in
-
Git "Undo" is a Developer's Best Friend We’ve all been there: you start coding, forget to create a new branch, or pull the wrong origin, and suddenly your commit history feels like a tangled mess. 😅 I recently hit a situation where my local changes and old commits got merged into the wrong branch. Instead of panicking or "copy-pasting into a notepad" (we’ve all been there!), I used this as an opportunity to master the Git Time Machine. Here are the 3 commands that saved my workflow today: 1️⃣ git log --oneline – My first step to visualize exactly where my HEAD was and find the specific commit hash I needed to return to. 2️⃣ git checkout <hash> – Entering the "Detached HEAD" state allowed me to jump back to a stable version of my code at a specific point in time, cutting through the surrounding noise. 3️⃣ git checkout -b <new-branch> – Once I found the right "save point," I locked it into a fresh, clean branch to keep my feature development isolated and organized. Key takeaway: Mistakes in Git aren't permanent. Understanding the underlying "graph" of your commits turns a stressful mistake into a 5-minute fix. #Git #WebDevelopment #SoftwareEngineering #MERN #ProblemSolving #CodingTips #FullStackDeveloper
To view or add a comment, sign in
-
Git is slowly turning from confusion to clarity… and I’m loving the shift 😊 Today I connected four key concepts that make real-world development actually work: git clone, git branch, git checkout, and pull requests. git clone: bringing a project from GitHub to my local machine, complete with its history. git branch: this is how developers create separate paths to work on new features or fixes without touching the main code. No accident. git checkout: the command that lets me switch between branches or create and move into a new one instantly. Example: git checkout feature-branch Pull Requests (PR) : where everything comes together. After making changes on a branch, I open a PR to propose those changes. It gets reviewed, discussed, and then merged into the main project if everything checks out. So the flow now feels like this: Clone → create a branch → switch/work → open a pull request → merge. #Git #VersionControl #TechJourney
To view or add a comment, sign in
-
-
5 Git commands I wish someone had shown me on day one. Everyone teaches git add, commit, push. Nobody teaches the commands that actually save you when things go wrong. 1. git stash Shelve your uncommitted work without losing it. Switch branches cleanly, come back, and run git stash pop. Done. 2. git log --oneline --graph A visual map of your entire branch history in the terminal. Essential when you're debugging "how did the codebase get into this state." 3. git bisect Binary search through your commit history to find the exact commit that introduced a bug. Sounds complex — takes 5 minutes to learn and saves hours. 4. git commit --amend Fix your last commit message or add a forgotten file before pushing. No more embarrassing "oops" commits cluttering the history. 5. git reflog Your ultimate safety net. Every HEAD movement recorded. Accidentally deleted a branch? Reset too hard? Reflog can bring it back. Almost nothing in Git is truly gone. Bonus: git cherry-pick [hash] — Apply one specific commit from another branch without merging everything else. Surgical and underused. Bookmark this for the next time something breaks at 11 PM. Which of these took you the longest to discover? #Git #CodingTips #DevProductivity #SoftwareEngineering #DevLife
To view or add a comment, sign in
-
-
𝗦𝘁𝗼𝗽 𝗦𝘁𝗮𝘀𝗵𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗚𝗶𝘁 𝗕𝗿𝗮𝗻𝗰𝗵𝗲𝘀 You switch branches often. You stash changes. You check out new code. You lose your place. Git Worktree solves this. It lets you open multiple branches at once. Each branch gets its own folder. All folders link to one repo. Use it to: - Review a PR without stopping your work. - Test scripts on different branches side by side. Git includes this tool. Many developers miss it. It saves you time. Do you use Git Worktree? Source: https://lnkd.in/gcRRy8jF
To view or add a comment, sign in
-
Ever felt paralyzed right before integrating a feature branch? You're definitely not alone! Let's talk about the ultimate developer debate: Git Merge vs. Git Rebase (and the magic of the Squash commit). Understanding when to use which command is the key to a clean, maintainable project history. Here is the quick breakdown: - Git Merge: The faithful historian. It takes two branches and joins them together, preserving the exact history of how and when things happened. - Git Rebase: The clean freak. It essentially picks up your whole branch and moves it to the tip of the main branch, rewriting history to create a perfectly linear story. - Git Squash: The ultimate decluttering tool. Before you merge or rebase, squashing allows you to take all those tiny "wip", "typo fix", and "test" commits and compress them into one single, meaningful commit. Your commit history tells the story of your software. Are you writing a messy rough draft, or a published novel? ByteByteGo #Git #VersionControl #SoftwareEngineering #WebDevelopment #CodingLife #ProgrammingTips
Git MERGE vs REBASE: Everything You Need to Know
https://www.youtube.com/
To view or add a comment, sign in
-
Ever had that moment where you're deep in a feature, everything clicking, and then ping "Can you fix this bug real quick?" You stash your changes. Switch branches. Wait for dependencies. Fix the bug. Switch back. Try to remember where you were. That mental context? Gone. 𝗚𝗶𝘁 𝗪𝗼𝗿𝗸𝘁𝗿𝗲𝗲𝘀 + 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝘀𝗼𝗹𝘃𝗲𝗱 𝘁𝗵𝗶𝘀 𝗳𝗼𝗿 𝗺𝗲. What are worktrees? Normally you switch branches inside one folder. A worktree checks out a different branch in a separate folder sharing the same Git history. No cloning. No duplicating. 𝘨𝘪𝘵 𝘸𝘰𝘳𝘬𝘵𝘳𝘦𝘦 𝘢𝘥𝘥 ../𝘩𝘰𝘵𝘧𝘪𝘹 𝘮𝘢𝘪𝘯 That's it. A second working directory, ready in seconds. Why this matters with Claude Code: Run a separate Claude Code session in each worktree. Each session stays scoped to its own task its own files, its own branch, its own context. Worktree 1: Claude helping you build a feature Worktree 2: Claude fixing review comments on a different PR Worktree 3: Claude writing tests while CI runs on the other two No crossed wires. No "wrong branch" suggestions. Each session is laser-focused. How I use it daily: I keep 3 reusable worktrees. When a new task comes in, I reset one to main, create a branch, run claude, and start working in under 10 seconds. My other tasks stay exactly where I left them. No stashing. No dependency reinstalls. No lost context. Quick setup: 𝘨𝘪𝘵 𝘸𝘰𝘳𝘬𝘵𝘳𝘦𝘦 𝘢𝘥𝘥 ../𝘵𝘢𝘴𝘬-2 𝘮𝘢𝘪𝘯 𝘤𝘥 ../𝘵𝘢𝘴𝘬-2 claude When done: 𝘨𝘪𝘵 𝘸𝘰𝘳𝘬𝘵𝘳𝘦𝘦 𝘳𝘦𝘮𝘰𝘷𝘦 ../𝘵𝘢𝘴𝘬-2 Tips: Keep worktrees around. Reset to main instead of recreating. Worktrees share Git history - commits and branches are visible everywhere. Perfect for stacked PRs - one worktree per PR, one Claude session per piece. Pro tip: Ask Claude Code to "create 3 worktrees for me" and it will set them all up within seconds. You don't even need to remember the commands. #GitWorktrees #ClaudeCode #DeveloperProductivity #AIAssistedCoding
To view or add a comment, sign in
-
Stop the "Stash & Switch" madness. 🛑 We’ve all been there: You’re deep in a feature, your workspace is a mess of half-finished logic, and suddenly... a critical bug hits production. Most devs reach for git stash. Some make a messy "WIP" commit. But there’s a better way that most people ignore: Git Worktree. Instead of flipping a single folder between branches, Git Worktree lets you "check out" multiple branches into separate folders simultaneously, all linked to the same local repo. Why is this a game-changer? ✅ Zero Context Switching: Keep your feature code open in one VS Code window and your hotfix in another. No stashing required. ✅ Parallel Testing: Run a heavy test suite or build process on one branch while you keep coding on the other. ✅ Code Reviews: Need to test a teammate's PR? Open it in a new worktree without touching your current progress. ✅ No More npm install Loops: If branches have different dependencies, worktrees keep their respective node_modules intact. No more re-installing every time you switch. The Magic Command: git worktree add ../hotfix-folder hotfix-branch It’s one of those "once you know it, you can't go back" tools. Are you still stashing, or have you made the switch to Worktrees? Let’s hear your workflow hacks in the comments! 👇 #Git #WebDevelopment #SoftwareEngineering #DevOps #ProgrammingTips #Efficiency
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