Managing multiple branches #15
Conversation
There was a problem hiding this comment.
In this case, where you have interdependent branches, I would argue that the second task was started prematurely. Instead, it should have been started only after the first task was complete.
If you have two completely independent tasks, this workflow is much more straight-forward
Co-authored-by: Pat McBennett <[email protected]>
Co-authored-by: Pat McBennett <[email protected]>
Co-authored-by: Aaron Coburn <[email protected]>
|
I've redone this for the simpler workflow and included the rebase steps. Please confirm I have it right when you go back to work on task2 after PR#1 has been merged. Thanks for all the input - it really helped me clarify things. I was trying to cope with dependent branches but I now see why that is so worth avoiding! |
|
Just a general comment on line length in this MD file - I try and keep lines below 100 characters (i.e., I set an editor ruler in my IDE). Generally I find it's much easier to review shorter lines (especially if reviewing in GitHub from your phone), and comments and suggestions can be more specific. |
|
Sorry - just saw the line length comment after a commit. I happened to improve a couple but wasn't trying very hard as it seems you cannot avoid long lines in tables. If you break a line you break the table. |
edwardsph
force-pushed
the
feat/workflow-notes
branch
from
25851e3 to
10132bc
Compare
Having spent too long working on solo projects I've been tripped up by the branch/PR workflow more than once. I thought it might be useful to make some notes and offer them as an addition to this documentation. However, you can see that I haven't even worked it all out so would need some help from others.