Forking a repository allows you to freely experiment with changes without affecting the original project. Most commonly, forks are used to either propose changes to someone else's project or to use someone else's project as a starting point for your own idea.
Cloning is used to create a local copy of the repository. It takes only one command in the terminal to clone the repository.
git clone https://github.com/distributed-system-analysis/pbench.git
- Go to the issues section, to find a list of open issues.
- Select the issues you are interested to work upon based upon the labels and descriptions.
- It is a good practice to assign the issue to yourself to let others know you're working upon it.
- Follow the instructions in the README.md to setup and install pbench.
- Save your changes by creating your own local branches on git
- Follow these commands to push the changes to your branch.
git add .
git commit -m "Issue solved"
git push origin branch_name
- Commit messages should have a short description (50 - 70 characters) followed by a longer format description of the changes below if needed. You’ll also notice each line is formatted for a specific length in the longer format description. For example:
Extend auditing to incoming, results, and users
The server audit is now applied to the incoming, results, and users
directory hierarchies. Any unpacked tar ball should now be compre-
hensively checked to see that all is in the correct place.
The test-20 unit test gold file holds an example of an audit report
covering all the possible outputs it can emit. Each unit test runs
the report as well, and they have been updated accordingly.
- For more on best practices, check out this article for reference from time to time: https://www.git-tower.com/learn/git/ebook/en/command-line/appendix/best-practices
-
If there are multiple commits, squash down the commits to one
-
For more complicated commits it is appropriate to have more than one
-
Commit the changes
-
Click on New Pull Request
-
Write appropriate Pull Request Title stating the fix
-
Use present tense (ex. Fixes, Changes, Fixing, Changing..)
-
Reference the issue that the PR is fixing with “Fixes #issue_number” in the description
-
Provide a detailed description of the changes; if UI related, add screenshots
-
Make sure that the branches can be automatically merged (otherwise rebase the PR with
master
) and then click the drop down next to,Create pull request
, and selectCreate draft pull request
-
Assign the PR to yourself and add appropriate labels
-
Add "DO NOT MERGE" label if the work does not need to be merged or there is no agreement on the work yet
-
Make sure to add Milestone to the PR to mention specific release
-
Request for review once the work is ready for getting reviewed
-
Select the
Ready for Review
button to move the PR out ofDraft
mode indicating it is ready for review and merging
- Make sure to add proper details to the Issue raised
- Upload screenshot(if possible) in dashboard issues
- Apply proper labels to the Issue
- Try to actively respond to the communication in case of comments in the same issue.
- Go to Files changed and check for the fixes proposed by the Pull Request
- Check for certain general criteria:
- The PR has no merge conflicts with the base branch
- The commits are squashed into one
- There is proper indentation and alignment
- No additional lines are added unnecessarily
- The code is clearly understandable, with comments if necessary to clarify
- Do not merge the PR with
DO NOT MERGE
orWIP
label. - In case of the requirement of running the changes in the PR on the local system, follow the mentioned process:
- To fetch a remote PR into your local repo,
git fetch origin pull/ID/head:BRANCHNAME
where ID is the pull request id and BRANCHNAME is the name of the new branch that you want to create. Once you have created the branch, then simply
git checkout BRANCHNAME
-
If modification is required, then either “Request changes” or add “General comments” for your feedback
-
For more information about reviewing PR in github go through: https://help.github.com/en/articles/about-pull-request-reviews https://help.github.com/en/articles/reviewing-proposed-changes-in-a-pull-request