In the open source world, different project comes with different workflow, using different medium. For instance, Linux Kernel development, use mailing list to gather patches for many developer around the world. The maintainer pick patches from developer with careful supervision. Then, they maintain release of the stable version, while Linus Torvalds himself maintain the mainline stream.
Other project, Git – a revision control system. It use same model as Linux Kernel, patches and conversations go to mailing list. With additional part, for the Continuous Integration system, it is recommended to use Github and Travis CI. Although they will reject all pull request from there.
Another example, Wget2 used Github mainly to perform collaboration (Because GNU not allowed their project to use Github, their move it to Gitlab [0]). Issues are discussed here. Pull request also getting merged here. Although, it also have mailing list to discuss issues and problems.
Here I share my experience how I contribute to open source, so my code could be merged in the project upstream. For an example, I will write several steps of my way doing Wget2 project for my GSoC 2017 application. Below are some points I follow:

Obtain Source Code

Startup procedures:

Fork project so you can modify yourself via Gitlab interface.

git clone
git remote add upstream https://[email protected]/gnuwget/wget2.git

Create an own branch for each ‘task’ you are working on and make your commits within it. When done, sync with upstream, rebase/merge and create your patches via format-patch.

Do not make changes to your branch ‘master’ - this should always reflect the original repo. This makes it easy for you to update your ‘master’ branch with changes from the ‘original/upstream’ master branch on Savannah.

Sync your Gitlab repo with upstream:

git checkout master
git fetch upstream
git merge upstream/master

Sync your ‘new-feature’ branch before generating patches:

git checkout new-feature
git rebase master
git push -f  # pushing updated tree to your Gitlab new-feature branch)

Assume ‘new-feature’ is a private branch where you can do all the dirty things that you shouldn’t on public/shared branches. As soon as your patch has been accepted, remove the branch ‘new-feature’ locally and from Gitlab.

Build the Executables

As prerequisite, install all mandatory software as listed in

Find the Problems

I usually look at Wget2 Gitlab issues pages to find issues and problems which appropriate to newcomer like me.

Make Changes to the Code

In this part, my knowledge in coding skill are truly challenged. Wget2 use C as its programming language. In my case, I just add some test based on requirements and of course with help from other contributors.

Create Pull/Merge Request

After I feel my code ready to merge, I push my commit to upstream and make a pull request from Gitlab interface.

Wait for Review

After create a merge request, I wait for feedback, criticism, suggestions, etc. from other developer.
Respond to it! and follow up with improved versions of your change. Even for a trivial patch you shouldn’t be surprised if it takes two or more iterations before your patch is accepted. This is the best part of participating in the Git community; it is your chance to get personalized instruction from very experienced peers!

Propose New Change

After getting a review, do some improvement. After all, make a new commit. Here, there is option to overwrite my existing commits or create new merge commits to keep history.

git push origin new-feature

If there is a conflict, Git will ask me to resolve the problem this. Then, try to push and merge commits. This won’t remove any existing commits. And if I don’t want to keep any commits history, I usually force to push:

git push -f origin new-feature

This is considered a little bit harmful. Before I do this, I will make sure that I know what I do. Also, forcing commits is should only do if it believed to final commits or at least near final, I should not do any more change to it. Just make sure that I don’t force push to the master branch of the project, otherwise, is safe.

Finally, after some iteration, if project maintainer agree with my changes, then they will merge it into their repository. If not, I should be take a look on my proposed changes more carefully, what could be wrong and what should be fixed. And the best of it all, I could learn a lot from the process.

[0] (