In the beginning… It all started with the challenge of finding the best sharing and versioning environment that will best accommodate our needs for building a strong and creative community around the FinTP project. It would have to allow collaboration among a large number of scattered contributors.
Finally, out of the hat there came out our rabbit, GitHub! We have to say we were also influenced by the large number of open-source projects it hosts.

My new world vs. my old world I started using Git having a Subversion background (have been a SVN user for a short while). The first impulse was to “translate” the SVN commands into Git ones. It turned out not to be such a bright idea. In order to make the best choices it is essential to understand Git functions and what makes it different. One thing is that “committing“ no longer meant that everyone contributing to that branch will be aware of my changes within the code. Being a contributor (as opposed to a committer) I am not allowed to make direct push into the master branch, that is, the location where the FinTP source code corresponding to that project is stored. In this case, I had to fork and clone the master branch locally and just work there and commit. Once I feel like my code is ready to face the world, I get online and push my code into the initial forked branch. To announce the software maintainer that I am ready to release my code into the community, I have to initiate a pull request. The software maintainer will decide, following an interactive review session, upon merging conditions: should it be merged as such or should it be improved.

Local vs. remote repository The main idea is to allow you to work on your own, without being forced to interact with the central remote repository. Yeah, I also wondered what the heck is the remote repository? Mainly it is the single central repository of any project that serves as a hub for contributors, who may or may not access it while coding. When you clone it on your local machine, then you get, what else?, a local repository. Be careful not to overlook the corresponding documentation, usually organized as a wiki site, which will prove to be handy. Actually, this way of working (fork→clone→code→commit→push/pull request→review→merge) is what makes Git so suitable for working in FinTP projects (this is where you can find them https://github.com/FinTP). I know it may look a bit complicated, especially if you compare it to SVN, and that over pushing, pulling and merging of the same files might become annoying at times, but I guess each of them is more or less suitable under specific working conditions (SVN is easier to manage when few developers are working on the same branch and bring changes to the same source files).
I found it useful to stage only specific parts of my code, may those be urgent issues or already perfect code. The staging area is like a buffer zone where you may add the code that will get shipped away. As FinTP is still in its early stage, it is usually about the code that is ready to be integrated in the already existing one. You have the possibility to choose how to interact within projects. I personally started by trying to use solely the GitHub application to push my commits, but, after some silly commits and some conflicts that could not be solved by the application; I gave up and shifted to Git bash, although I am not a CLI fan. It is a bit hard at first, but in my opinion it is totally worth it.

Branches Another important aspect that Git provides is the possibility to make several branches both on the local and remote repository. Thus, because of our need for working in a team, we have adopted two workflows. When a team of contributors is coding on the same project we go for a centralized workflow: all members are using the remote repository as a single entry-point for all changes brought to the project. Thus, beside the master branch on the remote repository, we use a development branch in which we push changes. The development branch is merged into the master one when the contributors agree that they have a stable release. On the local repository I have a master branch, a development branch and several feature branches. The main branches of the project are master and development. The master branch contains only ‘production-ready’ states of the project, while the development branch contains the latest development changes that will be included in the next release. On the development branch, nightly or merge-triggered builds (whatever comes first) are run. That means that the build will always include the latest merges. Master merges are equivalent to a new production release and actions that come with it (version increment, build label, build on some production machines) are automated. Distributed workflows: one type of supporting branch is the ‘feature branch’. When starting developing a new feature I create a new local feature branch that will be merged into the development branch as soon as the work is complete (the code is reviewed and documented, at least by relevant comments). Currently, on the projects I contribute to, there are no remote feature branches, but I have created several local branches. One can add several other supporting branches, such as release or hot fixes branches.

Message to potential contributors Using Git is awesome and it aims at making your work as smooth as possible. It is probably one of the best tools supporting large worldwide communities sharing the same interests in a collaborative environment. For start, just fork our project and start coding. Then push your commits. As soon as you have any doubts about the best course of action you may find useful information here https://help.github.com/. Anyway, if you are a beginner eager to contribute and feel that reading is just consuming too much of your time, we will be glad to offer our support.