Small GitHub crash course from Cocoanetics

I just read the Cocoanetics crash course on GitHub's Fork, Pull requests. For beginners, if you want to get an idea what GitHub is all about, head to Cocoanetics blog post.

How to contribute to Open Source Projects via Github

I'm not an expert at Github but I use it a lot to "consume" libraries that can be found in many high quality repositories.

Yesterday, I read a very small snippet from @cocoanetics' blog that seems to be a very good starting point to learn more about Git in general and how it can fit into a workflow of a contributor. Here is an excerpt from the post which I commented to the best of my current Git knowledge:

Generally the process to contribute to any open source project on GitHub is really simple once you did it for the first time.

1. You set up git and GitHub: you'll be able to learn more about this process by searching the web with "github tutorials" or "git tutorials".
2. You fork a project you want to contribute something: this will create a different branch, your own so you can start your own work and eventually contribute to the master.
3. You clone your fork to your local hard disk: this step is essentials as it will clone to your local machine the repository that you forked in the previous step.
4. You modify your local copy and commit the changes, providing sensible descriptions in the commit messages: changes are committed to your forked branch. See the following step.
5. You push your local clone to your online fork: so your changes becomes available on Github.
6. You create a pull request for the original master: in order to see other's changes to the repository you forked, you ask for them to be integrated into your forked branch with a pull. 
7. The owner might require some further changes, he will communicate with you via the pull request. If you respond to such e-mails they will automatically be appended to the conversion: a pull request notifies the owner (the master) of the repository of your changes.
8. Further commits you make to the branch you pushed will show up as updates to the pull request: obvious.
9. Finally when the owner is happy he can merge your changes into the master with just one button: obvious too. 

Any comments on this workflow? Feel free to share. 

Using GitHub for Mac to keep track of your libraries

If you happen to use many open sourced libraries hosted on Github's repositories for your iOS apps, then you should take a look at GitHub for Mac.

On the GitHub web site, you can watch many different repositories in order to keep an eye of what is happening with them. But, what if you use only a few of those repos and want to keep a local copy on your Mac for inclusion into your development workflow? I use GitHub for Mac for this purpose. 

Double-click on any repos to see the most recent activities on it. Hit the Changes section on the left and see what has changed between your local copy and the master on GitHub. Hit Branches to have a look at the repository's different branches then merge if you like. 

GitHub for Mac allows the complete management of repositories hosted on GitHub. As I'm not an expert, I found GitHub for Mac useful nonetheless. Download it here.

Using iRate in your app - asking for user reviews

This weekend I noticed many iOS apps are using the same kind of alert to ask the user for a review.

I started to look on GitHub and found out a very useful library called "iRate". Usage is very simple. Add the iRate.h/iRate.h to your project. Then, modify your application +initialize delegate method with the following lines of code:

These ivars have the following meaning: wait 5 days before asking a review from the user and wait for at least 10 application usage. If the user tap Remind me later, then wait 3 days before asking a review again. You can set a debug flag ON in order to bring the alert every time to do proof reading. Very nice.