The Open Source UA pull request is an important concept in collaborating with others' on GitHub. When you finish work and you want to share it with the project's owner, you issue what is called a "pull request".
This is you asking the project maintainer to review your contribution and pull it into the main git repository. Each project has their own requirements in order to accept the pull request.
Please see the contribution documentation for your target project for details.
In most established open source projects, you should find some sort of information regarding contributing to that given project. This could be called contribute.md or CONTRIBUTING.md or is simply a section in the repository's Readme file.
If you intend to contribute to a specific open source project, ensure that you follow that projects' "contribute". Most project maintainers won't accept your pull request unless you do.
For example, here's the contributing guidelines for Nightwatch -- a project I hope to cover in the near future.
https://github.com/nightwatchjs/nightwatch/blob/master/CONTRIBUTING.md
Here's a subset of their document with regards to submitting a pull request:
Follow the usual git workflow for submitting a pull request
- fork the project
- create a new branch from master (e.g.
features/my-new-featureorissue/123-my-bugfix)- If you're fixing a bug also create an issue if one doesn't exist yet
- If it's a new feature explain why do you think it's necessary
- ...
- ...
- Do not include changes that are not related to the issue at hand
- Follow the same coding style with regards to spaces, semicolons, variable naming etc.
- Add tests - after all this is a testing framework
There are common tools and concepts used in open source. Because this site is aimed at getting folks in to open source, it's occurred to me that a post to at least introduce you to related tools and give you a primer.
Of course, if you search individual for these tools, there'll be a lot better tool-specific write ups then I could ever do. But, this should act as a basic primer and launching pad to get started with these tools. At the end of each description, you'll find a source for more information.
Note: This article is still undergoing minor revision and additions but I felt it was complete and useful enough to publish now
git is a principle tool very commonly used in open source. There are other tools used, depending on the site used and the preference of the author but it's fair to say that git is far and away the most popular right now.
There are several ways to install git but following are probably the most common.
I'll cover basic usage in a fourth coming article but meanwhile, know that it exists and you'll likely need it to work with open source. (Although, do know that you can download and view open source without using git at all)
Github is a separate and distinct service from git although, the two almost always go hand in hand. There are alternative to github such as bitbucket.org and gitlab but I expect that most open source we explore on this site will be on github.
So, what is github? The service bills itself as social coding platform and I'd say they achieve that objective.
At its core, github is a place to publish your source code and then collaborate with others on it. They provide a few tools to facilitate this such as in-browser source code viewing, the wiki, the issues list and the concept of "pull requests". At it's core, all tools are designed to provide friendly, productive collaboration.
Unit testing is not a product but a software engineering concept. In open source, different users are making various changes to a given code base. One developer doesn't necessarily know the purpose, expected or possible input or the output of a given component (unit) of software and therefore could accidentally change it in a manor that introduces bugs elsewhere. These bugs may ever surface in manual testing because you'd need to know to look for them.
Unit tests help prevent this; they allow you to implement an automatic test to verify that a component works and more importantly, keeps working as intended.
Any time you are changing open source source code, you're going to be running these tests dozens and dozens of time. When I cover OSS for an article, I'll discuss running the associated tests.
Continuous Integration, like unit testing, is not a product but a software engineering concept. The high level purpose is to automate the process of taking the source code, compiling/building it3, running the unit tests as well as others and providing a report to the author and team.
This occurs when a contributor (you) makes a change to the codebase and request the the author includes the contributed change in the main code base (pull request)
Similar to git, there is a dominate product in the github world called travis-ci. This product is "10000% free" for open source project with awesome integration with github. Therefore, it's quite ubiquitous.
My favorite but I wish it worked on Linux. ↩
Git for the CLI does exist but there are different flavors. The detail are beyond this article but if you choose the CLI for Windows, bear this in mind. ↩
Even non-compiled languages such a JavaScript and Python commonly go through a build process which might include compressing the code and/or linting it ↩
I found myself in a situation where I needed to list all of the global npm packages I had installed on a (windows) server. The command, it turned out, was quite simple:
npm ls --global
npm ls itself will list the packages installed locally which can be helpful unto itself.
Then, slightly related is that I needed to remove a select global package which is easy enough.
npm uninstall --global package-name
I'm pleased that you've found this blog as quickly as you did. Unfortunately, content is quite limited right now.
I invite you to check out the about page to see what this blog and website is all about. Meanwhile, I kindly but regretfully ask that you check back later. Life, sadly, gets in the way of writing and software engineering