Hi Owen, Le 6 août 2020 à 03:19, Owen Lamb <owendl...@gmail.com> a écrit :
Wow! Thanks everyone... even if a lot of this went over my head. I've never rebased before, so I can't say what would be the better option. There are many tutorials on the Web about this, for instance [1]https://medium.com/datadriveninvestor/git-rebase-vs-merge-cc5199edd7 7c#:~:text=git%20—%20Rebase%20vs%20Merge.%20Rebasing%20and%20merging,fr om%20the%20last%20commit%20of%20the%20master%20branch%3A At any rate, my understanding is that I'll organize my commits near the end of the project to make sure everything is reviewable, correct? Yes, you will squash certain commits (concatenate them into a single commit) so that reviewers find a logical progression in your work. It is also critical that, even if the intermediate commits do not contain the whole feature, they must compile and give a usable LilyPond. This is for bisecting bugs. (It’s mentioned somewhere in the Contributor’s Guide, I can’t find the link...) Sometimes, this even means squashing all of your commits together. If that's the case, it might just be good to wait until then before I rebase and/or merge anything. Indeed, that’s what Jonas meant. The only caveat is that if master changes too much in the meantime in the same area, conflicts will be harder to solve. That said, I don’t think this particular area is evolving fast, is it? So, in the end... do it the way you prefer. Best, Jean References 1. https://medium.com/datadriveninvestor/git-rebase-vs-merge-cc5199edd77c#:~:text=git — Rebase vs Merge. Rebasing and merging,from the last commit of the master branch: