Coder Legion - Recent posts tagged version-control

No, Git Isn't Dead. Anthropic's Robots Just Needed a Bigger One.

Fri, 30 Oct 2026 07:44:39 +0000

The viral version says Git died in 2026.

The real story is funnier: seven humans spent five months building a version control system so their AI could keep merging 30,000 changes a day and it works by banning the two features Git is most famous for.

A post went around this week with the energy of a tabloid that just found out your marriage is over before you did. "Git is DEAD in 2026?" Two screaming-face emojis.

Anthropic has replaced Git with its own system called Scion, the robots write too much code, Git simply couldn't keep up, pour one out for the little distributed version control system that could.

And here's the thing that ruins a perfectly good funeral: the story is basically true. Anthropic did build an in-house source control system called Scion. They did move their internal monorepo off Git.

They are, by their own numbers, merging more than 30,000 code changes a day. I read their actual engineering write-up, because somebody has to, and it's a genuinely great piece of engineering.

It's also not a eulogy for Git. It's a note from the office saying the robots need a bigger desk. Let me show you the difference, because the difference is the whole joke.

The clickbait says "Git is dead." The footnotes say "please do not try this at home."

Here's the first thing the viral version conveniently loses. Anthropic goes out of its way to say Scion is not for everyone, is built only for one absurd situation, and is not going to be released.
This is the software equivalent of a Formula 1 team explaining that yes, the car does 370 km/h, and no, you cannot drive it to Big Bazaar.

So Git isn't dead. Git is fine. Git is running on your laptop right now, serenely, the way it has for twenty years, handling your eleven commits a week without filing a complaint.
What actually happened is narrower and far more interesting: one company hit a scale so ridiculous that a core assumption of Git stopped being free, and they had to pay to make it go away.

That assumption is the one every Git tutorial sells as the feature.

The feature that became the bill
Git is decentralized. Everyone who clones the repo gets the entire repo - every file, every branch, all of history, the whole cathedral - on their own machine. In 2005 this was revolutionary and correct.

It's why your internet going out doesn't stop you from committing. It's the thing we all fled Subversion and Perforce to get.

Now put a number on "the entire repo" at Anthropic scale. Their main branch history is pushing 100 GB. A compressed working copy is over 25 GB. And they run roughly 25 million CI checkouts a day. Do the naive multiplication and you get an estimate of more than 600 petabytes of Git traffic. Daily. To check out code.

Image: 100 GB history × 25M checkouts/day = 600 PB Press enter or click to view image in full size
Sit with the comedy of that. The beautiful, democratic idea - everybody gets a full copy! - is wonderful right up until your contributors are a swarm of always-online machines that don't need a full copy, don't go on holiday, and want to clone the cathedral every eight seconds. At that point "everybody gets everything" stops being empowerment and starts being a DDoS you're running against yourself, on purpose, with a straight face.

At peak, Anthropic was babysitting several hundred Git mirrors just to survive its own enthusiasm.
The robots didn't kill Git. The robots just took the one thing we loved about Git - you always have the whole thing - and used it ten million times a day until it showed us the bill.

Scion, or: we have reinvented Perforce and we feel great about it
So what did seven engineers build over five months? Reader, they went back to the office.

Scion is centralized. The authoritative servers are backed by Google's Spanner and cloud storage. Clients keep a small bounded cache. Most CI jobs don't even hold a local copy of the repo - they just ask the server over an API, like a civilised person ordering off a menu instead of being handed the entire kitchen.

Twenty years of the industry sprinting away from centralized version control, and the most advanced AI lab on Earth looked at its robot-generated code tsunami and sprinted straight back, yelling "it's fine, it's different when WE do it."

And - annoyingly - it is different when they do it. The wheel of history is round for a reason.
But here's my favourite detail, the one I want cross-stitched on a pillow. In Scion, branches and tags are discouraged.

Read that again. They built a version control system whose official guidance is to go easy on the two features that, for most of us, ARE version control. The reasoning is airtight - branches and tags are global state every server has to agree on, and global agreement is exactly the thing that doesn't scale when you're content-addressing immutable changesets across three tiers of cache.

But stripped of the justification, the sentence is pure deadpan poetry: welcome to our new version control system, please try not to control any versions.
The rest is seriously elegant, and I mean that with no snark left over. Commits are "changesets" that store only what changed. Everything is content-addressed and immutable, so any cache or server can answer a request without phoning a friend.

Checkouts are sparse and virtualized - a job pulls only the files it actually reads. Three tiers: a daemon on every node, regional caches, authoritative servers, each reportedly landing a cache hit rate above 99%. The payoff Anthropic reports: 200× less CPU and memory than the old mirror fleet, checkouts that went from minutes to seconds, and 25% of CI capacity handed back like finding money in a coat.

The part that should make every architect a little uneasy

Here's the detail the hot-takes skip, and it's the one I can't stop poking. Claude wrote most of Scion. The AI wrote the version control system that exists because the AI writes too much code for the old version control system.

That's not a dunk. It's an ouroboros, and it's genuinely where we are: the tooling layer is now being rebuilt, in real time, by the thing that broke the tooling layer. The system's workload created the system's solution and also authored it. Somewhere in there is a snake eating its tail while filing a pull request against itself - sorry, merging a changeset, there are no pull requests, we discourage branches.

And one more quietly radical bit: they dropped the merge queue. The old model - line up, test, then merge - stopped making sense at 30,000 a day, so Scion leans on post-merge testing and rollback instead. Merge first, find out later, roll back if it screamed. Which, if you've watched how agents write code, is also precisely how the agents write code. The tool didn't just scale to the robots. It started thinking like them.

Steal this (the you-are-not-Anthropic edition)

Architect hat on. The single most expensive mistake you can make with this story is to read "Anthropic replaced Git" and feel even a flicker of FOMO. You do not have this problem. If you build Scion for your fourteen-person team and your 400 MB repo, you have not future-proofed anything; you have cosplayed a scaling crisis and billed it to your runway.

The transferable lesson isn't centralize your VCS. It's this:

Your tool's killer feature and your tool's eventual bill are the same line item, read from different distances. "Every clone is a full repo" was the pitch and the tombstone. Audit your own stack: which beloved convenience becomes a catastrophe at 100× your current volume? That's your Git-history-is-100-GB moment, waiting.

Scale doesn't just break your performance; it breaks your assumptions. Anthropic didn't need a faster Git. They needed to delete the premise that everyone holds everything. Faster is an optimization. Deleting the premise is an architecture.

When the workload changes species, the tool has to change species. Humans and agents are not the same kind of client. Most of your tools were designed for the first and are about to be flooded by the second. That is the actual headline, and it has nothing to do with Git.

So no, Git isn't dead. Git got the highest compliment our industry gives: it was pushed until the exact shape of its one big idea became visible, and the only people it broke for were the ones running a code-generation operation the size of a small nation's power grid.

The robots didn't bury Git.
They just found the edge of the map - and politely, in a five-month sprint, drew a little more of it.

Hardik

I've spent about two decades building data and AI systems, long enough to have personally fled Perforce for Git and to now watch the industry's most advanced lab speedrun the return trip with a straight face. I write about AI in production: the parts that are genuinely new, and the parts that are just the wheel of history turning one more honest rotation.
If this made you want to go check how big your repo history actually is - follow me here, and clap a few times so Medium shows it to the next person about to build Scion for their to-do app.

