Phase 1: Web Fundamentals & JavaScript

Commits, branches, merging & rebasing

Beginner ~4 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you and a friend are building an amazing LEGO castle together. It's a huge project, and you want to make sure you can always go back if you make a mistake, or work on different parts at the same time.

First, let's talk about "commits." Every time you finish a small, important part of your castle – maybe you build a strong new wall, or add a fancy flag – you take a special picture of your entire castle and write a quick note like "Added a red flag to the main tower!" This picture is like a "save point" for your project. If you ever build something you don't like, you can just look at an older picture and rebuild from there without messing up all your hard work. This helps you track exactly how your castle grows, piece by piece, and always lets you rewind if you need to.

Now, for "branches." What if you want to build a cool drawbridge, and your friend wants to design a secret dungeon, all at the same time? If you both work on the same castle, you might accidentally knock over each other's pieces! So, instead, you each make a copy of the main castle. You work on your drawbridge on your copy, and your friend works on their dungeon on their copy. These separate copies are your "branches." It means you can both experiment and build new things without affecting the main, stable castle that you know is working perfectly.

Once you've both finished your awesome additions, you'll want to bring them back into the main castle. This is called "merging." You carefully take your finished drawbridge and add it to the main castle, and your friend does the same with their secret dungeon. Sometimes, all the pieces fit together perfectly. Other times, maybe your drawbridge needs to connect exactly where your friend put a special brick for their dungeon, and you have to carefully combine them to make everything look neat and sturdy. This merging puts all your separate great ideas back into one grand, complete castle. So, when you're building digital projects, these ideas let you team up with others, try out new features safely, and keep a clear history of every step you take!

At the heart of Git is the 'commit,' your project's reliable save point. Think of a commit as a snapshot of your entire project at a specific moment in time, accompanied by a descriptive message explaining what changes you made. Every time you finish a logical piece of work – like adding a new button or fixing a small bug – you create a commit. This allows you to track your progress granularly and revert to previous states if needed. 'Branches' take this a step further, allowing you to create parallel lines of development. Instead of everyone working directly on the main code, you can 'branch off' to develop a new feature or fix a bug in isolation, without affecting the stable main branch. This is crucial for teamwork, as multiple developers can work on different tasks simultaneously without stepping on each other's toes.

Once you've completed your work on a feature branch, you'll want to integrate those changes back into the main branch. This is where 'merging' comes in. Merging combines the history and changes from one branch into another, creating a new 'merge commit' that signifies this integration. Git does its best to automatically combine the changes, but if two branches modified the same part of a file differently, you'll encounter a 'merge conflict.' Resolving conflicts involves manually telling Git which changes to keep, ensuring your codebase remains consistent. Merging is the standard way to bring completed features or bug fixes into your primary development line, making them available for everyone.

'Rebasing' is another way to integrate changes, but it approaches it differently than merging. Instead of creating a new merge commit, rebasing takes your branch's commits and reapplies them one by one onto the tip of another branch (e.g., main). The result is a cleaner, linear project history, as if you had started your work directly from the latest point of the target branch. While merging preserves the exact history of your feature branch, rebasing rewrites it to appear as a direct continuation. Developers often use rebase to keep their feature branches up-to-date with main before merging, or to squash multiple small commits into a single, cleaner commit. It's powerful for maintaining tidy histories but requires a bit more caution, especially when used on branches that have already been pushed to a remote repository.

Key Takeaways

  • Commits are snapshots of your project, tracked with descriptive messages.
  • Branches allow isolated development for features or bug fixes without affecting the main codebase.
  • Merging combines changes from one branch into another, typically creating a new merge commit.
  • Rebasing reapplies commits on top of another branch for a cleaner, linear project history.
  • These tools are fundamental for organized, collaborative software development workflows.

Code Example

bash
# 1. Start on your main branch
git checkout main

# 2. Create and switch to a new branch for a feature
git checkout -b feature/add-user-profile

# (Make some changes to files, e.g., create new file, modify existing)

# 3. Add changes and commit them on the feature branch
git add .
git commit -m "feat: Implement basic user profile page"

# 4. Switch back to the main branch
git checkout main

# 5. Merge your feature branch into main
git merge feature/add-user-profile

# 6. (Optional) Delete the feature branch after successful merging
git branch -d feature/add-user-profile

How this code works

This code demonstrates a standard Git workflow for developing new features safely and then integrating them into the main project. It starts by ensuring the repository is on the main branch using git checkout main. A new branch, feature/add-user-profile, is then created and switched to in one step with git checkout -b. The feature/add-user-profile name is a descriptive placeholder. The vital -b flag here signals to Git to create this new branch before switching to it, a common point where beginners might otherwise get an error if they omit it. After development and staging changes with git add ., a permanent record of the work is saved with git commit -m.

Once the feature is complete, the workflow switches back to main using git checkout main. The changes from the feature/add-user-profile branch are then incorporated into the main branch using git merge feature/add-user-profile. This command takes all the committed work from the feature branch and applies it to main. As an optional final step, the git branch -d command safely deletes the now-merged feature branch, keeping the repository clean while preserving the history of all changes within main.

Resources

Related Articles

Hand-picked reads to go deeper on git & version control.

Back to Full-Stack Developer Roadmap