GitHub, the Programmer's Social Network
Talk is cheap. Show me the code. - Linus Torvalds in a message to the linux-kernel mailing list on 2000-08-25
Lone Gunman
For most of my career I worked alone or in very small teams. Version control is easy when you’re on your own: any system works as long as it stays out of your way and is reasonably efficient. I’ve been programming since the 90s and I’ve been through it all, from copying the whole project into another directory, or zipping it with the date of the change, to CVS, SVN, and now Git. Of all of those, Git is by far the best balance between capability and practicality. The learning curve is gentle: with four or five commands you’re already using Git without trouble. The lone gunman days are behind me now. I work on a team, and we’re not together in the same room. We work asynchronously, and version control has to absorb that. Git’s decentralized nature helps a lot when it comes to pulling the various parts of the work together and assembling the puzzle that modern software is.
GitHub
Although I had been using git for a while, I only started using GitHub for real in early 2016; before that I had only played around with it. This past year was great. I met a lot of fantastic programmers and came into contact with many interesting projects. I learned to improve my code in the best possible way: by seeing how other programmers solved problems, talking to them, and discussing the pros and cons.
Working as a team
To work in a group you just have to follow a few simple rules: always create a branch for your changes and submit your work as a pull request (PR). That’s usually enough for most professional projects, in the sense that you were hired to make the changes and were given instructions on what to do.
Contributing to open source projects
Contributing to open source is a bit more complicated, but not much. Ideally you fork the code into your personal repository, and from there it’s the same thing: create a branch for your changes and open a pull request when you’re done.
Before contributing, read the project’s README.md and look for details on how to contribute. If it’s not in the README.md itself, it may be in a specific file such as CONTRIBUTING.md. It’s also important to read the project’s issues and discuss what you want to do there before trying to send code.
My pull request was rejected
Don’t worry if your pull request is rejected. Look at the maintainers’ comments; they usually tell you what’s missing or what you did wrong. Sometimes it’s a matter of reading the README.md or the CONTRIBUTING.md more carefully. I’ve had contributions turned down because I hadn’t read the rules properly for my contribution to be accepted. Don’t give up and don’t abandon your work.
Is my code good enough?
Sometimes insecurity keeps people from contributing. Don’t worry about the quality of your code; try to do the best you can. It’s unlikely to be turned down if you follow the project’s contribution rules. Write tests and make sure your code works, that’s the important part. Besides, you can contribute with things other than code. Documentation, for example, is something every project needs, and so is writing tests. Even reporting bugs is already a big help.
What lies ahead
More and more, my projects and those of many friends revolve around GitHub, and that number only seems to grow. Increasingly, your GitHub profile becomes your résumé.