Sources / further reading: Anthropic Engineering, "Creating in-house source control" (the primary source for Scion's architecture, the merge-volume figures, and the self-reported performance numbers). Coverage and analysis: DevOps.com, "Anthropic Builds Its Own Source Control After AI Agents Outgrow Git"; Crypto Briefing, "Anthropic replaces Git with custom source control system Scion"; AlphaSignal, "Anthropic Ditched Git and Built Scion After Claude Caused 12x Merge Surge." A note on the numbers: the 200× and 25% figures are Anthropic's own, measured against their previous Git mirror fleet - not against Git in general - and are not independently verified. The ~600 PB figure is a hypothetical estimate for naive fetching, not measured traffic. The viral "nearly 100× faster checkouts" is a rounding-up of Anthropic's actual phrasing, "minutes to seconds." And the separate "20× less memory, 4× faster" stat floating around belongs to a different ingestion-pipeline rewrite, not Scion. The practice is real and impressive; the funeral is editorial.

Beyond the Pull Request: Why Delta Could Reframe AI Code Review

Tue, 22 Sep 2026 12:09:49 +0000

Let’s be honest: the traditional pull request (PR) was designed for a different era of software development. It worked well when people wrote relatively small, self-contained changes and review could focus on a neat diff. But as AI coding agents generate larger changes faster, a diff alone can leave reviewers reconstructing why a solution was chosen.

Nathan Sobo—Zed’s CEO and co-founder, who led GitHub’s Atom team—argues that development is moving toward a richer unit of work: the conversation that produced the code. In September 2026, Zed launched Delta in public beta, a separate multiplayer environment for working with coding agents and reviewing their output. Delta is not a finished GitHub replacement, but it is a serious attempt to rethink one core GitHub workflow: the pull request.

“It seems like everyone is in a race to replace GitHub right now.” — Nathan Sobo

The PR problem in the age of AI

A pull request is excellent at presenting a proposed change, but it usually does not retain the chain of reasoning behind it. That gap is more noticeable with agents: the important context may include the initial task, alternative approaches, failed experiments, review feedback, and the prompts that produced the final implementation.

This does not make PRs obsolete for every team or repository. They remain a familiar, durable coordination layer—especially for open-source communities. Delta’s point is narrower and more interesting: a review should not force a teammate or their agent to reverse-engineer decisions that the original conversation already contains.

Delta’s central idea: the thread

Delta makes the thread—the connected conversation, worktree, review, and landing process—the primary unit of collaboration. A developer can work with an agent, invite teammates into that thread, and let them inspect the context as well as the code.

Reviewers can create a dedicated review subthread. Each review receives an isolated copy of the parent thread’s worktrees, so a reviewer can ask an agent to investigate a concern or try a fix without disrupting the original work. Accepted fixes can then be incorporated before the change is landed.

What DeltaDB actually changes

Underneath Delta is DeltaDB, which Zed describes as extending Git’s content-based versioning with incremental versions based on deltas. It records edits and human/agent messages between commits, preserving how the code evolved during a thread.

That distinction matters. DeltaDB does not eliminate Git commits: commits remain the checkpoints teams can push, pull, and build from. Instead, DeltaDB retains the context and intermediate work that normally disappears between those checkpoints. Participants get synchronized local copies of the worktree, while the conversation and code stay connected in real time.

Dogfooding the model

Zed has turned off pull requests for Delta’s own repository and says the team now builds Delta entirely within Delta. At the time of the public-beta announcement, Sobo reported that 33 people had landed 570 changes to main since that switch.

It is an encouraging operational data point, not proof that every organization should abandon PRs. Still, it shows that the workflow can support real product development rather than only a polished demo.

GitHub is still part of the picture

Zed is keeping its public Zed repository on GitHub for now. The reason is practical: the repository is where the wider community files issues and contributes changes. Zed is encouraging contributors to share Delta threads alongside normal pull requests during this transition.

Sobo told The New Stack that Zed is moving more cautiously with the public repository because hundreds of monthly contributors depend on the existing workflow. GitHub’s community and social layer are not incidental features, and Zed has not claimed to have replaced them.

The bottom line

The provocative claim is not that commits or Git vanish. It is that the thread may become the richer record of software work: a place where the idea, implementation, review, and revision remain connected.

For teams reviewing agent-generated code, that is a compelling direction. Delta’s real test will be whether this context-rich model improves review quality without creating new overhead or fragmenting the collaboration ecosystems developers already rely on. For now, it is best understood as a promising public-beta experiment in continuous, agent-native engineering—not GitHub’s obituary.

Sources

About the Author

Jarno S. AEOvara is a technology professional specializing in software development, AI integration, and modern engineering workflows. He helps teams navigate the rapidly evolving landscape of software engineering.

Connect with Jarno: aeovara.fi/asiantuntija

Git & GitHub Basics Every Beginner Developer Should Know

Tue, 04 Aug 2026 05:00:00 +0000

Introduction

I avoided learning Git properly for way longer than I should have. I'd just zip my project folder and rename it project-final-v2-ACTUAL-FINAL whenever I wanted a backup. It worked, technically, until it very much didn't.

Git solves exactly this problem, and you genuinely only need about 10 commands to be productive with it. Here's everything you actually need, skipping the theory you won't use day-to-day.

Git vs GitHub — What's the Difference?

Git is the version control tool that runs on your computer. It tracks changes to your files over time.
GitHub is a website that hosts your Git projects online, so you can back them up, share them, and collaborate with others.

You can use Git without GitHub. You can't really use GitHub without understanding Git.

Setting Up (One-Time)

git config --global user.name "Your Name"
git config --global user.email "*Emails are not allowed*"

The Core Workflow

1. Initialize a repository

git init

Run this once, inside your project folder, to start tracking it with Git.

2. Check what's changed

git status

Shows you which files are modified, new, or staged. You'll run this constantly — it's your "what's going on right now" command.

3. Stage your changes

git add .

This stages all changed files, preparing them to be committed. Use git add filename.js to stage just one file.

4. Commit your changes

git commit -m "Add contact form component"

This saves a snapshot of your staged changes, with a message describing what you did. Write clear, specific messages — future you will thank present you.

Connecting to GitHub

5. Create a repository on GitHub

Go to github.com, click "New Repository," give it a name. Don't initialize it with a README if you already have a local project — you'll connect them next.

6. Link your local project to GitHub

git remote add origin https://github.com/yourusername/your-repo.git

7. Push your code

git push -u origin main

The -u flag remembers this connection, so future pushes just need git push.

Branches — Working Without Breaking Things

A branch lets you work on a new feature without touching your main, working code.

git checkout -b new-feature

Creates and switches to a new branch called new-feature.

git checkout main

Switches back to your main branch.

Once your feature works, merge it back:

git checkout main
git merge new-feature

Why this matters: if you're experimenting with something risky, do it on a branch. If it breaks, your main branch stays untouched and safe.

Pulling Changes

If you're working across multiple machines, or collaborating with others:

git pull

Downloads and merges the latest changes from GitHub into your local project.

Common Beginner Mistakes

Committing giant, vague changes. "fixed stuff" tells you nothing six months later. Commit small, logical chunks with clear messages.
Forgetting to pull before pushing when working with others — leads to avoidable merge conflicts.
Committing sensitive files like .env with API keys. Always set up a .gitignore file before your first commit.
Never using branches. Working directly on main for every experiment is how small mistakes become big headaches.

A Basic .gitignore for Frontend Projects

node_modules/
.env
dist/
.DS_Store

Save this as .gitignore in your project root before your first commit — it stops these files/folders from ever being tracked.

Final Thoughts

You don't need to memorize every Git command that exists. status, add, commit, push, pull, and basic branching cover probably 90% of real, everyday use. Learn these solidly, and the rest you can look up as you go.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev

Git Branch Pinning and Auto-Archiving: What's New in Tower 13 for Windows

Wed, 15 Jul 2026 17:21:47 +0000

Every long-running repo ends up with the same problem: a branch list full of stuff that's already merged or long abandoned, with the branches you actually need buried somewhere in the middle.

Tower 13 for Windows adds two features built specifically to deal with that — Branch Pinning and Automatic Branch Management. Both have existed on Tower for Mac for a while (Pinning since Tower 8, Auto Branch Management since Tower 15) and are now available on Windows.

Branch Pinning

Right-click a branch to pin it, and it moves into a dedicated "Pinned" section at the top of the sidebar. You can pin or unpin several branches in one go, pinned branches are automatically protected from auto-archiving, and pins are stored in your Git config so they persist reliably.

Fully Merged and Stale badges

New badges flag branches as Fully Merged (every commit integrated into the parent, and the tracked remote branch already deleted) or Stale (no recent activity). Selecting a flagged branch brings up a hint view with a one-click delete option, so you can confirm cleanup without digging through menus.

Automatic Branch Management

A new "Archived Branches" view holds branches you've set aside — added manually via drag-and-drop or the context menu, or moved there automatically based on a stale interval you configure in settings. Clicking the notification counter in the footer opens a dialog to review and approve archiving in bulk before anything happens. Archived branches can be unarchived at any time, and any branch can be flagged "Skips Auto-Archiving" if you want to protect it without formally pinning it.

Other changes in this release

Untracked files now show their contents directly in the diff view, the Windows build has been updated to run on .NET 10, and there are various fixes across the diff view, submodule handling, and multi-branch/tag operations.

Full details: Tower 13 for Windows release notes.

Git Err: Updates were rejected because a pushed branch tip is behind its remote

Mon, 24 Nov 2025 00:19:50 +0000

Git is a powerful tool for version control, allowing developers to collaborate seamlessly on projects. However, it's not uncommon to encounter errors and issues along the way. One such error that often bothers developers is "Updates were rejected because a pushed branch tip is behind its remote." . This error is seen when you're attempting to push changes to a remote branch that has progressed beyond your local branch's commit history. Fix: Pull before pushing. In this article, we'll delve into what this error means, how to recreate it, and various solutions to resolve it.

Index:

What is this problem?
How to recreate this issue?
What was wrong here?
Solutions
FAQs
Conclusion
References

What is this problem?

When you encounter the error message "Updates were rejected because a pushed branch tip is behind its remote" it means that you're attempting to push changes to a remote branch that has progressed beyond your local branch's commit history. Essentially, the remote branch has received new commits that your local branch doesn't have, causing a conflict during the push operation.

How to recreate this issue?

There are many scenarios in which this error can occur:

Parallel Development: When multiple developers are working on the same branch concurrently and one developer pushes changes to the remote before another developer pulls and integrates those changes locally.
Reverting Commits: If you revert commits locally and then attempt to push without reconciling the changes with the remote branch.
Force Push: Trying to force push changes without considering the implications, especially when working in a collaborative environment.

Tip: Regular communication can help avoid conflicts and ensure everyone is aware of ongoing changes.

Example:

Suppose you're working on a collaborative project with a remote repository hosted on GitHub. You make some changes to a file locally and commit those changes to your branch.

$ git add .
$ git commit -m "Updated feature X"

Now, when you attempt to push your changes to the remote repository,

$ git push

you encounter the error:

! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'https://github.com/username/repository.git'
hint: Updates were rejected because a pushed branch tip is behind its remote counterpart.

Tip: Pull changes from the remote branch frequently to keep your local repository up to date.

Error message:

What was wrong here?

The error occurred because the remote branch has progressed since your last local commit. Therefore, Git refuses to accept the push to avoid overwriting changes made by others.

Note: It's essential to understand the implications of Git operations like push and force push, especially in collaborative settings. Regularly syncing your local repository with the remote and communicating with your team can mitigate many issues.

Solutions:

1. Pull Changes:

Steps using Command Line:

Open Terminal and navigate to your project directory.
Run the command:git pull origin <branch_name>
If there are any conflicts, resolve them using next method or manually edit the conflicting files.
Once conflicts are resolved, commit the changes and push them to the remote repository.

$ git pull origin
$ git push

Steps using Visual Studio Code:

Note: Ensure you have the Git extension installed (you can find it in the Extensions view by searching for "Git").

Open Visual Studio Code and navigate to your project directory.
Open the Source Control view by clicking on the Git icon in the Activity Bar on the side.
Click on the three dots (...) to open the More Actions menu.
Click on "Pull" to fetch and integrate changes from the remote repository.
If there are any conflicts, Visual Studio Code will prompt you to resolve them using its built-in merge tool.
Resolve conflicts and stage the changes.
Commit the changes using the check mark icon in the Source Control view.
Push the changes to the remote repository by clicking on the "Push" button.

2. Rebase:

Steps using Command Line::

Open terminal and navigate to your project directory.
Run the command: git rebase origin/<branch_name>
Resolve any conflicts that arise during the rebase process. You will see prompts to resolve conflicts.
Once conflicts are resolved, continue the rebase process by running: git rebase --continue
After the rebase is complete, push your changes to the remote repository.

$ git rebase origin/
$ git rebase --continue
$ git push

Steps using Visual Studio Code:

Note: Ensure you have the Git extension installed (you can find it in the Extensions view by searching for "Git").

Open Visual Studio Code and navigate to your project directory.
Open the Source Control view by clicking on the Git icon in the Activity Bar on the side.
Click on the three dots (...) to open the More Actions menu.
Click on "Pull" to fetch and integrate changes from the remote repository.
Once the pull is complete, click on the three dots (...) again and select "Rebase" from the More Actions menu.
If there are any conflicts during the rebase process, Visual Studio Code will prompt you to resolve them using its built-in merge tool.
Resolve conflicts and stage the changes.
Continue the rebase process by clicking on the "Continue" button in the Source Control view.
Once the rebase is complete, push the changes to the remote repository by clicking on the "Push" button.

3. Force Push (with caution):

Caution: Force pushing should be used sparingly and only when necessary. Always communicate with your team before force pushing to avoid conflicts and data loss.

Steps using Command Line:

Open Terminal and navigate to your project directory.
Run the command: git push -f origin <branch_name>
Confirm that you understand the consequences of force pushing and ensure that you're not overwriting any important changes.
Push your changes to the remote repository using force push.

$ git push -f origin
$ git push

Steps using Visual Studio Code:

Note: Ensure you have the Git extension installed (you can find it in the Extensions view by searching for "Git").

Open Visual Studio Code and navigate to your project directory.
Open the Source Control view by clicking on the Git icon in the Activity Bar on the side.
Make sure you have the latest changes by pulling from the remote repository (click on the three dots (...) and select "Pull").
After ensuring that you're not overwriting any important changes, click on the "..." button and select "Push" from the More Actions menu.
In the confirmation dialog, check the box labelled "Force Push" and click on the "Push" button to force push your changes to the remote repository.

FAQs Q. Can I lose my changes by force pushing?
A. Yes, force pushing can overwrite commits on the remote branch, potentially losing others' work. Use it judiciously and communicate with your team.

Q. Why does Git reject non-fast-forward pushes?
A. Non-fast-forward pushes are rejected to prevent unintentional overwriting of commit history. They can lead to data loss and conflicts in collaborative environments.

Conclusion:

The "Updates were rejected because a pushed branch tip is behind its remote" error in Git can be frustrating, but understanding its causes and solutions can help you overcome it effectively. By following best practices like regular pulls, communication, and cautious use of force push, you can streamline your development workflow and minimize conflicts.

References:

Git Basics: A Beginner's Guide to Branches

Tue, 11 Nov 2025 21:49:11 +0000

This article explores Git branches and their role in version control. You'll learn about team practices of creating, merging, and managing branches, gaining essential skills for collaborative projects!

What is Version Control?

Version control is a system that helps track changes to files over time. It allows multiple people to collaborate on a project, keeping a history of modifications, so you can revert to previous versions if needed. This is especially useful in software development, where teams collaborate on code, ensuring everyone is on the same page and changes are managed efficiently.

What are Git Branches?

In the context of version control, Git branches are like separate workspaces within a project. They allow you to work on different features or fixes without affecting the main codebase. Each branch can be developed independently, and once the work is complete, it can be merged back into the main branch. This system enables teams to collaborate efficiently, allowing multiple people to work on different tasks simultaneously without interfering with each other's work.

Merge Develop into the Master Branch

When working alone, you'll likely build your projects directly on the default master (main) branch. Even when you start to create individual branches, they will be made from the master branch and be merged back into it. However, when working on a team project, there is usually a development (develop) branch in addition to the master branch, and it is vital to understand how to work with them.

In my recent experience, when implementing a professional Agile workflow in my personal project, I finally understood the concept of having both a develop and master branch. Now that I was creating individual branches for each of my issues, each time I pushed to the default master branch, a deployment was triggered (though Netlify). So I initially thought, “Why am I bothering to make new branches, since I am not working in isolation?” Then I realized that is precisely what the develop branch is for. The purpose of the develop branch is to serve as an integration branch for features before they are ready for production.

In a team-based environment, once you have finished working on your individual issue branch, push and merge it into the develop branch (not the master branch). When all the individual issue branches are merged into the develop branch, yours and presumably those of fellow team members, it is the “develop branch” that gets merged into the “master branch,” which will then trigger a deployment if configured to do so. The master branch is typically the production-ready branch, which is why merging into it triggers deployment.

By following this workflow, you and other team members can confidently work on your own individual branches, contributing to the project simultaneously. Then, when all of the branches are accepted and merged into the develop branch, the team’s work will be deployed to the project once the develop branch is merged into the master branch.

Note: When working on issue branches, it is essential to follow a team-based Agile workflow, which includes testing and code review to ensure quality before merging them into the develop branch.

Make Your Issue Branch from Develop

As I am sure you know, it's crucial to pull all changes from the remote branches first to ensure all files are updated with the latest versions. If you've been working alone for a long time, it might take some time to get used to pulling changes first.

When working on a team project, you'll need to create branches to address individual issues. Generally, these issue branches are created from the develop branch rather than the master branch. So, be sure that you clarify with your team which branch to use as the base for your issue branches.

Note: To maintain consistency and avoid conflicts, it's essential to pull changes from both the master and develop branches regularly. This practice ensures that your branch is synchronized with the latest updates from the main codebase and the develop branch. By doing so, you minimize the risk of merge conflicts and ensure a smoother integration process when your work is ready to be merged back into the main branches.

Agile Development

Having covered the overall concept of working with branches, it's important to note that there are specific conventions and workflows for creating them. These conventions are often guided by Agile development principles, which emphasize flexibility, collaboration, and iterative progress in software projects —principles that my team follows.

Members of the Gridiron Survivor apprenticeship program, of which I am a part, work on individual issue branches of our current project, Elfgorithm, a Secret Santa-style gift exchange app. We use naming conventions for the branches and organize our work into Sprints, which are time-boxed periods during which specific tasks or features are developed. Each individual issue branch undergoes review and testing to ensure quality and functionality.

The naming conventions we use for branches include the programmer’s name, issue number, type (the kind of work), and a short description of the branch’s purpose:

\[YourName\]/\[IssueNumber\]-\[type\]-\[IssueDescription\]

Using naming conventions for branches enhances project organization and efficiency, allowing branches to be quickly identified and facilitating collaboration.

These conventions also improve Git automation. Scripts can recognize branch patterns to trigger actions, such as tests or notifications, resulting in reduced manual effort and ensuring consistency. Linking Sprint ticket numbers to issue branches connects the code to project management tools, simplifying progress tracking and aligning work with tasks.

Overall, structured naming conventions improve organization, communication, and workflow efficiency in software development.

Deleting with an Individual Issue Branch

Once your individual issue branch is accepted and merged into the develop, it is then safe to delete it. GitHub provides a “Delete Branch“ button for easy removal on the remote repository. You will also need to delete your issue branch in your local repository.

Once your issue branch is deleted from both the remote and local repositories, remember to pull the changes from the master and the newly merged develop branch. This ensures your local repository is up-to-date with the latest changes. Afterward, you can use git fetch --prune to clean up your local repository by removing any remote-tracking references that no longer exist on the remote.

Merge Conflicts

Dealing with merge conflicts deserves its own article, but it’s important to understand, so I will provide a brief overview.

A merge conflict occurs when Git is unable to resolve differences in code between two branches automatically. This typically happens when two team members make changes to the same part of a file. For example, imagine two team members both update the README file and change the same line. Git doesn't know which change to keep, so it flags this as a conflict.

To fix a merge conflict, you'll need to manually review the conflicting changes and decide which version to keep. Here's a simple way to handle it:

Identify the Conflict: When you try to merge, Git will notify you of the conflict and mark the conflicting areas in the file. You'll see markers like <<<<<<<, =======, and >>>>>>> indicating the different changes.
Resolve the Conflict: Open the file in a text editor and look for these markers. Decide which changes to keep or if you need to combine them. Remove the markers and ensure the file appears as you want it to.
Mark as Resolved: Once you've resolved the conflict, save the file and use git add <file> to mark it as resolved.
Complete the Merge: Finally, commit the changes with git commit to complete the merge process.

By understanding and resolving merge conflicts, you ensure that your team's work is integrated smoothly and accurately!

About Us

What is Gridiron Survivor?

Gridiron Survivor is an apprenticeship program created by Shashi Lo, a Senior UX Engineer at Microsoft. It aims to provide developers entering the tech industry with vital work experience. The program focuses on practical training in project management, coding practices, and team collaboration, offering mentorship and skills essential for success in their initial tech roles.

What is the Elfgorithm App?

Elfgorithm is an AI-driven Secret Santa app set to launch in winter 2025. It streamlines gift exchanges by removing the guesswork from Secret Santa activities. The app manages gift-giving details and provides personalized gift suggestions, ensuring you find the perfect presents for everyone.

Gridiron Survivor Sponsors

A very special thanks to our sponsors!

GitKraken: A popular Git client that provides a graphical interface to manage Git repositories. It is known for its user-friendly design and features that simplify version control, making it easier for developers to collaborate and manage their code.
Frontend Mentor: An online platform that offers front-end coding challenges. It helps developers improve their skills by providing real-world projects to work on, along with a supportive community for feedback and learning.
Vercel: A cloud platform for static sites and serverless functions. It is designed to optimize the workflow of developers by providing tools for building, deploying, and scaling modern web applications with ease. Vercel is known for its seamless integration with frameworks like Next.js.

Be sure to listen to the HTML All The Things Podcast!

I also write articles for the HTML All The Things Podcast, which you can read on their website: https://www.htmlallthethings.com/.

Be sure to check out HTML All The Things on socials!

Affiliate & Discount Links!

With CodeMonkey, learning can be all fun and games! CodeMonkey transforms education into an engaging experience, enabling children to evolve from tech consumers to creators. Use CodeMonkey's FREE trial to unlock the incredible potential of young tech creators!

With a structured learning path tailored for various age groups, kids progress from block coding to more advanced topics like data science and artificial intelligence, using languages such as CoffeeScript and Python. The platform includes features for parents and teachers to track progress, making integrating coding into home and classroom settings easy.

Through fun games, hands-on projects, and community interaction, CodeMonkey helps young learners build teamwork skills and receive recognition for their achievements. It fosters a love for coding and prepares children for future career opportunities in an ever-evolving tech landscape.

To learn more about CodeMonkey, you can read my detailed review article!

Affiliate Links:

Advance your career with a 20% discount on Scrimba Pro using this affiliate link!

Become a hireable developer with Scrimba Pro! Discover a world of coding knowledge with full access to all courses, hands-on projects, and a vibrant community. You can read my article to learn more about my exceptional experiences with Scrimba and how it helps many become confident, well-prepared web developers!

Important: This discount is for new accounts only. If a higher discount is currently available, it will be applied automatically.

How to Claim Your Discount:

Click the link to explore the new Scrimba 2.0.
Create a new account.
Upgrade to Pro; the 20% discount will automatically apply.

Disclosure: This article contains affiliate links. I will earn a commission from any purchases made through these links at no extra cost to you. Your support helps me continue creating valuable content. Thank you!

Conclusion

Version control is a system that tracks changes to files over time, enabling multiple people to collaborate on a project and revert to previous versions if necessary. In development, branches provide separate workspaces within a project, enabling the independent development of features or fixes without affecting the main codebase. In a team project, there are typically both a development branch and a master branch. The team works on the development branch, which is eventually merged into the master branch.

Individual issue branches are created from the development branch. Once a team member completes an issue branch, it undergoes review and testing as part of Agile development practices before being merged back into the development branch. These issue branches are deleted from both the remote and local repositories after they are merged to maintain a clean codebase.

When working with a team, merge conflicts happen when multiple developers change the same part of a file in different branches. You need to manually resolve these conflicts by reviewing the changes, deciding which ones to keep, and removing the conflict markers. Handling merge conflicts effectively is crucial for maintaining a smooth workflow and ensuring the accurate integration of team members' work.

Practicing is the best way to learn! Even if you're working solo, you can apply Agile workflows to your personal projects by creating, merging, and managing branches. This approach will help you develop marketable skills as you learn and implement Agile workflows!

Let’s connect! I’m active on LinkedIn and Twitter.

Why Every Developer Should Learn Git Early

Thu, 16 Oct 2025 00:26:56 +0000

Why Every Developer Should Learn Git Early

Introduction

When I started coding, I focused only on writing code that worked. But soon, I realized that writing code is just half the journey managing it is equally important. That’s when I discovered Git, and it completely changed how I approached development.

What Is Git and Why It Matters

Git is a version control system that tracks changes in your code. It allows you to save versions of your project, collaborate with others, and recover previous states if something breaks.

Whether you’re a solo developer or part of a team, Git helps you stay organized and confident in your workflow.

How Git Makes a Difference

Here’s what learning Git early taught me:

Mistakes aren’t scary anymore — you can always roll back to a working version.
Teamwork becomes easier — multiple people can work on the same project without overwriting each other’s code.
Clean progress tracking — you can see when and why changes were made.
Confidence in deployment — version history ensures that production code is safe and traceable.

Tools and Platforms That Helped Me

GitHub — for storing and showcasing my projects
VS Code + Git Integration — for smooth commit and push actions
Command Line / Terminal — for mastering essential commands like git init, git add, git commit, and git push

If you’re new, start by creating a small project and pushing it to GitHub that’s how I built my first repository, and it helped me understand how professional developers manage their work.

My Advice to Beginners

Learning Git early builds discipline and confidence. You stop being afraid of “breaking things” and start experimenting more which is exactly how growth happens.

Don’t wait until you join a team to learn Git. Start now, even if you’re coding alone.

Let’s Connect

I’d love to hear how Git has impacted your developer journey or if you’re just getting started.
Share your thoughts or connect with me on
dev.to • GitHub • LinkedIn

Signature
The Duchess of Hackers
Full-Stack Developer | Digital Marketer

Git Conventions (part 1/3)

Fri, 26 Sep 2025 14:48:55 +0000

Over the last decade or so, I have had the opportunity to experiment with various git usage strategies and styles. Ranging from branch names, to pull request descriptions, a lot of time has been spent thinking about how to best describe our work to convey as much information clearly and concisely to others. There are a wealth of strategies or style guides on how to best utilise the git ecosystem but there is no silver bullet that solves all potential scenarios. What follows is an outline of some of the rules and guides I have incorporated into my daily git life which has best worked for my team and me.

Disclaimer: This is an evolving document which has been altered and tuned over the years. It may not apply to you and your situation but perhaps there is a nugget or two here that could improve your workflow and developer happiness.

Branches

99% of the time, code changes fall into one of a handful of categories/types. When creating a new branch, naming it something clear and meaningful can help other developers know at a glance what sort of changes are been introduced. It can also simplify finding a branch using tab completion locally when jumping between branches.

Branch Types

The following branch types should suit most use cases. These can be refined or altered depending on your use case (for instance, one might not utilise the style type if they work on CLI scripts for a living)

feature - a new feature
fix - bug fixes, hotfixes, typos, etc
style - UI / UX style changes
test - adding or refactoring tests; no production code changes
housekeeping - everything from code refactoring to updating documentation
devops - updates to configuration files, software versions, etc

Branch Format

The proposed branch format will make it easy to see at a glance what type of work has been done in the branch with a clean and easy-to-read branch name. The max length of a branch name is 255 characters but where possible, I try to keep the length to no more than 50 characters for readability purposes.

type-name_of_branch

The type is separated from the branch name with a - while the rest of the name is done in snake case (words separated by _)

Alternatively, if using a task/issue tracking application, like JIRA or GitHub projects, it adds additional visibilty to include the issue/ticket number in with the branch, and using a / instead of - can aid in making the branch name a little easier to read, for example:

type/ticket#-name_of_branch

Examples branch names:

feature-add_user_authentication
fix-about_page_infinite_redirect

// or

feature/21-add_user_authentication
fix/42-about_page_infinite_redirect

Commits

Developing a structured format for our commit messages will clarify each commit's purpose resulting in a cleaner git history. At a glance, one will know if a commit is intended to add a feature, fix a bug or just improve code quality. We should aim to keep the work done within a branch small and testable, often resulting in there only being a single commit per branch, however, it's better to have lots of small atomic commits within a branch than having all the commits squashed into one before merging. This makes bisecting introduced bugs a lot easier.

Commit Message Template:

This is a sample commit template I have been using for a while now. As I try to keep my commits granular and bespoke, I define the first line leaving everything else commented out. However, if you are pushing up a commit that involves a lot of changes, perhaps references a specific issue or task item, or includes changes that could affect future development, it is recommended to flesh out the commit message with as much information as possible to help future you (or team members) get a clear picture of the work done by looking at your commit alone.

The commit subject, as seen below, has the convention of starting with the type of work being committed (bug, feature, housekeeping, etc) all in lowercase, followed by a semicolon, space and commit message, starting capitalised, in the imperative form, without any full stop at the end.

 type: [Ticket#](Optional) Summary of change

 # **--- Proposed Changes ---**
 #
 #
 # Issue / Task: [name](url)

 # --- COMMIT END --- (informational only, do not uncomment)
 # <type>: <subject> (Approx 50 characters)
 # |<----  Using a Maximum Of 50 Characters  ---->|
 # Explain why this change is being made
 # |<----   Try To Limit Each Line to a Maximum Of 72 Characters   ---->|
 # --------------------
 # Type can be
 #    feature      (new feature)
 #    fix          (bug fix)
 #    style        (UI / UX style changes)
 #    test         (adding or refactoring tests; no production code change)
 #    housekeeping (refactoring code or adding documentation)
 #    devops       (background / architecture changes)
 # --------------------
 # Remember to
 #   - Use the imperative mood in the subject line
 #   - Do not end the subject line with a period
 #   - Separate subject from body with a blank line
 #   - Use the body to explain what and why vs. how
 # --------------------

All the lines starting with a # are commented out and will not be displayed when viewing the commit message so if you intend to add future detail to your commit message, be sure to uncomment the lines necessary.

You can set up your default git commit message template with

git config --global commit.template ~/.gitmessage

Example commit messages:

feature: Add user authentication
fix: About page infinite redirect

// or

feature: [21] Adds user authentication
fix: [42] About page infinite redirect

Very often when jumping into a piece of work, I might not know right off the bat what the commit message will be as it tends to evolve as the work gets completed. In this case, I usually start my commit with something like

wip: Not sure what the issue is

and later on, once having completed the work and getting the branch ready for review, rename the commit messages appropriately during an interactive rebase (git rebase -i).

Closing Comments

This is by no means the definitive git convention standard to employ and it is something that is continually evolving and morphing as I find myself working on new and different projects. Everyone's experience is different and must be dealt with accordingly but, perhaps there are a few nuggets here that could help you guide a more structured and concise git workflow.

To further the conventions, I have also put together standard workflows, processes, and templates when it comes to GitHub Pull Requests (PR) and Issues affecting code reviews, QA testing, and deployment, but that is a story for another post.

Additional Resources

1.) A lot of the inspiration for these conventions has been taken from "Conventional Commits".

https://www.conventionalcommits.org/en/v1.0.0/#why-use-conventional-commits
https://marcodenisi.dev/en/blog/why-you-should-use-conventional-commits/

2.) A classic article on how best to write commit messages. I have gleaned a lot of the commit message advice in this article to supplement my variation.

