Make Your Git Logs Beautiful & Readable! Let’s be honest—reading git log can feel like deciphering an arduous riddle. Here’s a simple yet powerful command that visualizes your Git log in a clean, structured format: git log --oneline --graph --all --pretty=format:"%C(yellow)%h %C(blue)%ar %C(reset)%s %C(green)%an" 🔹 What does it do? ✅ Shows a concise commit history ✅ Displays branches and merges in a graph ✅ Highlights commit hash, time ago, message, and author Want this always handy? [I bet you do] Add this alias to your ~/.zshrc file: Open .zshrc [will open this file in notepad] then add below command alias logs='git log --oneline --graph --all --pretty=format:"%C(yellow)%h %C(blue)%ar %C(reset)%s %C(green)%an"' Now, just type logs in your terminal to get a clean, structured Git log every time! 🎯 Try it out & let me know—does this make your life easier? 🚀 #Git #SoftwareEngineering #DevTips #Productivity
Saurabh Gupta’s Post
More Relevant Posts
-
Did anyone ask you about the most popular Git merges ? Sounds very basic right . But figure out a GitHub /GitLab/Circle CI repo first time how you can determine which merges actually its displaying . Let's discuss in brief 1. #FastForwardMerge :- Example :- a> Let’s say your main branch is at commit A. b> You create a new branch feature from main and add two commits: B and C. c> The feature branch now looks like A -> B -> C. d> If no new commits were added to main, Git can do a fast-forward merge by moving the main pointer directly to C. e> Result: The main branch history now appears as A -> B -> C. As no new commits were made on the target branch since the feature branch already split-off ,so Git can "fast-forward" by simply moving the target branch pointer to the latest commit . When to use: This is often used for simple updates or when the feature branch doesn’t diverge from the main branch. 2. #SquashMerge :- Example :- a>Starting from commit A on main, you create a new branch feature and make three commits: B, C, and D. b> The feature branch looks like A -> B -> C -> D. c> If you do a squash merge into main, Git will compress B, C, and D into a single commit (say E) on the main branch. d> Result: Instead of main showing every commit (B, C, D), it will show just A -> E, with E being a summary of all changes from B, C, and D. When to use: Ideal for features or bug fixes with many small commits that clutter the commit history. Squashing keeps the history clean and focused.
To view or add a comment, sign in
-
Git Commands Cheat Sheet Here are a few commands I've found super useful: git init - Start a new Git repository. git clone - Cloning repositories like a pro! git status - Check the current status git add - Stage your changes git pull - Keeping my local copy up to date with ease. git branch - Managing branches like a boss. git checkout - Switch branches or restore working tree files. git commit - Documenting changes and committing with confidence. git merge - Combine changes from different branches git log - View the commit history git reset - Unstage changes or reset to a previous commit git push - Sharing my work effortlessly with the team. Plus, many more! Git is a developer's best friend, and these commands are the keys to unlocking its full potential. Save this Git cheat sheet, and never get stuck with Git again!
To view or add a comment, sign in
-
-
𝗚𝗶𝘁 commands cheat sheet that developer must know Simple Git Workflow: 1. Initialize a Repository: 𝙜𝙞𝙩 𝙞𝙣𝙞𝙩 2. Make Changes/Modify files in your working directory. 3. Stage Changes: 𝙜𝙞𝙩 𝙖𝙙𝙙 <𝙛𝙞𝙡𝙚(𝙨)> 4. Commit Changes: 𝙜𝙞𝙩 𝙘𝙤𝙢𝙢𝙞𝙩 -𝙢 "𝙔𝙤𝙪𝙧 𝙘𝙤𝙢𝙢𝙞𝙩 𝙢𝙚𝙨𝙨𝙖𝙜𝙚" 5. Pull/Push Changes Pull changes from the remote repository before pushing. 𝙜𝙞𝙩 𝙥𝙪𝙡𝙡 𝙤𝙧𝙞𝙜𝙞𝙣 <𝙗𝙧𝙖𝙣𝙘𝙝_𝙣𝙖𝙢𝙚> 𝙜𝙞𝙩 𝙥𝙪𝙨𝙝 𝙤𝙧𝙞𝙜𝙞𝙣 <𝙗𝙧𝙖𝙣𝙘𝙝_𝙣𝙖𝙢𝙚> 6. Branching: Create a new branch for new features or bug fixes 𝙜𝙞𝙩 𝙗𝙧𝙖𝙣𝙘𝙝 <𝙣𝙚𝙬_𝙗𝙧𝙖𝙣𝙘𝙝_𝙣𝙖𝙢𝙚> Switch to that branch 𝙜𝙞𝙩 𝙘𝙝𝙚𝙘𝙠𝙤𝙪𝙩 <𝙣𝙚𝙬_𝙗𝙧𝙖𝙣𝙘𝙝_𝙣𝙖𝙢𝙚> 7. Merging: Merge branches when changes are ready to be integrated. Switch first to branch you want to merge 𝙜𝙞𝙩 𝙘𝙝𝙚𝙘𝙠𝙤𝙪𝙩 <𝙗𝙖𝙨𝙚_𝙗𝙧𝙖𝙣𝙘𝙝> Now merge the feature to base 𝙜𝙞𝙩 𝙢𝙚𝙧𝙜𝙚 <𝙛𝙚𝙖𝙩𝙪𝙧𝙚_𝙗𝙧𝙖𝙣𝙘𝙝> 8. Viewing History: 𝙜𝙞𝙩 𝙡𝙤𝙜 𝗕𝗼𝗻𝘂𝘀: Discard Changes in Working Directory: 𝙜𝙞𝙩 𝙘𝙝𝙚𝙘𝙠𝙤𝙪𝙩 -- <𝙛𝙞𝙡𝙚(𝙨)> Remove Untracked Files: 𝙜𝙞𝙩 𝙘𝙡𝙚𝙖𝙣 -𝙙𝙛 Stash your change for later use: 𝙜𝙞𝙩 𝙨𝙩𝙖𝙨𝙝 -𝙢 "𝙈𝙚𝙨𝙨𝙖𝙜𝙚" Use your stash: 𝙜𝙞𝙩 𝙨𝙩𝙖𝙨𝙝 𝙥𝙤𝙥 #linkedin #linkedinglobal
To view or add a comment, sign in
-
-
Merge Conflict in Git 1.merge conflict in GitHub (or Git) occurs when Git cannot automatically resolve differences between two branches during a merge. 2.Conditions where merge Conflict arises in git a- two developers edit the same lines of code in a file on different branches. b-One branch modifies a file, while the other deletes it. c-One branch renames a file while the other modifies its contents. 3.During a merge or rebase, Git compares changes in both branches. 4.If changes cannot be automatically resolved, Git marks them as a merge conflict.
To view or add a comment, sign in
-
-
We all use git and make commits in our day-to-day work. We use different prefixes/icons with the message for [bug], [issue], [feat], [refactor], etc. But what about the message format? I always use imperative forms like Fix an issue, Add a feature because most of the best practice tutorials out there suggest that as well as Github’s default messages “Merge branch”, “Add README.md”, etc. are in the imperative form. But I see many senior devs write commit messages like Added some feature, Fixed issue, etc. Do you have any strong opinion or reason to support any one of them? 1. A commit message should be in the imperative form and answer the question of what changes It will bring to the project when the commit is added. 2. Commit messages should be written as Added, Fixed, etc. and reflect what changes the dev has made in the commit. 3. Format doesn’t matter as long as you or other devs get the idea of the commit by looking at the message. Commit message guidelines: https://lnkd.in/grGsca8s Git Commit message Emoji: https://lnkd.in/gyWt-Rtz
To view or add a comment, sign in
-
How to Work With Branches in Git and GitHub... When adding or changing code, don't forget the most important thing: never mess with the main repo.
To view or add a comment, sign in
-
🚀 Here is Day #2 of Sharing Helpful Git Commands Day #2: Git Notes Git Notes are like sticky notes, you stick onto a commit, allowing you to add extra info without messing with the actual code or the history of your changes. Here how the syntax looks like: > git notes add -m 'Review: Follow me for more' e09c251 👀 Viewing Notes: You can view the notes attached to a commit using the commit hash, like so: > git notes show e09c251 ❌ Deleting Notes: Similar to Viewing, you can delete notes from a commit using the commit hash, like so: > git notes remove e09c251 ⬆ ⬇ Pushing and Pulling Notes: By default, Git Notes are not pushed or pulled along with commits during normal git push and git pull operations. If you want to push or pull notes along with commits, you need to use the --notes flag, like so: > git push origin master --notes Git notes are particularly useful in situations where you need to attach additional information such as code review comments, issue tracking references, or release notes. I hope you liked today's command learnings. 🗯️ Drop your comments on what you think of this command. #GitTips #DeveloperTools #VersionControl
To view or add a comment, sign in
-
Discover Your Git Repo’s Secrets with git-of-theseus Ever wondered how your codebase has evolved over time? git-of-theseus gives you that X-ray view of your repository, showing how much of your current codebase contributes to the main branch and how much is essentially dead weight. This tool doesn’t just stop there—it can also help you see the impact of individual contributors on your project. It’s like holding a mirror up to your repo and asking, “Am I really as efficient as I think I am?” Check it out here: https://buff.ly/3C5Z35r I’ve been exploring it to better understand how my team’s work evolves over time, and it’s eye-opening.
To view or add a comment, sign in
-
Exciting news! We've just published a new blog post on Oh Shit Git that explores the intricacies of managing comments within Git repositories. This insightful piece delves into best practices for using comments effectively, ensuring your code remains clear and maintainable. Whether you're a seasoned developer or just starting out, this post offers valuable tips to enhance your Git workflow. Check it out here: [Oh Shit Git](https://ohshitgit.com/)
To view or add a comment, sign in
-
🚀 Quick Git .gitignore Tip 🚀 Ever faced a situation where your .next directory (or any other ignored folder) keeps showing up in git status even though it's in your .gitignore? Here's a common issue and how to fix it: The Problem The .next directory was added to .gitignore, but it still shows up in git status. This happens because the folder was tracked by Git before it was added to .gitignore. The Solution 1️⃣ Check if the files are still tracked: git ls-files .next/ 2️⃣ If tracked, untrack them without deleting them locally: git rm -r --cached .next/ git commit -m "Remove .next directory from git tracking" 3️⃣ Now .next will be ignored as expected! Why This Works Git ignores only untracked files listed in .gitignore. If a file or folder is already tracked, you need to manually untrack it. 🔧 Fixing this improves your Git workflow, especially for builds or cache files like .next. #Git #DevTips #VersionControl Does this example fit your post style?
To view or add a comment, sign in
-
QAE - II @ Amazon | QAM @ Times Internet | TA @ TCS
2moI remember you taught me this way back in 2021, and I've been using it ever since! I've created a few more aliases since then, though. 😉 #Memories #Technique #Learning #Growth #Aliases