@jamesvandyne Great tip!
Splitting those changes into two commits will allow us to keep a better history of the system and allow our pull request to "tell a better story".
We can fix combined commits with an interactive rebase. I use PyCharm for part of this in my regular workflow at work, so rather than providing a concrete example, I'll instead summarize the procedure.
- git rebase -i origin/main (or whatever branch you rebase on to) to start an interactive rebase.
- Find the commit you want to split and mark it as "edit"
- git reset HEAD~1
- Add the files / changes for change A, commit
- Add the files / changes for change B, commit
- git rebase --continue
The "secret" is that when you edit stops the rebase after the combined commit. By resetting HEAD~1, we effectively undo that commit. But since it's a soft reset, the changes are not rolled back, just the commit. This allows us to tweak and commit individual parts separately as desired before continuing to the next commit in our branch.
Most people on my team started as junior engineers. This means, that we can not always assume any git knowledge below the surface. One of my teammates even described this as "we basically know push and pull". So I tried to have a lecture on some of the cases and how to resolve it. We do use GitHub for our main repository, so some of the things could be GitHub specific. Also we use master as our main branch with production code. Also, the examples will be given as command line code, simply because this is what I am most used to. But there are other ways to do it. Can't merge to master because of merge conflicts This is what actually started the idea for the training. Sometimes there will be merge conflict. They will block the merging to the master. Since we disable the resolving of merge conflicts inside of the Github, they need to be resolved on the local machine. And the example I mentioned resolved this by opening a new pull request.git checkout master git pull git checkout <branch name…