Collaborating within a large team presents unique challenges, especially when maintaining the health of a shared repository. This article explores how to efficiently integrate substantial branches by leveraging rebasing and commit squashing techniques, ensuring a seamless process while minimizing conflicts and preserving repository integrity.


Imagine a Team Working Together

Picture a group of people writing a book. Each person is responsible for a different chapter.

three girls holding a laptop

Let’s say:

  • Alice writes the introduction.
  • Bianca writes the main story.
  • Carol writes the conclusion.

Each of them works on their own copy of the book—these are their individual “branches.” While they work, the original book (called the “main branch”) doesn’t change. Over time, their chapters become very different from each other and the original book. To finish the project, they need to combine their chapters back into one book. This is where techniques like rebasing and merging come in.

At this stage, unifying the chapters requires a choice between two approaches: rewriting history or merging as-is.

  1. Option 1: Rewrite History (Rebase)

    By using the rebase approach, each contributor’s changes are reapplied to the latest version in a way that creates a seamless, linear history. It’s as if everyone’s contributions happened one after the other, without any branching or divergence. This approach results in a clean, straightforward narrative, making the document’s history easy to read and follow. However, rewriting history can erase the context of who made which changes first, which could obscure the story of how the document evolved over time.


  2. Option 2: Merge as-is (Merge Commit)

    Alternatively, merging combines each contributor’s version into the main document, preserving all individual branches and changes as they are. Conflicts that arise—such as different edits to the same section—must be resolved manually to ensure the document flows smoothly. This method keeps a full record of each contributor’s distinct contributions, showing exactly where and how each branch diverged. Although this approach may make the history look more complex, it’s invaluable for tracing individual changes and understanding how each person shaped the document.

In short, rebasing gives a polished, linear history, ideal for presentation, while merging provides a more detailed history that’s helpful for tracking specific contributions and investigating how the project evolved collaboratively.


Understanding the tools

Git Rebase

Git rebase is a powerful technique that allows developers to reapply or move a sequence of commits onto a new base commit, creating a cleaner, linear project history by eliminating unnecessary merge commits. This approach enhances the readability of the commit history, making collaboration smoother and easier to follow.

diagram

💡 Key Considerations

  • Use with Caution on Shared Branches: Rebase should generally be a last-resort solution, especially on active branches with multiple contributors. Rebasing shared branches can lead to confusion and conflicts as it rewrites commit history.

  • Golden Rule: Never rebase a branch that is publicly accessible or has already been shared with other team members. Rewriting history on a public branch disrupts the workflow and can complicate collaboration.

  • Prefer Merge for Active Collaboration: In cases where multiple developers are actively contributing to the same branch, merging is typically a safer option as it preserves the shared commit history without altering existing commits.

Challenges of Git Rebase

Using Git rebase is usually not recommended in team projects because it changes the commit history, which can confuse others who are working on the same code. This can lead to conflicts and make collaboration more difficult. It also makes it harder to understand why changes were made, as the context can get lost.


Git Merge --squash

The git merge --squash command combines all changes from your feature branch into a single commit on the main branch, creating a streamlined commit history without the need to rebase. This approach helps maintain a full record of project changes, reducing the complexity and potential conflicts that can come with rebasing.

💡

This is an ideal method for merging branch changes into an active development server, preserving clarity while minimizing disruption.

diagram

Benefits of Git Merge --squash

  • Streamlined Commit History: Consolidating changes into a single commit simplifies the project history, making it easy to review and maintain.

  • Full Project Context: Unlike rebasing, which can obscure the progression of individual commits, merge --squash provides a holistic view of the feature’s development.

Challenges of Git Merge--squash

While git merge --squash has many advantages, it can lead to challenges, especially when the feature branch has numerous file changes or significant time has passed since the last merge. In these cases, conflicts may arise, requiring careful resolution to ensure that the new changes integrate smoothly without impacting other developers’ work.

How Can You Solve the 100+ Branch Commits Problem?

If you find yourself with over 100 commits in a branch, you can streamline your project by following these steps:

  1. Checkout to the Main Branch and Pull the Latest Changes:
    Start by switching to the main branch (often named main or master) and fetching the latest changes from the remote repository.

    git checkout main
    git pull origin main
  2. Create a New Branch:
    Create a new branch based on your current feature branch, adding “-CLEAN” to the branch name to indicate it’s a streamlined version.

    git checkout -b your-branch-name-CLEAN
  3. Merge and Squash:
    Merge the original branch into the new branch, squashing all commits into a single commit for a more concise history.

    git merge --squash origin/your-branch-name
  4. Resolve Conflicts:
    If any merge conflicts arise, resolve them to complete the merge.

    💡 Note: This process will create a single commit containing all necessary changes, allowing you to isolate it for further use.

  5. Push the Clean Branch:
    After resolving any conflicts, push the new branch to the remote repository.

    git push origin your-branch-name-CLEAN
  6. Cherry-Pick Commits:
    Switch to the deployment branch (e.g., develop) and cherry-pick the single consolidated commit from the clean branch.

    git checkout develop
    git cherry-pick <commit-hash>
  7. Resolve Cherry-Pick Conflicts:
    If conflicts arise during the cherry-pick process, resolve them, and then push the finalized changes to the remote repository.


man celebrating

Conclusion

By implementing these strategies, you can effectively manage and streamline your branch commits, particularly when faced with the challenge of having over 100 commits in a single branch. This approach not only simplifies your Git history but also fosters better collaboration among team members.

Utilizing techniques such as merging and squashing commits helps maintain a clean and organized project structure, making it easier to track changes and conduct code reviews. Additionally, cherry-picking allows you to include only the essential changes in your deployment branch, minimizing the risk of introducing unwanted commits.

Incorporating these practices into your workflow will enhance efficiency, clarity, and maintainability in your development process, ultimately leading to smoother project management and successful releases.

Related articles