Git Config, Amend & .gitignore Essentials for Clean Version History

Three phase of git in local machine. 1. Untracked 2. Staged 3. Committed Let discuss about them below: Untracked: Every file in a directory after git init is below in this. Basically file are exits but the they are not a part of git version control. That means if any files are deleted from here we can restore them via git. If we want check git status via the command: git status; this files are under the untracked files and the file names are red colored. Staged: Basically a file in being a part of version control from here. If any file which is add in this phase will show the file name in green color and under the changes to be committed category. We can restore any file from here if they deleted from our local machine. Committed: This phase is the final phase of a local git repository. Here we can create a version of our work with a meaning full message. If we commit anything we can see them via git log command. Git status command won't give us any result it will say nothing to commit. [N. B: If any file(s) or directory is included at .gitignore can't tracked by git. It will automatically vanish for git] #devOps #git #learnNewThings

𝗚𝗶𝘁 - 𝗧𝗵𝗲 𝗱𝗮𝗶𝗹𝘆 𝗧𝗶𝗽 As we all know git is one the most powerful tool we have, here are some tips to "optimize" your daily work 𝙗𝙧𝙖𝙣𝙘𝙝.𝙨𝙤𝙧𝙩 -𝙘𝙤𝙢𝙢𝙞𝙩𝙩𝙚𝙧𝙙𝙖𝙩𝙚 What 𝚋𝚛𝚊𝚗𝚌𝚑.𝚜𝚘𝚛𝚝 -𝚌𝚘𝚖𝚖𝚒𝚝𝚝𝚎𝚛𝚍𝚊𝚝𝚎 Does When you set this configuration, any command that lists branches (like 𝚐𝚒𝚝 𝚋𝚛𝚊𝚗𝚌𝚑) will sort them based on the 𝗱𝗮𝘁𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗹𝗮𝘀𝘁 𝗰𝗼𝗺𝗺𝗶𝘁 made to that branch. 𝗦𝘁𝗮𝗻𝗱𝗮𝗿𝗱 𝗯𝗲𝗵𝗮𝘃𝗶𝗼𝗿: • Branches are listed A-Z. 𝗪𝗶𝘁𝗵 𝘁𝗵𝗶𝘀 𝘀𝗲𝘁𝘁𝗶𝗻𝗴: • The branches with the most recent activity appear at the bottom of the list (closest to your prompt), making them much easier to find in a repository with dozens of stale branches. 𝗣𝗿𝗼-𝗧𝗶𝗽: Adding More Detail • If you want an even more powerful view of your recent work, you can create a "𝘀𝘂𝗽𝗲𝗿 𝗮𝗹𝗶𝗮𝘀" that shows the date and the last commit message:    • Set alias 𝙜𝙞𝙩 𝙘𝙤𝙣𝙛𝙞𝙜 --𝙜𝙡𝙤𝙗𝙖𝙡 𝙖𝙡𝙞𝙖𝙨.𝙧𝙡 "𝙗𝙧𝙖𝙣𝙘𝙝 --𝙨𝙤𝙧𝙩=-𝙘𝙤𝙢𝙢𝙞𝙩𝙩𝙚𝙧𝙙𝙖𝙩𝙚 --𝙛𝙤𝙧𝙢𝙖𝙩='%(𝙖𝙪𝙩𝙝𝙤𝙧𝙙𝙖𝙩𝙚:𝙧𝙚𝙡𝙖𝙩𝙞𝙫𝙚)%𝟬𝟵%(𝙧𝙚𝙛𝙣𝙖𝙢𝙚:𝙨𝙝𝙤𝙧𝙩)%𝟬𝟵%(𝙨𝙪𝙗𝙟𝙚𝙘𝙩)'" You just created a powerful new Git alias named 𝚛𝚕 (Recent List). 𝗨𝘀𝗮𝗴𝗲: 𝗴𝗶𝘁 𝗿𝗹 Enjoy.... #GIt #DevOps

This is a very useful tip. Especially when working in a team with many branches and many commits. You can set it up to immediately see what branch was most recently used, when was the most recent commit, what was it, and maybe even add the person who committed.

Wrote a short note on something I recently found useful while working with Git — git cherry-pick. It helped me move specific commits across branches without merging everything, especially in a GitFlow setup. Tried to keep it simple and practical. Read here: https://lnkd.in/dt4xQ7Da #git #devops #versioncontrol