https://cbea.ms/git-commit/#imperative

3.) A commit linting tool you can incorporate into your workflow to enforce a standard of commit messages. Can be configured in a pre-commit GIT hook.

https://commitlint.js.org/#/

GitHub Repo Security: Your Easy Go-To Checklist

Sat, 16 Aug 2025 19:41:28 +0000

Hey there! If you’re managing a GitHub repo, you know it’s more than just a place to stash code—it’s your project’s home. I’ve put together a checklist of GitHub settings to keep your repo secure and organized, sticking to the exact options you’ll see in GitHub’s interface. For each section, I’ve added a few tips to make your life easier based on what I’ve learned messing around with repos. Let’s dive in!

A. General Settings

Repository Visibility: Set to Public (if intended) or Private for restricted access.
Repository name: Keep it clear and descriptive.
Description: Add a brief description.
Topics: Add relevant topics for better discoverability.
Default Branch: Set to main (or another preferred default).
Archiving: Disable if the repo is active.

Tips:

For the repo name, think about future-proofing—something like project-v2 can avoid confusion if you iterate later.
Use topics strategically (e.g., “javascript”, “open-source”) to attract contributors searching for projects like yours.
If archiving, consider leaving a note in the README about why it’s archived and where to find active forks.

B. Branch Protection Rules

