Unlike most open source projects, Git itself does not accept code contributions via Pull Requests. Instead, patches are submitted to the Git mailing list for review and will be applied manually by the Git maintainer.
Apart from lacking the convenience of a web interface, this process also puts considerable demands on the code contributions: the mails are expected to be plain text only (no HTML!), for example, and the diffs embedded in the mails must apply cleanly (no whitespace changes!), among other things.
A few tutorials out there try to help with this process (e.g. Git for Windows' detailed instructions how to contribute patches to the Git project). GitGitGadget tries a different approach: allow contributing patches to the Git project itself by opening a Pull Request at https://github.com/gitgitgadget/git and let GitGitGadget prepare and send the corresponding mails.
So you cloned https://github.com/git/git and implemented a bug fix or a new feature? And you already pushed it to your own fork? Good, now is the time to direct your web browser to https://github.com/gitgitgadget/git and to open a Pull Request. Please make sure to use a descriptive Pull Request title and description; GitGitGadget will use these as the cover letter. You will also want to read Git's guidelines to make sure that your contributions are in the expected form.
The first time you use GitGitGadget, you need to be added to the list of users with permission to use GitGitGadget (this is a very simple anti-spam measure). Any user who is already on that list can do that, by adding a comment to that Pull Request that says /allow <username> (with your GitHub login name).
The Pull Request will trigger a few Checks, most importantly one that will build Git and run the test suite on the main platforms, to make sure that everything works as advertised.
Once everything is ready to go, add a comment to that Pull Request saying /submit. This will trigger GitGitGadget (you can see the progress via the Check called "GitGitGadget PR Handler"): it will wrap your Pull Request into a nice bundle of mails in the format expected on the Git mailing list.
The patches will be reviewed by volunteers (be gentle...) and you will most likely receive helpful comments. The Git developer community is globally distributed, so please wait a day or two for reviewer comments to trickle in before sending another iteration of your patch series (if needed).
In the case that a reviewer asks for changes, you should respond either acknowledging that you will make those changes or making an argument against the requested changes. If your patches need to be revised, please use git rebase -i to do that, then force-push, then update the description of the Pull Request by adding a summary of the changes you made, and then issue another /submit.