Guidelines for Pull Request¶

Before pull request¶

Fork our monorepo
Create your branch

git branch branch-name

Make desired changes in code and follow commit message guidelines
Push to your fork

git push

1. Create pull request¶

Before creating the PR, you have to update the branch on the current master:

git fetch
git rebase origin/master

Warning

If your pull request contains any BC breaks (see Backward Compatibility Promise), it should not be targeted against the current master but against a branch where the next major release is being prepared.
E.g., if the latest release is v7.1.0 and you want to introduce a breaking change, you need to rebase your branch on 8.0 branch and target your PR against it. If no such a branch exists, you need to create one.

You have to check your change using the command php phing standards tests tests-acceptance as it’s mentioned in contributing.

Hint

In this step, you were using multiple Phing targets.
More information about what Phing targets are and how they work can be found in Console Commands for Application Management (Phing Targets)

Please make sure you sign form to agree with the license agreement.
Create a PR with essential information to make our code review easier.
- you do not have to update CHANGELOG.md at all as it is generated automatically using github-changelog-generator/github-changelog-generator during our release process.
Now, just wait for a review of your change.

Note about targeting pull requests¶

As we support multiple versions of Shopsys Platform while keeping Backward Compatibility Promise, it is important to think about proper targeting of your pull request.

If your pull request:

fixes a bug and does not contain any BC break, it should be targeted to the oldest supported version where the bug occurs.
does not contain any BC break, it should be targeted to master.
contains any BC break, it should be targeted to a branch where the next major release is being prepared.
- E.g., if the latest release is v7.1.0 and you want to introduce a breaking change, you must rebase your branch on the 8.0 branch and target your PR against it.

Note

Always rebase your branch onto the base branch before retargeting. Otherwise, your PR might contain more commits than you'd want to merge.

2. Changes after review¶

During the review, a reviewer will write comments how to improve the solution or fix bugs. CR can end in Approved or RequestChanges status when further edits are needed. After completing the CR, it is necessary to correct errors encountered by the reviewer. It would be good if you could respond to each comment so that we knew you were reading them. We use fixup commits for correcting the pull request so the reviewer can see what edits were made. Once the changes are done, the branch must be pushed. Comments to commit messages should be corrected after the fixup commit squash.

Fixup commit usage:¶

Changes which you want to add to previous commits commit independently with git commit --fixup=hash. Commit messages will be automatically completed.

Hash commit on GitHub (in right):¶

alt text

Hash in console command git log:¶

alt text

3. Approved¶

If the reviewer is satisfied with the changes, squash fixup commits.

Update the branch on the current master:

git fetch
git rebase origin/master

Squash fixup commits:

git rebase --interactive --autosquash origin/master

After squash, you just need to correct commit messages (if needed) and push it:

git push --force