Go to: Settings → Branches → Branch protection rules → Add rule

Configure for main (or default branch):

☑ Require a pull request before merging
☑ Require approvals (at least 1-2)
☑ Dismiss stale pull request approvals
☑ Require review from Code Owners
☑ Require status checks to pass before merging (e.g., CI/CD checks)
☑ Require branches to be up to date before merging
☑ Require conversation resolution before merging
☑ Require linear history (optional but prevents merge commits)
☑ Do not allow bypassing the above settings (even for admins)

Tips:

Set up a CODEOWNERS file in your repo to auto-assign reviewers for specific files or folders.
For status checks, integrate tools like GitHub Actions or external CI/CD platforms to catch bugs early.

C. Actions & Workflows Permissions

Go to: Settings → Actions → General

Actions permissions:

☑ Allow all actions (or restrict to only verified actions if security is critical).

Workflow permissions:

☑ Read repository contents and packages permissions (least privilege).

Tip:

If you’re restricting actions, check the GitHub Marketplace for verified actions to avoid reinventing the wheel.

D. Collaborators & Teams

Go to: Settings → Collaborators & Teams

Only grant Write/Admin access to trusted contributors.
Prefer Pull Requests (PRs) over direct commits.

Tips:

Create teams for different roles (e.g., “Developers”, “Maintainers”) to streamline access management.
If you’re open-source, clearly document how contributors can request access in your CONTRIBUTING.md.
Regularly review collaborator lists to remove inactive users—trust me, it’s easy to forget!

E. Security & Moderation

Go to: Settings → Advanced Security

☑ Enable vulnerability alerts (Dependabot).
☑ Enable Dependabot security updates.
☑ Enable secret scanning (GitHub Advanced Security, if available).
☑ Enable push protection (blocks commits with exposed secrets).

Tips:

Set up Dependabot to auto-update your dependabot.yml file for regular dependency checks.
If secret scanning catches something, act fast—rotate any exposed keys and check commit history for leaks.
Consider enabling Dependabot version updates (not just security) to keep your dependencies fresh.

F. Merge Button Behavior

Go to: Settings → General → Pull Requests

☑ Allow merge commits / Squash merging / Rebase merging (choose as needed).
☑ Always suggest updating pull request branches.
☑ Allow auto-merge.

Tips:

Squash merging is great for keeping a clean history, but merge commits can help track context for bigger changes.
Auto-merge is a lifesaver for busy repos—just make sure your status checks are robust to avoid bad merges.
Encourage contributors to update their PR branches to reduce merge conflicts.

G. Issue & Discussion Settings

Go to: Settings → Features

☑ Enable Issues (if needed).
☑ Enable Discussions (optional).
☑ Enable Projects (optional).

Tips:

Use issue templates (via .github/ISSUE_TEMPLATE) to guide contributors on reporting bugs or features.
Discussions are great for open-ended ideas—pin active threads to keep the community engaged.
Projects can help you visualize workflows, but keep them simple to avoid overwhelming new contributors.

Wrapping Up

That’s the rundown! These settings and tips should help you secure your GitHub repo while making it a welcoming spot for collaboration. I’m no expert, but this setup has saved me headaches on my own projects. Got questions about any of these settings or a GitHub hack you want to share? Drop them in the comments below—I’d love to hear your thoughts and help with any setup snags!

Versioning Your API the Right Way (REST Best Practices)

Mon, 11 Aug 2025 19:28:36 +0000

When you build and maintain a REST API, change is inevitable. New features, improvements, and fixes are part of growth — but making changes without breaking existing integrations that is where the real challenge lies.
That’s where API versioning comes in.

Versioning is simply the practice of managing changes to your API without breaking existing clients. It ensures that developers using your API can keep working without disruption, while giving you the flexibility to introduce updates at your own pace.

Why Version Your API?

Backward compatibility – Prevent breaking changes for existing consumers.
Controlled rollout – Introduce new features gradually.
Clear change tracking – Developers can easily know what’s changed between versions.
Easier deprecation – Old versions can be sunset without surprise.

Common API Versioning Strategies

There are several ways to version an API. Each has its strengths and trade-offs.

1. URI Path Versioning (Most Common)

Example:

GET /api/v1/users

Pros:
- Very clear and easy to understand.
- Works well with caching and routing.
Cons:
- Can lead to duplication of routes across versions.
- URL changes when upgrading versions.

Best practice: Use for major, breaking changes. Avoid unnecessary version bumps for small non-breaking updates.

2. Query Parameter Versioning

Example:

GET /api/users?version=1

Pros:
- Easy to implement.
- URL doesn’t drastically change.
Cons:
- Less ideal for caching in some setups.
- Not as visible/explicit as URI versioning.

3. Header Versioning (a.k.a. Content Negotiation)

Example:

GET /api/users
Accept: application/vnd.myapi.v1+json

Pros:
- Clean URLs (no version in path).
- Supports multiple representations for the same resource.
Cons:
- Harder for humans to discover versioning.
- Requires clients to manage headers explicitly.

4. Media Type Versioning

Similar to header versioning, but versions are embedded in the media type format, e.g.:

application/vnd.github.v3+json

Choosing the Right Approach

Public APIs: URI path versioning is usually best — it’s explicit and developer-friendly.
Internal APIs: Header versioning or media type versioning works well when you want clean URLs.
Frequent Small Changes: Use semantic versioning within responses and documentation instead of changing the version in the URL for every update.

Best Practices for API Versioning

Follow Semantic Versioning Principles
- Use MAJOR.MINOR.PATCH format internally.
  Example: v2.1.4 means major version 2, minor update 1, patch 4.
- Only increment MAJOR when introducing breaking changes.
Document Every Version
- Maintain changelogs so developers know what’s different.
Communicate Deprecations Early
- Announce when an old version will be retired.
Avoid Version Explosion
- Don’t create new versions for minor changes — use backward-compatible updates.
Test for Backward Compatibility
- Automated regression tests help avoid breaking old clients accidentally.

Example: A Sensible Versioning Workflow

Start with v1 in the URI.
Add new, non-breaking endpoints or fields without changing the version.
When you introduce a breaking change (e.g., removing a field, changing response format), release v2.
Keep v1 live for a deprecation period while encouraging migration.

Conclusion

API versioning isn’t just about sticking a “v1” in your URL — it’s about responsible change management.
When done right, it protects both your developers and your users, allowing innovation without chaos.

Whether you choose path, query, or header versioning, the key is consistency, documentation, and communication.

PS: That’s how you version your REST API the right way.

Fixing mistakes with Git

Mon, 11 Aug 2025 19:10:50 +0000

Bob is my uncle…

He dropped his ice cream.

He didn’t know how to git.

Now he has no ice cream.

DONT BE LIKE BOB

Lucky for you I am here to share some ways to fix your mistakes on your project. This is assuming you already know git, if not read these articles:

If you are new to git, maybe start with these first:

If you prefer video: Git and GitHub for Beginners — Crash Course — YouTube

How git can fix my project?

Well, git has a full history(from the day of git init to today) of your project development. All you have to do is view the history and select the day you wanna go back and boom. This all will workout assuming you’ve named your commits properly.

You can not fix the mistakes once you pushed the changes to remote, theoretically of course. I mean you could, but it will mess up everyone else working on the branch so it is not advised not to fix something that is already on the remote unless all the contributors agree to it.

reset

git reset undo’s changes by removing the commits from the branch.

git reset --soft
git reset --mixed
git reset --hard

Each command above moves your current version of your project to the last recent version. You can go back to a specific commit by appending HEAD~n where n is the number of commits to go back.

i.e., git reset --soft HEAD~3 to go back in 3 commits.

