GitHub Development Flow
When developing software it’s strongly recommended that you have version control. Version control helps by providing a history of your changes as well as providing a way for programmers to work together.
Tip: If you find yourself commenting out large portions of code “just in case you need it later” consider checking in more frequently. Not only will this will keep your code neat and tidy, but you have the code in a safe location you can retrieve it from at a later date.
While there are numerous options available for source control systems, Open Source developers typically prefer GitHub. This is due to Git being designed for OSS purposes and GitHub building smoothly on top with excellent services and interfaces.
It’s absolutely amazing how much free software we have access to today. Nearly any system you can think of has at least one emulator available (often many!) and open source applications and games are plentiful. All the source code being available makes it possible to achieve ports to systems like the RS-97.
As with all things, there is a catch. If you make a fork of GPLed software and begin releasing versions of that software, the users have every right to ask for the source code. Answering every request for code can get rather annoying. The best way to get around this is to check into GitHub regularly. Keeping the code in GitHub up to date ensures that users can self-serve your latest code changes. And if they do ask, you can simply point them to your repository!
The key to being effective at this is really checking in often. Every small feature or breakpoint you add, take a quick moment to check in. Not only will this form a good habit, but it will also keep your workspace clean and make it easy to trace through previous changes.
Once your code is available, others are going to want to help. You may be focused on a performance improvement but others want the menu system improved. Thankfully GitHub makes it easy to collaborate on changes in parallel.
In this scenario, others can click the Fork button on GitHub to start working on their own branch. They know have their own place to work that won’t affect you in the slightest. They can make changes, check in, etc.
Tip: Make sure your GitHub repository stays up to date! Contributors can end up wasting a lot of time trying to upgrade significantly out of date code and may not want to start over when you finally publish the latest.
When they’re done, they can issue a Pull Request to you. A Pull Request is a small change bundle that you can review and decide to accept or reject. You can leave comments on what you’d like to see changed before you accept it (e.g. replace hardcoded values) or you can accept simply accept the change and have it automatically integrated into your code!
Tip: Try not to submit large Pull Requests. The maintainer you’re submitting to needs to review your code. The larger it is, the more time this process will take. Smaller, focused changes are more likely to get accepted. Those smaller changes also help you build a relationship with the other developer and gives you a chance to learn what their preferences are and what pitfalls you might run into.
Ever try to trace through changes in a GitHub repository but just get overwhelmed by all the .o binaries that were checked in? These files really dirty up our repositories without adding value to anyone. Worse yet, they change a lot and can really start to slow down your source control over time.
The best solution is not to check them in. That way they stay in your build environment where they belong and don’t need to darken your GitHub repository.
But how to prevent the files from getting checked in? Hand selecting files sounds like a lot of work!
Thankfully there’s a very easy solution. The .gitignore file placed at the root of your project can contains patterns of files you don’t want stored in your GitHub repository. Anything that matches these patterns will be automatically ignored when you check in.
Here’s an example file you can use as a starting point for your project.
*.o
*.a
.DS_Store
nbproject/**
**/*.ipk