#Git Merge VS Rebase again

8 messages · Page 1 of 1 (latest)

analog ridge
#

Im not newbie to git, ive been using it for almost a decade. When collaborating with others, I'm faced with a situation where my pull request is still in progress while someone else's has been merged. In this scenario, I typically execute a pull --rebase on the "dev" branch to ensure my commits are placed on top and are aligned. Although this approach is valid in the Git realm, I'm pondering its impact on maintaining a really healthy project. While the traditional pull merge method retains the true history and safeguards comments during code review, it can potentially bloat the project's history.

I'm seeking your perspective on the matter. Would you recommend continuing with the rebase technique during local development and then merging "dev" into my branch when going through a code review? Or should I exclusively stick to the merge approach? Perhaps a blend of both methodologies based on specific scenarios would be more suitable? What are your thoughts on this?

uncut caveBOT
#

<@&987246964494204979> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#
TJ-Bot
Im not newbie to git, ive been using it for almost a decade. When collaborating with others, I'm faced with a situation where my pull request is still in progress while someone else's has been merged. In this scenario, I typically execute a `pull --rebase`

When your PR is still in progress while someone else's has already been merged, merge and rebase serve slightly different collaboration approaches:

  • Git Merge preserves history as is. When you merge the main branch into your feature branch, you get a merge commit that reflects when you integrated the latest main changes. This approach is non-destructive and keeps the chronological commit graph intact. It’s clearer for teams who want a complete record of changes and integrations.

  • Git Rebase rewrites your feature branch commits on top of the latest main branch. This creates a linear history, making it appear as if you developed on the tip of main. It’s cleaner but rewrites commit hashes, so it requires caution when collaborating (especially if others share your branch). Rebasing before merging a PR helps avoid unnecessary merge commits.

In practice, for ongoing PRs:

  • Use merge if you want to keep track of when main was integrated and maintain all branch commits as they happened.
  • Use rebase if you want to keep a clean, linear history and your workflow allows rewriting local history safely.

Your familiarity with both means the choice depends on team conventions and whether rewriting history fits your collaboration style.

Useful links:

- AI generated response using gpt-4.1-mini model
acoustic eagle
#

I never pull. I always fetch. I prefer to separate the "Oh look there's changes" from "and you're going to rebase it right now dammit"

#

I tend to keep my working in progress in a single commit I amend to, rebasing that. Then I carve up into meaningful piece for delivery if warranted - and that's only for projects using merge-commits, if they're squashing I might not even do that unless it helps the reviewer.

If the branch changes are too large for that to be practical, there's almost always a smaller piece I can deliver first.

random wyvern
#

At the end of my feature, I fetch rebase to latest.

#

That way, I can see if there is a problem and fix it one time.

acoustic eagle
#

I might do so multiple times. But it's usually fairly painless, unless I've planned poorly

analog ridge