Add better squash instructions #379
Conversation
akotlar
force-pushed
the
feature/better-squash-instructions
branch
3 times, most recently
from
fdcf160
to
b4f3e98
Compare
akotlar
force-pushed
the
feature/better-squash-instructions
branch
2 times, most recently
from
eaf18b9
to
1e97968
Compare
akotlar
force-pushed
the
feature/better-squash-instructions
branch
from
8bdb523
to
0c5874f
Compare
| @@ -23,7 +23,7 @@ git checkout -b feature/some_feature | |||
| git commit -a -m "Addresses issue #NNN". | |||
|
|
|||
| # Push to the remote repository, explicitly telling git that the remote repository you want to push to is "origin" (the foobar fork). | |||
| git push --set-upstream origin feature/some_feature | |||
| git push --set-upstream origin feature/999 | |||
There was a problem hiding this comment.
This no longer matches the example on line 19 - do you want it to say 999 up there as well?
| @@ -74,35 +74,63 @@ git pull upstream refs/pull/999/head | |||
| # Pull Request Etiquette | |||
There was a problem hiding this comment.
I think this section should go before 'Reviewing pull requests.' It's a little bit confusing to follow making another branch called pr_999 and then going back to the feature/999 one. Having everything grouped for what to do for one's own branch and then for someone else's work I think would be easier to follow.
| ``` | ||
|
|
||
| - This will ensure that git history remains clean, while still allowing you to commit frequently during development. | ||
| If you have already created a branch from feature/999, which was just squashed, you can bring a child branch (feature/1000) up to date by: |
There was a problem hiding this comment.
I think I would also add another subheading here, to indicate this section is just about child branches. I think the only part that really relates to etiquette is really lines 75 and 76, so maybe a subheading to indicate the different procedures would be useful. Like if line 79 had a subheading with something like 'How to maintain 1 commit per PR' for instance.
|
|
||
| This will ensure that git history remains clean, while still allowing you to commit frequently during development. |
There was a problem hiding this comment.
I think I would add some kind of wrap up statement at the end. Maybe add some kind of contact information if they have questions, that sort of thing.
|
|
||
| If you now want to squash the commits that are exclusive to feature/1000: | ||
| ```sh | ||
| # Checkout the child branch (feature/1000), and bring it up to date with the changes in the parent branch (feature/999) |
There was a problem hiding this comment.
You might want to mention or clarify that squashing of the parent is not required before this part, worded something like: Whenever you want to bring the child branch up to date
And that you'll have to resolve conflicts and commit it before continuing the procedure.
No description provided.