Forking a Repo

In my last blog, I concluded that I may have to pick up coding again. While contemplating the coding problem, I got an request to show a demo for a mobile app. Now I doubt I can outsource that at all (Its just a demo!). So the coding decision is becoming a reality.

Even the realization didn't make it easier. I need to build a prototype and fast. Do I have time to learn python and/or java fast enough to produce a MVP to satisfy our requirements.

Well, I seem to have stumbled into a solution, Forking a Repo!, aided by the donglegate saga ;-)
Forking a repo is a legitimate techie term.

It means to take a copy of another person or group's software (repository) so as to continue development independently. There may be the intention of contributing your changes back at a later date, or the fork may represent a split or schism in the developer community, with different aims.

This will help get up to learn and get up to date faster than developing from scratch.

First of all, I have to find a good repository and one that is probably free. The most popular ones are Github and Bitbucket.
The differences between Github and Bitbucket is like choosing which Linux distro is best. And will probably not end.

First major difference is that Bitbucket offers some free private repository, while Github offers only public repository free of charge.
In term of real source management DVCS  (Distributed Version Control System), BitBucket uses Mercurial, while Github uses Git. The differences are subtle and mostly academic. git is very popular among OSS community thank to Linux Torvalds.

I am currently using both of them. Github seems more popular among open source project, (so easier to find project to fork), while I love the private repo and team collaboration efforts in BitBucket.

Both offer detailed description of the forking process. And you can also import project from either host.