Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or just head straight to the command line:
git clone git@github.com:USERNAME/FORKED-PROJECT.git
Keeping Your Fork Up to Date While this isn't an absolutely necessary step, if you plan on doing anything more than just a tiny quick fix, you'll want to make sure you keep your fork up to date by tracking the original "upstream" repo that you forked. To do this, you'll need to add a remote:
git remote add upstream https://github.com/layer5io/meshery.git
("meshery" is used as the example repo. Be sure to reference the actual repo you're contributing to e.g. "meshery-linkerd").
git remote -v
Whenever you want to update your fork with the latest upstream changes, you'll need to first fetch the upstream repo's branches and latest commits to bring them into your repository:
git fetch upstream
git branch -va
Now, checkout your own master branch and merge the upstream repo's master branch:
git checkout master
git merge upstream/master
If there are no unique commits on the local master branch, git will simply perform a fast-forward. However, if you have been making changes on master (in the vast majority of cases you probably shouldn't be - see the next section, you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.
Now, your local master branch is up-to-date with everything modified upstream.
Create a Branch (doing your work) Whenever you begin work on a new feature or bugfix, it's important that you create a new branch. Not only is it proper git workflow, but it also keeps your changes organized and separated from the master branch so that you can easily submit and manage multiple pull requests for every task you complete.
To create a new branch and start working on it, perform the following flow.
git checkout master
For enhancements use feature/your_username/issue# or feature/your_username/name_of_feature
For bugs use bug/your_username/issue# or bug/your_username/name_of_bug
git branch feature/jdoe/567
git checkout feature/jdoe/567
Now, go to town hacking away and making whatever changes you want to.
Prior to submitting your pull request, you might want to do a few things to clean up your branch and make it as simple as possible for the original repo's maintainer to test, accept, and merge your work.
In the time that you've been working on your changes, if any commits have been made to the upstream master branch, you will need to rebase your development branch so that merging it will be a simple fast-forward that won't require any conflict resolution work.
git fetch upstream
git checkout master
git merge upstream/master
git checkout feature/jdoe/567
git rebase master
Now, it may be desirable to squash some of your smaller commits down into a small number of larger more cohesive commits. You can do this with an interactive rebase:
git checkout
git rebase -i master
This will open up a text editor where you can specify which commits to squash.
Instructions on How to Sign Off Commits to Meet the Developer Certificate of Origin (DCO) Requirements
Contributors to this project are required to sign off on their commits to comply with the Developer Certificate of Origin (DCO). The DCO is a simple statement that you, as the contributor, have the legal right to make the contribution.
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file.
(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me.
(c) The contribution was provided directly to me by some other person who certified (a), (b) and I have not modified it.
(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
How to Sign Off on Your Commits
To add the required sign-off to your commits, follow these steps:
-
Ensure Git is Configured with Your Name and Email
Your Git configuration must have your correct name and email address, as they will be used to generate the sign-off message. To configure Git, run the following commands:
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
-
Use the -s or --signoff Option in Your Commit
When making a commit, you must use the -s or --signoff option to add the sign-off line. This will append the following line to your commit message:
Signed-off-by: Your Name <your.email@example.com>
Example of a signed-off commit:
git commit -s -m "Fixing issue with Meshery module"
This ensures that your contribution complies with the DCO.
-
Verify Your Sign-Off
To verify that your commit has the sign-off, you can inspect your commit log:
git log -1
The last commit should contain a Signed-off-by line that matches your name and email.
-
Amending a Commit Without Sign-Off
If you've already made a commit but forgot to sign off, you can amend the commit with the sign-off using the following command:
git commit --amend --signoff
This will add the sign-off to your previous commit.
Once you've committed and pushed all of your changes to GitHub, go to the page for your fork on GitHub, select your development branch, and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to GitHub. Your pull request will automatically track the changes on your development branch and update.