I'm crap with Git, so please bear with me, but I have a question...

Say someone sends me a PR for one of my repositories, and since that PR was made, there have been other pushes to that repo.


Day 1 --> PR added
Day 2 --> A new commit is made

If on Day 3 I decide to merge the PR, what happens to the changes that were made on Day 2?


Thanks everyone for jumping on - I love this community!

@kev Presuming the changes were pushed to the source branch on the remote repo, then they'd also be merged.

But ONLY if they were pushed to the source branch in the PR, if the changes are pushed to any other branch then they aren't.

@kev If day 2 affects something that the patch in the PR modifies, you might get a merge conflict. Otherwise it will just apply the patch.

@kev if the changes does not conflict with each other, git is smart enough to merge them together.

If there is a conflict, you will be notified, and you won't be able to merge till its rectified.

@kev Nothing. Here's some proto-ASCII art to explain.

| \
| \
| \
| PR
Nu |
\ |
\ |
\ |
o Merged version

See it has both commits in its history? Those changes are preserved.

(Also, GitHub bad.)

@kev Sometimes, a picture tells fewer words than the space it takes up.

@kev assuming there are no conflicts, git should manage merging this without your having to do so.

git uses a common ancestor commit of the two branches as a base for the merge operation

not sure if that answers your question...

@kev I've seen many projects requiring to rebase the working branch with the updated master/main and then (and only then, after solving conflicts, if present) merge to master/main.

@kriive @kev a cleaner way would be to do a merge instead of rebase since rebase rewrites history. You could create a merge commit that mergest upstream/master and origin/branch where master is the projects master branch and branch is your dev branch. This way you don't get cases where a current commit has an older timestamp than the previous. Keep in mind when doing that, you'll need to have an up to date master brach.

Rebasing an outdated PR is a preferred way to go.
Usually, it is done by the PR author.
@kriive @kev

@kriive @kev If there are any conflicts, then that's the best and in my opinion only proper way to handle the conflict. If there are none then it's maybe a question of taste, since the history will look a bit nicer if you rebase all the time.

@kev nothing happens to it if there's no conflict or the conflict is resolved properly.

@kev git merge should handle that just fine.
I'm no expert myself, but I gather it first finds the most recent common commit. Then it works to combine all the changes since then.

@kev If you are merging that PR to your master, the changes will stay. If the PR and your main branch are editing the same files, you can see some conflicts.

@1nfiniteHacks @kev This is the best explained answer (according to me).

@kev If the same line of code has not been edited previously it should merge fine. However if it has then you will have to fix the conflict manually.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.