Demystifying Git: The 4 Core Layers of Git. Most developers treat Git like a magic undo button, but understanding its actual internal architecture completely changes how you use it.These are the 4 core layers of git. • Persistence: Git is a key-value store. Every file (blob), directory (tree), Annotated Tag and commit is saved as an immutable object in .git/objects identified by a unique SHA-1 hash. • Content Tracker: Git tracks complete snapshots of your content, not file differences. These snapshots are maintained by a Tree object, which is dynamically generated from the index file (staging area) at the moment of commit. • Version Control: Git connects your snapshots into a timeline structured as a Directed Acyclic Graph (DAG). The Commit object acts as a node in this graph, storing metadata to link a specific snapshot to its parent history. • Distributed Version Control: Git is peer-to-peer. Every local clone is a fully autonomous backup of the entire project, and network operations (push/fetch) merely sync missing objects and update pointers. Branches, Head and tags aren't duplicated folders; they are like simply lightweight pointers to a commit within the DAG, making branching an instantaneous pointer swap. These insights are heavily inspired by the teachings of Mohit Dharmadhikari at VoidInfinity Tech. #Git #SoftwareEngineering #SystemArchitecture #DistributedVersionControl

🏷️ Git Tip of the Day: git describe Commit hashes are precise but not very human‑friendly. git describe gives commits readable names based on the nearest tag, making version tracking easier. 👉 Example: git describe --tags Suppose your repo has a tag v1.4.0 and you run this on a commit 7 commits ahead. Output: v1.4.0-7-g89abcde This means: • The commit is 7 commits after tag v1.4.0 • 89abcde is the abbreviated commit hash Now you can reference this build as v1.4.0-7 instead of a long hash. 🔎 Real-life analogy: Think of it like naming a photo “Vacation2026‑Photo7” instead of “IMG_89abcde.” It’s still unique, but now it’s meaningful and easy to remember. 💡 Perfect for versioning builds, CI/CD pipelines, and release notes. #GitTips #DevTools #SoftwareEngineering #CodingLife #VersionControl #GitDescribe #DeveloperProductivity #CodeVersioning #ProgrammingInsights #ReleaseManagement

Ever had your git push rejected with a confusing message like: “rejected (fetch first)” “branches have diverged” I recently ran into this — and finally understood what Git was trying to protect me from. Here’s the simple breakdown What’s actually happening? You and the remote repository (GitHub) both made changes. Git blocks your push to prevent overwriting someone else’s work. The fix (clean & safe way): git pull origin main --rebase git push origin main What --rebase really does: Instead of merging, it: Temporarily removes your commits Pulls the latest changes Re-applies your commits on top Result: clean, linear history (no messy merge commits) Common blockers & how to handle them Unstaged changes? You modified files but didn’t stage them yet. Fix: git add -A git commit -m "your message" Not ready to commit? Use stash: git stash git pull --rebase git stash pop Conflicts during rebase? # fix files git add . git rebase --continue Key takeaway If your push is rejected: Always sync first, then push git pull --rebase git push #Git #DevOps #Terraform #LearningInPublic #SoftwareEngineering

Most people think git log is just for checking commits. Typical flow: git commit → git log At first glance, it only shows author, date, and message. Not very exciting, right? Here’s the thing: git log can do much more. After a feature is merged, it becomes your breadcrumbs for tracking down issues. Pro tip: Write consistent commit messages: [TYPE] [TICKET] [MODULE]: Summary Types include: FEATURE, IMPROVEMENT, TEST, FIX, REFACTOR, DOC Search by ticket: git log --grep "TICKET" -p Now you can see all changes for a ticket. Over time, patterns emerge, and bugs become easier to trace. The takeaway: Meaningful commit logs turn git log from a simple list into a tool you can actually rely on.

Git is much more than just add, commit, and push. When working on large codebases, the real magic happens when you master rebasing, squashing, and cherry-picking. Recently, I decided to test my version control skills through the Git-Gud challenges (created by Khaled Riyad). I successfully completed all the challenges, which gave me solid, hands-on practice with: 1. commit & amend 2. reset-soft 3. branching 4. merge, and resolving merge-conflict 5. stash 6. rebase & Interactive Rebasing (squash, reword, drop, reorder, edit) 7. Navigating a detached-head 8. cherry-pick 9. reflog I also contributed to Git-Gud and opened a PR and modified the validation logic in (00-commit's test) by adding the -i flag to make it allowing Uppercase and Lowercase. And it got merged, here it is: https://lnkd.in/dNhgYFmn Mastering these specific commands makes managing project histories and collaborating on large repositories so much smoother. Big thanks to Khaled Riyad for providing such an excellent resource! (Check out the video below to see my workflow successfully passing the challenges). #Git #VersionControl #GitHub #DeveloperTools #SoftwareEngineering #BackendDevelopment

🚀 Git Workflow Demo Completed Here’s the workflow I documented for application development: - Repo setup and remote connection - Branching (`main`, `dev`, `feature`) - Merge and rebase conflict resolution - Release tagging (`v1.0`) 👉 Repo link: https://lnkd.in/gJhPbByC   📄 Full documentation: Git workflow demo.docx (included in repo) This project shows a structured workflow that can be applied to any application and forms the foundation for CI/CD pipelines. #github#devops#cicd#versioncontrol#applicationdevelopment#tech#cloudcomputing