3 ms·

How do you make your commit history clean and reviewable when submitting a PR? How do you keep your local branch up-to-date with upstream without a mess of merg

by 3np 5y ago

How do you make your commit history clean and reviewable when submitting a PR? How do you keep your local branch up-to-date with upstream without a mess of merge commits? I use it continuously throughout any workday, if I'm doing contributions that day. It's also a good idea to set your pull strategy to rebase, as recommended here: https://sdqweb.ipd.kit.edu/wiki/Git_pull_--rebase_vs._--merge https://sdqweb.ipd.kit.edu/wiki/Git_pull_--rebase_vs._--merg... git config --global pull.rebase true

KronisLV 5y ago
> How do you make your commit history clean and reviewable when submitting a PR? I've seen cases where people don't care in the slightest about the list of commits in any PR/MR, but instead just look at the diff view to see the code changes. At least that's how it's been in every single project that i've ever been a part of. Most also don't use rebasing at all and don't do squashing commits into a single one for that particular PR/MR either. That said, there is probably merit to using rebase and squashing as well, though many fail to see it or gain anything useful from it.
WorldMaker 5y ago
Merge commits are quite navigable. We have DAG traversal as basic interview questions all the time in this industry for multiple reasons. They are only a mess if you call it that and generally refuse to use traversal tools such as --first-parent.