--soft flag only moves the HEAD pointer to the commit but doesn’t affect the working directory and staged changes, meaning if you have created some files but that doesn’t exist on the older commit now it will be there because it still exists in the staging area and the working directory.

--mixed flag is the default and this moves the HEAD but it resets the staging area but not the working directory. So, if you have issued agit add . before reset it will be removed from the staging area but it will still be in the working directory.

--hard flag will do a factory reset to the specific commit. Anything and everything and between is vaporized.
Please do not do this in a public branch(a branch that is already pushed to remote) instead use the safer version revert.

You can also use git reset <filename> or git reset <commit-hash> <filename> to unstage a file without removing it from the filesystem.

revert

git revert is a safer version of undoing a commit. Revert works by finding a way to create a new commit without the changes introduced by the specified commit and appends it to the current tree.

Meaning it will not delete any commits instead it will create an inverse version of the specified commit.

git revert HEAD
git revert <commit-hash>

Unlike reset, revert requires a commit hash to act.

You can see in the above image that unlike reset it doesn’t just remove the previous commits instead creates a new commit and preserves the commits and doesn’t create problems with other branch contributors.

If revert and reset do the same which should I use?

Reset:

Don’t use it in a public branch.
Will remove all the commits after the specified commit (i.e., resetting to two days old commit will remove all the commits made in the last two days).
Use it if you are the only one using the branch or if the commits haven’t reached the remote repo.

Revert:

Use it anywhere. Afterall it just gonna look like a new commit…
Edit commit messages
Sometimes you make a silly spelling mistake in your most recent commit message and if you want to edit you can re-commit with the --amend flag. You can also add new files and use amend to update the most recent commit snapshot.

git commit --amend -m "new message that doesn't trigger your OCD"

Again, do not amend a commit that is pushed to a remote.

But the --amend the flag will only work for the most recent commit, what if you want to edit a commit message that is older than the most recent commit?

You can use rebase to change older commit messages. Rebase is also used to integrate changes from other branches just like git merge but rebase gives you finer control on how the history of the base branch should look after integrating.

git rebase -i HEAD~n n is the number of commits to go back.

This will open your default editor and show n number of commits with the work “pick” before it.

Now change the word “pick” to “reword” from the commits that you want to change the message. DO NOT CHANGE THE COMMIT MESSAGE HERE YET… Just change the word “pick” -> “reword”.

Save the file and close the editor.

Now you will get a new editor with the commit message. Change it to your new commit message and save it, then close the editor. If you have are trying to reword multiple commits, then you will get each editor windows one by one. That’s it. Remember, rebase will rewrite the history not just update the message so avoid it in remote branches.

Move a commit to a new branch

Sometimes you wanna work on a specific commit but you don’t want to mess with the main/master branch by performing a reset. For this, you can create a branch that contains that specific commit and work there and merge it later.

git branch -b fix
git checkout fix
git reset --hard <commit-hash>

Or you can do it in one line: git checkout -b fix <commit-hash>.

cherry-pick

git cherry-pick is used to pick a specific commit from a branch and place it in the current branch.

Why in the world would I do that?

You created a commit in the wrong branch. Oops.
You want to include a commit from your branch “fix_contrast” to your main/master branch but you don’t want to merge the whole branch just yet.

Checkout to your base branch where you want the picked commit to be and then issue the command.

git cherry-pick <commit-hash-from-other-branch>

This will copy that commit from the target branch to your current/base branch. This will not delete the commit on the target branch, it just makes a copy. This will have the same commit message as the target branch commit message, if you want to edit it you can use -edit the flag to rename it before cherry-picking finishes. Or if you don’t want to commit the target branch commit, use --no-commit the flag to copy only the changes to the working directory.

Even though the reset did remove the commits it looked like it left a phantom of the commits behind…

If the commits are removed then it shouldn’t have its hash right? YES and NO.

Although you reset your branch history every time you make critical actions like reset or merge git stores these actions in a special record called reference logs (aka reflog).

So, if for some reason you think you made a mistake by hard resetting a branch and if you want the commits back, you can get it back.

Issue the command git reflog and it will return the log of all critical mistakes you’ve done so far.

You can again use the git resetto get back to the previous stage but this time the syntax is a little different, git reset HEAD@{n} where n is the number shown in reflog.

And that’s it. You can fix mistakes and fix the fixed mistakes that turned out to be a mistake by themselves. Also, remember to avoid any of these operations on a public branch with multiple collaborators working on it.

There are some other ways too but I only used the above commands for the most part and I hope this article should give you an intro to cleaning up yours's and your colleges’ mess.

Git default options

Thu, 31 Jul 2025 07:54:19 +0000

Git has become a fundamental part of our developers' daily routine that it's hard to remember our lives without it. And yet, most of us use a limited set of commands and options. Today, I want to focus on two commands most developers probably use every day and look at the defaults behind them.

git push

After git commit, git push is probably the second most used command. I don't think I'll teach you anything with this excerpt from the documentation:

>git-push - Update remote refs along with associated objects

>-- Git documentation

The default options pushes the current branch to the origin remote; it assumes a branch of the same name as the local branch exists on the latter. If it doesn't exist, you need to use -u option to create it.

Also, the default assumes a single upstream named origin. If you want to push the current branch to another upstream, you need to specify it explicitly:

git push other_upstream

Likewise, the default assumes pushing to a remote branch with the same name. To push to another branch, we also must specify it along with the upstream.

git checkout my_branch
git push other_upstream master

git rebase

The default git push options are straightforward. The default ones for git rebase aren't the reason why we probably use one of them all the time.

>git-rebase - Reapply commits on top of another base tip

>-- Git documentation

Let's try the git rebase command on a simple tree:

A   B   C   D
o---o---o---o master
     \
      E   F   G
      o---o---o branch1 [HEAD]

Nothing happens. Or more precisely, "it depends"™. If we didn't set an origin remote, git complains.

There is no tracking information for the current branch.
Please specify which branch you want to rebase against.

Imagine the following remote repo:

A   B   C   D
o---o---o---o master
     \
      E   F   G   H
      o---o---o---o branch1 [HEAD]

Let's configure the remote and bind the local branch to the remote branch.

git fetch
git branch --set-upstream-to=origin/branch1

If we call rebase again, git tries to apply every commit from the remote branch, starting from the root one. Since H doesn't exist on the local branch, it just adds it to the tip of it.

Let's try with master and test again:

git rebase -i master

-i allows rebasing interactively.
Here's the proposal.

pick 5529dc4 E
pick 93af602 F
pick 7f79811 G
pick c6f853b H

As per the documentation, the command switched branch, got the commits from master, and now applies the commits in the current branch.

The result is the following:

A   B   C   D
o---o---o---o master
             \
              E   F   G   H
              o---o---o---o branch1 [HEAD]

Git is a huge beast. Most developers, including me, only use a fraction of its features. In this post, we described the default of two of the most common Git commands. I hope it sheds some light on them.

To go further:

Originally published at A Java Geek on July 27^th, 2025

Git & GitHub: Your First Steps to Version Control

Sun, 13 Jul 2025 21:32:41 +0000

Follow Me for More Content!

Before we dive into Git and GitHub, let's connect! I regularly share programming tutorials, tips, and insights:

Portfolio: abdelhakim-baalla.vercel.app
LinkedIn: abdelhakimbaalla
️ Instagram: abdelhakim.baalla
Dev.to: abdelhakim_baalla

Introduction

Have you ever worked on a project and wished you could go back to a previous version? Or maybe you're collaborating with friends on a coding project and keeping track of changes is becoming a nightmare?

Welcome to the world of version control! Today, we're going to explore Git and GitHub – two powerful tools that will revolutionize how you manage your code and collaborate with others.

Don't worry if you've never used a command line before or if terms like "repository" sound foreign. By the end of this guide, you'll understand what Git and GitHub are, why they're essential for developers, and how to use them step by step.

What is Version Control?

Imagine you're writing a book. You start with Chapter 1, then add Chapter 2, make some edits to Chapter 1, add Chapter 3, and so on. Now imagine you want to:

See what your book looked like last week
Compare two different versions of Chapter 2
Work with a co-author without overwriting each other's changes
Keep a backup of your work that's accessible from anywhere

This is exactly what version control does for your code! It's like having a time machine and collaboration tool rolled into one.

What is Git?

Git is a distributed version control system created by Linus Torvalds (the same person who created Linux) in 2005. Think of Git as a super-smart filing system that:

Tracks every change you make to your files
Lets you create different versions (called "branches") of your project
Helps you merge changes from different contributors
Keeps a complete history of your project

Key Git Concepts

Let's break down the essential Git terminology:

Repository (Repo): A folder that contains your project files and all the version history. It's like a project folder with superpowers!

Commit: A snapshot of your project at a specific point in time. Each commit has a unique ID and a message describing what changed.

Branch: A separate line of development. The main branch is usually called "main" or "master."

Clone: Making a copy of a repository on your computer.

Push: Uploading your local changes to a remote repository.

Pull: Downloading changes from a remote repository to your local computer.

What is GitHub?

GitHub is a web-based platform that hosts Git repositories in the cloud. While Git is the tool that tracks changes, GitHub is the online service where you can:

Store your repositories online
Share your code with others
Collaborate on projects
Showcase your work to potential employers
Contribute to open-source projects

Think of GitHub as Google Drive for programmers, but with powerful collaboration features built specifically for code.

Getting Started: Installation and Setup

Step 1: Install Git

For Windows:

Go to git-scm.com
Download the installer
Run the installer with default settings

For Mac:

Open Terminal
Type: git --version
If Git isn't installed, it will prompt you to install it

For Linux:

sudo apt-get update
sudo apt-get install git

Step 2: Configure Git

After installation, you need to tell Git who you are:

git config --global user.name "Your Name"
git config --global user.email "*Emails are not allowed*"

Step 3: Create a GitHub Account

Go to github.com
Click "Sign up"
Choose a username (this will be part of your GitHub profile URL)
Enter your email and create a password
Verify your account

Your First Git Repository

Let's create your first project and track it with Git!

Step 1: Create a Project Folder

mkdir my-first-repo
cd my-first-repo

Step 2: Initialize Git

git init

This creates a hidden .git folder that will track all your changes.

Step 3: Create Your First File

Create a simple file called README.md:

# My First Project

Hello, Git and GitHub!

This is my first repository.

Step 4: Check Status

git status

You'll see that Git has detected your new file but isn't tracking it yet.

Step 5: Add Files to Staging

git add README.md

Or to add all files:

git add .

Step 6: Make Your First Commit

git commit -m "Add README file"

Congratulations! You've made your first commit.

Connecting to GitHub

Now let's put your repository on GitHub so others can see it and you can access it from anywhere.

Step 1: Create a GitHub Repository

Go to GitHub and click the "+" icon in the top right
Select "New repository"
Name it "my-first-repo"
Keep it public
Don't initialize with README (we already have one)
Click "Create repository"

Step 2: Connect Your Local Repository

GitHub will show you commands to run. They'll look like this:

git remote add origin https://github.com/yourusername/my-first-repo.git
git branch -M main
git push -u origin main

Step 3: Verify the Upload

Refresh your GitHub page, and you should see your README file!

Essential Git Commands

Here are the commands you'll use most often:

Checking Status and History

git status          # See current status of files
git log             # View commit history
git log --oneline   # Compact view of commits

Making Changes

git add filename    # Stage a specific file
git add .           # Stage all changes
git commit -m "message"  # Commit with message

Working with Remote Repositories

git push            # Upload changes to GitHub
git pull            # Download changes from GitHub
git clone <url>     # Copy a repository to your computer

Branching

git branch                    # List all branches
git branch feature-name       # Create new branch
git checkout feature-name     # Switch to branch
git checkout -b feature-name  # Create and switch to branch
git merge feature-name        # Merge branch into current branch

Working with Branches

Branches let you work on different features without affecting your main code.

Creating a New Feature

git checkout -b new-feature

Make your changes, then:

git add .
git commit -m "Add new feature"
git push origin new-feature

Merging Changes

git checkout main
git merge new-feature
git push origin main

Collaboration Workflow

Here's how teams typically work with Git and GitHub:

The Fork and Pull Request Workflow

Fork the repository on GitHub
Clone your fork to your computer
Create a branch for your changes
Make your changes and commit them
Push your branch to your fork
Create a Pull Request on GitHub
The maintainer reviews and merges your changes

Basic Collaboration Commands

# Start working on someone else's project
git clone https://github.com/username/project.git
cd project

# Before starting work, get latest changes
git pull origin main

# Create your feature branch
git checkout -b my-contribution

# Make changes, add, and commit
git add .
git commit -m "Add my contribution"

# Push your branch
git push origin my-contribution

Best Practices for Beginners

Commit Messages

Write clear, descriptive commit messages:

# Good
git commit -m "Fix login button styling"
git commit -m "Add user authentication feature"

# Bad
git commit -m "fix"
git commit -m "changes"

Commit Frequently

Make small, frequent commits rather than large ones:

# Do this
git commit -m "Add header component"
git commit -m "Style header with CSS"
git commit -m "Make header responsive"

# Not this
git commit -m "Complete entire website"

Use .gitignore

Create a .gitignore file to exclude files you don't want to track:

# .gitignore
node_modules/
*.log
.env
.DS_Store

Common Mistakes and How to Fix Them

Mistake 1: Committing Too Much

# If you accidentally added files
git reset HEAD filename

# If you committed but haven't pushed
git reset --soft HEAD~1

Mistake 2: Wrong Commit Message

# Change the last commit message
git commit --amend -m "New message"

Mistake 3: Working on Wrong Branch

# Save your work temporarily
git stash

# Switch to correct branch
git checkout correct-branch

# Apply your work
git stash pop

Practical Example: Building a Simple Website

Let's walk through a real example of using Git and GitHub to build a simple website.

Step 1: Set Up the Project

mkdir my-website
cd my-website
git init

Step 2: Create Basic Files

Create index.html:

<!DOCTYPE html>
<html>
<head>
    <title>My Website</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <h1>Welcome to My Website</h1>
    <p>This is my first website tracked with Git!</p>
</body>
</html>

Create style.css:

body {
    font-family: Arial, sans-serif;
    margin: 0;
    padding: 20px;
    background-color: #f4f4f4;
}

h1 {
    color: #333;
    text-align: center;
}

Step 3: Track Your Progress

git add .
git commit -m "Initial website structure"

Step 4: Add a Feature

Create a new branch for navigation:

git checkout -b add-navigation

Update index.html:

<!DOCTYPE html>
<html>
<head>
    <title>My Website</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <nav>
        <ul>
            <li><a href="#home">Home</a></li>
            <li><a href="#about">About</a></li>
            <li><a href="#contact">Contact</a></li>
        </ul>
    </nav>
    <h1>Welcome to My Website</h1>
    <p>This is my first website tracked with Git!</p>
</body>
</html>

Step 5: Commit and Merge

git add .
git commit -m "Add navigation menu"
git checkout main
git merge add-navigation

Step 6: Push to GitHub

git remote add origin https://github.com/yourusername/my-website.git
git push -u origin main

Advanced Tips for Beginners

Viewing Changes

git diff                    # See unstaged changes
git diff --staged          # See staged changes
git show                   # See last commit details

Undoing Changes

git checkout -- filename   # Discard changes to a file
git reset HEAD filename    # Unstage a file
git revert <commit-hash>   # Undo a specific commit

Working with Remote Repositories

git remote -v              # List remote repositories
git remote add upstream <url>  # Add another remote
git fetch origin           # Download changes without merging

GitHub Features for Beginners

Issues

Use GitHub Issues to track bugs and feature requests:

Go to your repository
Click "Issues" tab
Click "New issue"
Describe the problem or feature
Add labels and assign to team members

Pull Requests

Pull Requests let you propose changes:

Push your branch to GitHub
Click "Compare & pull request"
Add a description of your changes
Request reviews from team members
Merge when approved

GitHub Pages

Host your website for free:

Go to your repository settings
Scroll to "Pages"
Select source branch (usually main)
Your site will be available at username.github.io/repository-name

Troubleshooting Common Issues

Problem: "Permission denied"

This usually means you need to set up SSH keys or use HTTPS authentication.

Solution:

git remote set-url origin https://github.com/username/repository.git

Problem: "Merge conflict"

This happens when Git can't automatically merge changes.

Solution:

Open the conflicted file
Look for conflict markers (<<<<<<<, =======, >>>>>>>)
Choose which changes to keep
Remove the conflict markers
Add and commit the resolved file

Problem: "Nothing to commit"

This means all your changes are already committed.

Solution:

git status  # Check what's happening
git push    # Maybe you need to push to GitHub

What's Next?

Now that you understand the basics, here are some next steps:

Practice Daily: Use Git for all your projects, even small ones
Contribute to Open Source: Find beginner-friendly projects on GitHub
Learn Git GUIs: Try tools like GitHub Desktop or GitKraken
Explore Advanced Features: Learn about rebasing, cherry-picking, and hooks
Join Communities: Participate in coding communities and collaborate on projects

Conclusion

Congratulations! You've just learned the fundamentals of Git and GitHub. These tools might seem overwhelming at first, but with practice, they'll become second nature.

Remember these key points:

Git tracks changes to your files over time
GitHub hosts your repositories online
Commits are snapshots of your project
Branches let you work on features safely
Pull Requests facilitate collaboration

Start small, practice regularly, and don't be afraid to make mistakes. Every developer has accidentally deleted something or created a merge conflict. The beauty of Git is that you can almost always recover from these situations.

Your journey with version control has just begun, and it's going to make you a more organized, confident, and collaborative developer. Happy coding!

Let's Stay Connected!

Found this guide helpful? I'd love to connect with you and share more programming content!

Main Links:

Portfolio: abdelhakim-baalla.vercel.app
LinkedIn: abdelhakimbaalla
Twitter: @Abdelhakim99891
Dev.to: abdelhakim_baalla

More Platforms:

GitHub: Abdelhakim-Baalla
Medium: abdelhakimbaalla50
Instagram: abdelhakim.baalla
YouTube: Dinocrafting

Community:

Reddit: Abdelhakim-Baalla430
Stack Overflow: abdelhakim-baalla
Hashnode: abdelhakimbaalla
Substack: abdelhakimbaalla

Follow me for more beginner-friendly tutorials, coding tips, and tech insights. Let's learn and grow together in this amazing world of programming!

Git Under the Hood

Sat, 28 Jun 2025 19:28:23 +0000

I decided to write a short introduction to Git — and more specifically, what’s going on under the hood. Understanding the internal mechanics of Git can help you better grasp its basic behavior and make it easier to understand commands used in everyday workflows.

Did you know that Git is fundamentally a key-value store?

In Git, the key is a SHA-1 (or SHA-256) hash, and the value is a Git object.

What is a hash?

SHA stands for Secure Hash Algorithm. It’s a family of cryptographic hash functions designed to take input data of any size and produce a fixed-size string of characters — a "digest" or "hash" — that looks like a random sequence of letters and numbers.

Key Properties of a Hash

The same input always produces the same output hash.
It’s fast to compute a hash for any given input.
Given a hash, it's computationally infeasible to reverse it and recover the original input — doing so would require an impractical amount of time and energy.
It's extremely unlikely that two different inputs will produce the same hash (this is called a collision).
Even small changes in the input result in completely different hashes.

Each Git object's hash is calculated from its content. This guarantees data integrity — meaning the content can’t be modified without changing its hash. It also enables deduplication, where identical content is stored only once.
Historically, Git has used SHA-1 hashes for its internal objects — such as blobs, trees, commits, and tags. Each object is identified by a 40-character SHA-1 hash. SHA-1 is a cryptographic hash function that produces a 160-bit (20-byte) hash.

However, due to growing concerns about vulnerabilities in SHA-1, newer versions of Git support SHA-256, a more secure hashing algorithm.

Git isn't the only tool that uses hashes — there are many other use cases for verifying data integrity. A common method is to generate a digest (hash) of a file or message and later recheck the digest to confirm that the content hasn't been modified.

For example, when downloading a file or disk image, you’ll often see a checksum (like SHA-256) provided alongside it. After the download, you can compute the digest of the file on your machine and compare it to the provided value. If they match, the file hasn't been altered.

It’s also important to remember that a digest is a one-way function: you cannot retrieve the original data from the hash.

What Are Git Objects?

Git stores all of its data as a set of objects in its internal database. These objects form the foundation of Git’s version control system.

The four main Git object types are:

Blob (Binary Large Object)

Represents the content of a file.
Stores only the raw data — not the filename or metadata.
Each version of a file’s content is stored as a separate blob.
Think of it as a snapshot of the file's content at a specific point in time.

Tree

Represents a directory.
Contains pointers to blobs (files) and other trees (subdirectories).
Stores:
Filenames
File modes (permissions)
References to blobs and other trees
Think of it as a snapshot of a folder’s structure and contents.

Commit

Represents a snapshot of the entire project at a given point in time. Points to a single tree object (the project’s root directory).
Contains metadata:
Author and committer info
Commit message
Timestamp
References to parent commits (the project’s history)

Tag

A human-readable label or bookmark that points to another Git object, usually a commit.
Can be lightweight (just a reference) or annotated (with metadata).
Annotated tags include:
Tagger name
Date
Optional message
Often used for marking releases (e.g. v1.0.0).

In practice, this is why Git tracks content, not directories. If a directory contains no files or subdirectories, Git has nothing to store — the directory itself doesn't exist in Git's object database. That's why developers often create an empty file like .gitkeep to force Git to track an otherwise empty directory.

It's also worth noting that Git does not track full file permissions. It only stores limited permission bits — mainly whether a file is executable or not (i.e., the +x bit).

Since a blob represents only the content of a file (without its name or path), you can’t retrieve the filename directly from a blob object. The filename and path information are stored in the tree object that references the blob.

This design means that two files with different names but identical content will share the same hash — and therefore the same blob. This is one of the ways Git achieves storage efficiency through deduplication.

Rewinding Time in Git: Exploring Commits & Branching

Fri, 27 Jun 2025 07:07:54 +0000

In the last story, we created a new repository on GitHub and pushed our code to the main branch. In this one, let’s rewind a bit, I'll walk you through how to look back at your development history and test new features safely using Git.

By now, you’ve probably updated your project and pushed changes quite a few times. Every commit you've made is like a snapshot, a version of your project frozen in time.

But how do you go back and look at an old version, maybe just to check a single line of code?

Most people head to GitHub -> Commits tab. But you don’t need to leave the terminal for that. Here's how you can do it right from the command line.

See Your Project’s History

git log

This shows a list of commits made by you and your collaborators. Each commit is identified by a unique 40-character SHA-1 hash. This hash acts like a version ID.

A sample log entry looks like:

commit 7abd5964ad8ef67ac20f5c52eea34e0d3bebe110
Author: hiruthicShaSS <*Emails are not allowed*>
Date: Fri Jun 25 16:42:07 2021 +0530

    Opening articles in new tab and card title fixed

That’s a lot of info! Let’s trim it down.

Get Specific Commits

Want just the last few entries?

git log -3

Want logs after a specific date?

git log --after="2021-05-01"

Combine with --before to get a date range!

Want Less Detail? Use --oneline

git log --oneline

This condenses each commit into a single line:

7abd596 Opening articles in new tab and card title fixed

To include branch and tag info too:

git log --oneline --decorate

Or if you're just looking for a human-friendly summary:

git shortlog

Enter Branches

Every Git project starts with the default main branch. But you shouldn’t develop or test directly on it. That’s what branches are for.

Check your current branches:

git branch

Let’s create a new one for development:

git branch development

But wait, this doesn’t switch to the new branch yet. To move to it:

git checkout development

Or do both in one shot:

git checkout -b development

Honestly, this is what I always use .

Why Branching Matters

Each branch is an isolated version of your code. You can try out features, break stuff, go wild, and it won't affect your main branch. When you're done and happy with your changes, you can merge it back.

