GitHub is an incredibly effective way to collaborate on development projects -track files -push.
One of the most important things to understand when getting started with collaboration on open-source projects, is to recognize your role. Often, there are plenty of things you as a developer can do that don’t involve being an extremely clever programmer. In fact, fear of being an inadequate programmer is often the reason why people don’t get in open-source projects to begin with.
Instead of trying to fix a major bug; or rewriting an entire module, try finding things like documentation inadequacies or cross device testing and patching or even simple syntax errors and grammar issues.
This kind of tasks are good way to get your foot in the door as a contributor to the project without trying to take more than you can handle.
Learn the ecosystem of the project
Don't be afraid to start small.
With any collaborative effort, a set of conventions has probably been adopted. This may include a vocabulary set, a way of contributing and formatting commit messages, a certain rhythm of collaboration, that the contributors have agreed to, or even syntactic standards that have been established.
Before you try to get involved with a project, read all the document related to these things. For instance, GitHub has standardized a CONTRIBUTING .md file. These guides are maintained by the people who also maintain the codebase and the master branch.
Another way of understanding the ecosystem is to simply look at the existing codebase and the Git log. Reading through the commit messages and perusing the code style can tell you a lot about a project. Read through the project’s documentation, and adopt the vocabulary used to that your contributions maintain continuity and portray a similar voice.
Once you’re part of the project’s cultural ecosystem, how do you actually contribute code?
The pull request work flow for code contribution.
The work flow for contributing code can seem daunting at first. The most important thing to remember is to follow the patterns and standards outlined by the project you are working on. The general work flow that git hub supports is fairly simple.
- Fork the repo to your own account.
- Clone the repo to your local machine.
- Check out a new ‘’topic branch’’ and move changes.
- Push your topic branch to your fork.
- Use the diff viewer on git hub to create a pull request via a discussion.
- Make any requested changes.
- The pull request is then merged(usually, to the master branch) and the topic branch is deleted from the upstream(target) repo.
P.S: Found this in one of my Jotnotes. f you have valuable materials to recommend in references on this topic, do drop.
Top comments (0)