Assuming "H" is the hash of the current state of the repository content, consider this initial state of the repository (most recent first):
H(3) Implement feature B
H(2) Implement feature A
H(1) Initial commit
Now you implement "shiny feature", so your history in your branch looks like this:
H(5) Shiny feature, improvements.
H(4) Shiny feature, initial implementation.
H(3) Implement feature B
H(2) Implement feature A
H(1) Initial commit
You tested H(4) and H(5), and everything looks good.
Then you `git pull --rebase`, and your history looks like this:
H(10) Shiny feature, improvements.
H(9) Shiny feature, initial implementation.
H(8) Pulled commit C
H(7) Pulled commit B
H(6) Pulled commit A
H(3) Implement feature B
H(2) Implement feature A
H(1) Initial commit
You test H(10) because it's the current state of your repo, looks good, and merge (or create PR, whatever).
With the usual pull request flows, `H(9)` (i.e. anything between your new "base" and your most recent commit) usually stays untested, entirely ignored by the developers, and you would only ever find out if you ever need to bisect.
Not usually a problem, unless you have a rule of "every commit should be verified/tested" and the untested commits have a change that doesn't prevent a build but still causes issues (e.g. something that's only visual, or a new config file was added to a "conf.d" directory and its presence changed some behavior, stuff like that).
To avoid this you can squash H(9) and H(10) before pushing to a shared branch, this way only one tested commit will be added on top of existing commits.
Assuming "H" is the hash of the current state of the repository content, consider this initial state of the repository (most recent first):
Now you implement "shiny feature", so your history in your branch looks like this: You tested H(4) and H(5), and everything looks good.Then you `git pull --rebase`, and your history looks like this:
You test H(10) because it's the current state of your repo, looks good, and merge (or create PR, whatever).With the usual pull request flows, `H(9)` (i.e. anything between your new "base" and your most recent commit) usually stays untested, entirely ignored by the developers, and you would only ever find out if you ever need to bisect.
Not usually a problem, unless you have a rule of "every commit should be verified/tested" and the untested commits have a change that doesn't prevent a build but still causes issues (e.g. something that's only visual, or a new config file was added to a "conf.d" directory and its presence changed some behavior, stuff like that).