If it all goes south? Just delete the branch and start over from main (just kidding, we'll talk how to fix f*ckups in git later).

Working with Git branches is like owning the Eye of Agamotto, every time you mess up, you can just rewind time and try again. Cool, right?

Until then:

Learn Git. Get fit.

Stay Curious. Adios ✌️

Understanding the basics of GIT

Thu, 26 Jun 2025 04:17:18 +0000

Git is a powerful Source Control Management (SCM) tool, and when combined with GitHub, it becomes much more than just version tracking. In this article, I'll walk you through the essential Git commands I regularly use in my projects. Let's dive in!

What is a Repository?

A repository is essentially a folder on GitHub that holds your project files. But it's more than just a folder-it comes packed with features that help track changes, collaborate with others, and manage your code efficiently.

What is a Commit?

A commit is a snapshot of your code at a specific point in time. It lets you track changes and roll back to previous versions when needed.

What is a Branch?

A branch is like a sandbox. It lets you test or add new features without affecting the main codebase. By default, the primary branch is called main (earlier known as master). You can safely experiment on other branches and merge changes when ready.

Initializing a Git Repository

To create a new Git repository for your project:

Initialize a new Git repository

git init

(Optional) Rename the default branch to 'main'

git branch -m master main

Connect your local repo to a remote one (GitHub, GitLab, etc.)

git remote add origin <your-remote-url>

Verify the remote URL

git remote -v

Boom! Your local repository is ready and connected to the remote one.

Add README.md and .gitignore

README.md

This is the face of your project on GitHub. It's a Markdown file that can include formatted text, links, images, badges, and more to explain your project.

.gitignore

This file tells Git which files/folders to ignore. You should add files like:

IDE config files
Environment variables
Secret keys
Build directories

This prevents accidentally pushing sensitive or unnecessary files to your repo.

Staging and Committing Changes

After creating your files, it's time to track and commit them:

Add specific files

git add <filename> <another-filename>

Or add all changes

git add .

Commit with a message

git commit -m "Initial commit with README and .gitignore"

A commit creates a restore point in your project. Make sure your commit messages are meaningful!

Pushing to Remote

Your code is still local. To push it to your remote repository:

git push origin main

If you're working on a different branch, just replace main with your branch name.

Wrapping Up

That's it! You've now initialized a Git repo, tracked changes, and pushed your code to GitHub. This is just the beginning. Git has a lot more to offer-branching strategies, rebasing, stashing, cherry-picking, and so on.

But we'll cover all that in the next article. Until then, happy coding!

Stay Curious. Adios

Discover software versioning, including Semantic Versioning and GitHub releases, to boost your project management skills

Tue, 13 May 2025 18:32:02 +0000

In this article, we explore versioning in software development. You'll learn about Semantic Versioning, GitHub releases, and practical steps to manage updates, enhancing your project management skills!

Versioning

Versioning in software development is a systematic method of assigning unique version numbers to different states of a software product. This practice helps developers and users track changes, improvements, and bug fixes over time.

By using version numbers, teams can efficiently manage software updates, ensure compatibility, and maintain a clear history of the software's evolution. Versioning is crucial for collaboration, as it allows multiple developers to work on the same project without conflicts and provides users with a clear understanding of the software's progression and stability.

Semantic Versioning

In versioning, particularly Semantic Versioning (SemVer), version numbers are typically structured as three-part identifiers: major, minor, and patch. Here's what each part represents:

Major Version (X): This number is incremented when there are incompatible changes that may break backward compatibility. It signifies significant updates or overhauls to the software.
Minor Version (Y): This number is incremented when new features are added in a backward-compatible manner. It indicates enhancements and improvements that do not disrupt existing functionality.
Patch Version (Z): This number is incremented for backward-compatible bug fixes. It addresses issues and errors without adding new features or breaking existing ones.

Additional characters and symbols used in versioning:

Caret (^): In dependency management, the caret symbol is used to specify compatible versions. For example, ^1.2.3 allows updates to versions that do not change the leftmost non-zero digit (e.g., 1.x.x).
Tilde (~): Similar to the caret, the tilde specifies a range of acceptable versions, but it is more restrictive. For example, ~1.2.3 allows updates to versions that do not change the middle digit (e.g., 1.2.x).
Pre-release Identifiers: These are appended to version numbers to indicate versions that are not yet stable, such as alpha, beta, or release candidate (e.g., 1.0.0-alpha).
Build Metadata: This is additional information about a build, appended after a plus sign (e.g., 1.0.0+build.1). It does not affect version precedence.

These conventions help developers manage dependencies and ensure compatibility across different versions of software.

The chart below, based on information from Wikipedia, shows how software versions are named during development stages. In early stages, like alpha or beta, a zero in the major version shows that development is still happening. Semantic Versioning uses suffixes like -alpha to show the status, while numeric status uses numbers in the sequence. The numeric 90+ scheme, used by older projects, puts a large number at the end to mark pre-releases, helping users understand how stable the software is.

Development Stage	Semantic Versioning	Numeric Status	Numeric 90+
Alpha	1.2.0-a.1	1.2.0.1	1.1.90
Beta	1.2.0-b.2	1.2.1.2	1.1.93
Release Candidate (RC)	1.2.0-rc.3	1.2.2.3	1.1.97
Release	1.2.0	1.2.3.0	1.2.0
Post-release Fixes	1.2.5	1.2.3.5	1.2.5

Releases

You'll find a section labeled 'Releases' on the main GitHub repository page for the Elecretanta project by the Gridiron Survivors team I am on. This section is where the project maintainers publish official versions of the software. Each release typically includes a version number, release notes, and downloadable assets like source code or compiled binaries.

So far, we have three release tags in the Elecretanta project's GitHub repository that show how the software has developed. These tags help track the project's progress and understand the changes made over time.

The Elecretanta project has three alpha release tags, each representing a different stage of development. The latest, 0.3.0-alpha, includes new features and improvements still being tested. The 0.2.0-alpha tag shows earlier development progress with foundational updates, while 0.1.0-alpha marks the initial release, introducing the software's basic functions. All releases are available for download in zip and tar.gz formats, and they share the same commit identifier, indicating they were part of a rapid development cycle.

Steps Taken to Update to Version 3

Our team lead, Shashi, upgraded the Elecretanta project from version 2 to version 3 during a Livestream. Although it wasn't recorded, he provided a detailed step-by-step guide on the update process, which we will now review.

Update process steps:

Create PR from develop into main.
Modify package.json version number.
Merge both changes together towards main.
Go to GitHub repo's homepage and click on Releases.
Click on Draft a new release.
Create a new tag that matches the version number.
Target is main branch.
Click generate release notes.
This will combine all the PRs that are being released into the main branch compared to the previous release notes.

Shashi followed a structured process on GitHub to update the Elecretanta project from version 2 to version 3. First, a pull request (PR) was created from the develop branch to the main branch. The package.json file was then updated to reflect the new version number. After merging these changes into main, Shashi navigated to the GitHub repository's homepage and selected "Releases." He drafted a new release, creating a tag that matched the updated version number, targeting the main branch. By generating release notes, all PRs merged into main since the last release were automatically compiled, providing a comprehensive overview of the updates.

What is New in Version 3?

In version 3 of our project, we focused on refining the codebase and enhancing the overall quality of the application. A significant portion of this release involved addressing and resolving numerous ESLint errors across various components, such as forms, alert dialogues, text areas, and avatar components. This effort was crucial in improving code quality and ensuring consistency throughout the project.

Additionally, we made some user experience improvements, like adding a "back to dashboard" link for easier navigation and ensuring that users are properly redirected to the dashboard after completing the onboarding flow. We also created unit tests for specific components, such as labels and avatar images, to enhance the reliability and maintainability of the code.

Compared to version 2, which introduced major features like the GiftExchange system and user onboarding, version 3 primarily focused on polishing the existing features and ensuring a smoother, more reliable user experience. This release also welcomed new contributors, who played a vital role in addressing these improvements and ensuring the project's continued success!

Understanding Auto-Generated Release Notes on GitHub

After our tech lead, Shashi, completed the update from version 2 to 3, he utilized a GitHub feature to generate automatic release notes. This process streamlines the creation of release notes, making it particularly effective for tracking changes and contributions. By leveraging the naming conventions of branches and pull requests (PRs), this feature automatically compiles a comprehensive overview of updates for each release.

How It Works

Branch Naming Conventions: By adhering to a consistent naming convention for branches, such as including issue numbers or descriptive titles, GitHub can link these branches directly to their corresponding PRs. This practice not only organizes the workflow but also facilitates the automatic generation of release notes.
Pull Requests and Commits: Each PR, when merged, is associated with specific commits that detail the changes made. These are often linked to issues or tasks, providing context and traceability. For example, a branch named Julianna/257-ESLint-Errors-Form indicates that the work addresses ESLint errors in a form component, linked to issue #257.
Auto-Generated Notes: When drafting a new release, GitHub can automatically generate release notes by compiling all merged PRs since the last release. This includes details such as the PR title, author, and a brief description of the changes. The notes also highlight new contributors, acknowledging their first contributions to the project.
Benefits: This automated process saves time and ensures accuracy in documenting changes. It provides a clear and organized summary of what has been updated, fixed, or added, making it easier for team members and users to understand the progression of the project.

By utilizing these features, teams can maintain a well-documented history of their project's development, enhancing collaboration and transparency!

About Us

What is Gridiron Survivor?

What is the Elfgorithm App?

Gridiron Survivor Sponsors

A very special thanks to our sponsors!

GitKraken: A popular Git client that provides a graphical interface to manage Git repositories. It is known for its user-friendly design and features that simplify version control, making it easier for developers to collaborate and manage their code.
Frontend Mentor: An online platform that offers front-end coding challenges. It helps developers improve their skills by providing real-world projects to work on, along with a supportive community for feedback and learning.
Vercel: A cloud platform for static sites and serverless functions. It is designed to optimize the workflow of developers by providing tools for building, deploying, and scaling modern web applications with ease. Vercel is known for its seamless integration with frameworks like Next.js.

Be sure to listen to the HTML All The Things Podcast!

I also write articles for the HTML All The Things Podcast, which you can read on their website: https://www.htmlallthethings.com/.

Be sure to check out HTML All The Things on socials!

Affiliate & Discount Links!

To learn more about CodeMonkey, you can read my detailed review article!

Affiliate Links:

Advance your career with a 20% discount on Scrimba Pro using this affiliate link!

Important: This discount is for new accounts only. If a higher discount is currently available, it will be applied automatically.

How to Claim Your Discount:

Click the link to explore the new Scrimba 2.0.
Create a new account.
Upgrade to Pro; the 20% discount will automatically apply.

Disclosure: This article contains affiliate links. I will earn a commission from any purchases made through these links at no extra cost to you. Your support helps me continue creating valuable content. Thank you!

Conclusion

Software versioning is a fundamental practice that allows us to track changes, manage updates, and ensure compatibility in our projects. By understanding version numbers, which consist of major, minor, and patch components, you can effectively manage software updates and monitor your project's evolution.

In our team's Elecretanta project, recently updated to version 3 by our team lead, Shashi, we focused on refining the codebase, improving user experience, and enhancing code quality. The update process utilized Semantic Versioning principles and GitHub's automatic release notes feature, simplifying the creation of release notes and helping track changes and contributions. This release also highlighted the importance of collaboration and welcoming new contributors to ensure the project's ongoing success.

By leveraging software versioning and tools like GitHub, you can keep your projects organized and efficient, encouraging continuous innovation and opportunities for success in your development efforts!

Git and GitHub for Python Developers A Comprehensive Guide

Sun, 07 Apr 2024 21:58:43 +0000

Git and GitHub play a crucial role in the workflow of Python developers, providing essential tools for version control, collaboration, and project management. In this guide, we'll explore the fundamentals of Git and GitHub and how Python developers can leverage them effectively.

Overview

We'll discuss the following subjects in this post:

Brief Explanation
Why Git and GitHub are Essential for Python Developers
Getting Started with Git
Basic Git Commands
Working with Branches
Collaborating with GitHub
Advanced Git Concepts
Best Practices and Tips
Conclusion

Now, let's delve into each topic in detail.

Brief Explanation

Git is a distributed version control system used in software development that tracks modifications to source code. It allows developers to collaborate on projects efficiently and manage codebase history effectively.

In contrast, GitHub is a web-based repository hosting platform for Git repositories. It offers additional features like issue tracking, pull requests, and project management tools, making it an ideal platform for open-source collaboration and project hosting.

Is Git useful for Python? Can Python be used with GitHub? Find out below!

Why Git and GitHub are Essential for Python Developers

Version Control: Git enables Python developers to track changes in their codebase, revert to previous versions if needed, and collaborate seamlessly with team members. A system called version control keeps track of changes made to a file or group of files over time so that you can retrieve particular versions at a later time.

Distributed Version Control: Distributed version control allows multiple developers to work on a project simultaneously. Each developer has their own copy of the repository, and changes can be merged together.

Collaboration: GitHub provides a centralized platform for Python developers to work together, review code, and manage project tasks efficiently.

Open Source Contribution: GitHub hosts millions of open-source projects, offering Python developers opportunities to contribute to various projects and enhance their skills.

Project Hosting: Python developers can host their projects on GitHub, making it accessible to the community and facilitating collaboration.

Can I run Python code on GitHub? Definitely! GitHub's support for code hosting, version control, and integrated workflows makes it an ideal platform for running and managing Python code.

What is the best git and GitHub for Python developers? Git and GitHub, without a doubt! These tools provide essential functionalities for version control, collaboration, and project management, making them invaluable for Python developers.

Real Python offers high-quality Python tutorials, articles, and resources to help you master Python programming and advance your career.

Getting Started with Git

1. Installing Git on Different Platforms

Where can you find Git and GitHub for Python developers download? Look no further than the official Git and GitHub websites, which offer downloads tailored for various platforms and provide comprehensive documentation for getting started.
To install Git on your system, follow the instructions for your respective platform:

Windows: Download the Git installer from git-scm.com and follow the installation wizard.
macOS: Install Git using Homebrew by running brew install git in the terminal.
Linux: Install Git using your package manager. For instance, use sudo apt install git on Ubuntu.

What's the significance of Git python library? The Git python library, also known as GitPython, is a valuable tool for Python developers, offering programmatic access to Git repositories and enabling automation of version control tasks.

Here's the code snippet for importing GitPython into your Python projects:

# Install GitPython package using pip
# You can run this command in your terminal or command prompt
# pip install GitPython

# Once GitPython is installed, you can import it in your Python code
import git

# Now you can use GitPython in your code to interact with Git repositories

This code snippet demonstrates how to import GitPython into your Python projects after installing the GitPython package using pip.

2. Configuring Git

Once Git is installed, configure it with your username and email:

git config --global user.name "Your Name"
git config --global user.email "*Emails are not allowed*"

This makes it clear that the configuration commands are universal and can be used on any operating system.

3. Creating Your First Git Repository Locally

To create a new Git repository for your Python project, navigate to your project directory in the terminal and run:

git init

This initializes a new Git repository in the current directory.

Figure 1: Diagram illustrating a Git Repository

Basic Git Commands

1. git init

The git init command initializes a new Git repository in the current directory.

2. git add

The command git add is used to stage changes for the subsequent commit. You can add specific files or directories:

git add file.py            # Add a specific file
git add .                  # Add all changes in the current directory

Caution: Avoid adding sensitive information such as passwords or API keys to a Git repository. Instead, make use of independent configuration files or environment variables.

3. git commit

The staged modifications are saved to the repository by using the git commit command:

git commit -m "Commit message"

4. git status

The git status command shows the status of files in the repository:

git status

5. git log

The git log command displays the commit history:

git log

6. git diff

The git diff command shows the differences between files:

git diff file.py

Figure 2: Diagram illustrating .git folder

Putting It All Together: Simple Git Workflow

Clone the repository.
Make changes and stage them.
Commit changes with a descriptive message.
Push changes to the remote repository.
Repeat steps 2-4 as necessary.
Pull changes from the remote repository to stay up-to-date.

Figure 3: Diagram illustrating Git Workflow

Aside: The Staging Area
The staging area is where changes are prepared before committing them to the repository. It allows for selective commits.

Working with Branches

1. git branch

The git branch command lists, creates, or deletes branches:

git branch                    # List branches
git branch new-feature        # Create a new branch
git branch -d branch-name     # Delete a branch

Tip: Use Meaningful Branch Names: When creating branches in Git, use descriptive names that reflect the purpose of the branch, such as feature/xyz or bugfix/123.

2. git checkout

The git checkout command switches between branches:

git checkout branch-name

Traveling Back in Time: Examining a Specific Version of Your Code

To revert your code to a previous commit, use the git checkout command followed by the commit hash:

git checkout <commit-hash>

3. Merging Branches

Merge branches using git merge:

git merge branch-name

4. Resolving Merge Conflicts

When merging branches, resolve conflicts by editing the conflicting files and then committing the changes.

Figure 4: Diagram illustrating Git branch operations

Collaborating with GitHub

What's the deal with Python GitHub? Python GitHub, a term synonymous with Python projects hosted on GitHub, offers a wealth of resources, libraries, and collaborative opportunities for Python developers.

1. Creating a GitHub Account

Visit github.com and sign up for a free account.

Note: License Your Projects: When hosting projects on GitHub, consider adding a license file (e.g., MIT, Apache) to define how others can use, modify, and distribute your code. It's an essential aspect of open-source collaboration and legal protection.

2. Setting up SSH Keys

Generate SSH keys and add them to your GitHub account for secure authentication:

ssh-keygen -t rsa -b 4096 -C "*Emails are not allowed*"

3. Pushing Local Repositories to GitHub

To push your local repository to GitHub, use the following commands:

git remote add origin *Emails are not allowed*:username/repository.git
git push -u origin master

Caution: Be Careful with Force Push: Avoid using **git push --force** (or **-f**) unless absolutely necessary. Force pushing can overwrite history and cause irreversible changes, potentially leading to data loss for you and collaborators.

4. Cloning Repositories from GitHub

Use the following to copy a repository from GitHub to your PC:

git clone *Emails are not allowed*:username/repository.git

5. Forking Repositories and Creating Pull Requests

Fork repositories on GitHub to contribute changes. Create a pull request to propose your changes for merging into the original repository.

Tip: Regularly Update Your Forks: If you fork a repository on GitHub to contribute changes, remember to regularly update your fork with changes from the original repository to avoid conflicts and stay in sync.

6. Reviewing Pull Requests and Merging Changes

Review pull requests submitted by collaborators and merge changes into the main branch after review.

Figure 5: Diagram illustrating branches created by different collaborators

7. Fetching

The git fetch command downloads objects and refs from another repository, but it does not merge them into your current branch.

Aside: What is a SHA

A SHA (Secure Hash Algorithm) is a unique identifier for a commit. It's a 40-character string that uniquely identifies a commit.

Advanced Git Concepts

1. Rebasing Commits

Rebase commits to maintain a linear commit history:

git rebase branch-name

Note: Understanding Git Rebase: While rebasing commits can create a cleaner commit history, it's important to understand that it rewrites commit history, which can cause conflicts for collaborators. Use with caution and communicate changes to team members.

2. Git Aliases

Define aliases for commonly used Git commands:

git config --global alias.co checkout

3. Using .gitignore

Create a .gitignore file to specify files and directories to ignore:

echo "venv/" >> .gitignore

4. Git Hooks

Set up Git hooks for automation tasks like running tests before commits:

nano .git/hooks/pre-commit

5. Cherry-picking Commits

Cherry-pick commits from one branch to another:

git cherry-pick <commit-hash>

What about Git-python? Git-python, a Python library for interacting with Git repositories, offers a convenient way for Python developers to automate Git operations and integrate version control into their Python projects.

Where can you find Git python examples? Git python examples abound in tutorials, documentation, and open-source projects hosted on GitHub, providing practical demonstrations of Git usage in Python development.

How do you perform git-python install? Installing git-python is straightforward: simply use pip to install the GitPython package, which provides a Python interface for interacting with Git repositories.

Best Practices and Tips

1. Writing Descriptive Commit Messages

Provide clear and concise commit messages that describe the changes made.

2. Keeping Commits Atomic and Focused

Commit small, focused changes to keep the commit history clean and understandable.

3. Using Branches Effectively

Use branches for feature development, bug fixes, and experimentation.

Figure 6: Diagram illustrating Git network graph

4. Regularly Pulling Changes

Pull changes from remote repositories frequently to stay up-to-date with the latest developments.

The git pull command fetches changes from a remote repository and merges them into your current branch.

5. Collaborating Effectively

Communicate with team members, participate in code reviews, and follow project guidelines for effective collaboration.

6. Handling Large Repositories

Optimize repository size, use shallow clones when necessary, and adopt efficient Git workflows for managing large projects.

Conclusion

In the exploration of Git and GitHub within the Python development sphere, this guide has endeavored to provide an exhaustive overview, tailored specifically towards Python developers. The utility of Git and GitHub extends beyond mere version control; it encompasses comprehensive project management, collaboration among team members, and a significant contribution to the Python community's advancement. Mastery over these tools empowers developers to manage projects with greater efficiency, collaborate seamlessly, and elevate their Python projects. The knowledge imparted here equips individuals to adeptly navigate version control systems, adopt collaborative workflows, and advance Python projects towards success. It's imperative to recognize that the journey of discovery and learning in the use of these tools is perpetual. Developers are encouraged to continually engage with Git and GitHub, enhancing their competencies and contributing meaningfully to the domain of Python development.

Coder Legion - Recent posts tagged version-control

No, Git Isn't Dead. Anthropic's Robots Just Needed a Bigger One.

Beyond the Pull Request: Why Delta Could Reframe AI Code Review

The PR problem in the age of AI

Delta’s central idea: the thread

What DeltaDB actually changes

Dogfooding the model

GitHub is still part of the picture

The bottom line

Sources

About the Author

Git & GitHub Basics Every Beginner Developer Should Know

Introduction

Git vs GitHub — What's the Difference?

Setting Up (One-Time)

The Core Workflow

1. Initialize a repository

2. Check what's changed

3. Stage your changes

4. Commit your changes

Connecting to GitHub

5. Create a repository on GitHub

6. Link your local project to GitHub

7. Push your code

Branches — Working Without Breaking Things

Pulling Changes

Common Beginner Mistakes

A Basic .gitignore for Frontend Projects

Final Thoughts

Git Branch Pinning and Auto-Archiving: What's New in Tower 13 for Windows

Branch Pinning

Fully Merged and Stale badges

Automatic Branch Management

Other changes in this release

Git Err: Updates were rejected because a pushed branch tip is behind its remote

Index:

What is this problem?

How to recreate this issue?

Example:

Error message:

What was wrong here?

Solutions:

1. Pull Changes:

2. Rebase:

3. Force Push (with caution):

Conclusion:

References:

Git Basics: A Beginner's Guide to Branches

This article explores Git branches and their role in version control. You'll learn about team practices of creating, merging, and managing branches, gaining essential skills for collaborative projects!

What is Version Control?

What are Git Branches?

Merge Develop into the Master Branch

Make Your Issue Branch from Develop

Agile Development

Deleting with an Individual Issue Branch

Merge Conflicts

About Us

What is Gridiron Survivor?

What is the Elfgorithm App?

Gridiron Survivor Sponsors

My other related articles

Be sure to listen to the HTML All The Things Podcast!

I also write articles for the HTML All The Things Podcast, which you can read on their website: https://www.htmlallthethings.com/.

Be sure to check out HTML All The Things on socials!

Affiliate & Discount Links!

Advance your career with a 20% discount on Scrimba Pro using this affiliate link!

Important: This discount is for new accounts only. If a higher discount is currently available, it will be applied automatically.

Disclosure: This article contains affiliate links. I will earn a commission from any purchases made through these links at no extra cost to you. Your support helps me continue creating valuable content. Thank you!

Conclusion

Are you now confident in managing Git branches for collaborative projects? Do you have other tips for handling merge conflicts effectively? Please share the article and comment!

Why Every Developer Should Learn Git Early

Why Every Developer Should Learn Git Early

Introduction

What Is Git and Why It Matters

How Git Makes a Difference

Tools and Platforms That Helped Me

My Advice to Beginners

Let’s Connect

Git Conventions (part 1/3)

Branches