Vous pouvez naviguer parmi les posts en glissant votre doigt.

How I became Github actor

7th September 2016 . category: code .


I know Github since a long time because I’ve been using it as a consumer: I take code and use it in my projects. I always had the sensation a one-way relationship couldn’t last, as with women (if you steal too many code lines from a woman, she might become angry).

Now with the experience I got from my use of Github, I notice that the initial good wills faded. As for any phenomenon, Github lives, and it has the particularity of mixing commercial, educational and technological cycles, each one of them having their pros and cons.

  • educational cycles will allow noobs to discover Github as a user, and, for some of them, to share their innovations. Among these, some of them will be updated by their creator or, for the luckiest, by the community which would have join;
  • technological cycles makes this technology obsolete or put the lights on that one. For example, if Github existed in the early 2000’s, I’m not sure Javascript projects would have been successful. Actually, it may have been the spreading of Javascript projects on Github that made the browsers adapt.
  • commercial cycles will emphasize this or that technology. Except if you’re naive, you know that if a company invests in a technology, its interest is to undermine its competitors and keep the most knowledge on the chosen technolgy, even if it means obfuscation, thus meaning than regardless the “open source” side, a user would spend more efforts than necessary to handle it. This is a reminder of Linus Torvald’s words, when he said he disapproved of code complexity in Linux related projects. Generally, a good code is not a complicated one, but I’ll get back on it in another article.

These three cycles, which I’ll also be detailing in another article, have for consequence that a lot of “dead” (i.e. not maintained) projects remains on Github, and other projects that I consider as obsolete are maintained because such company would have made the choice of it, and want to minimize its investments (like with a hackathon, allowing to get a lot of quality code given by young developers for the price of a little Redbull and pizza. ROI to the max!).

I’m in!

That’s why I decided to enter the marvelous world of Github as a contributor, after some hesitations. Indeed: for me, before being part of it, I thought that published codes on Github were the fruit of the hard work of the best developers of the world and that, with all humility, I hadn’t my place. Then, thanks to work, I was abs to discover collaborative projects (I installed a Continuous Integration Platform, had to managed a team of several personalities, etc.), and I understood that what made Github strong wasn’t the mountains that were pushed, but the stones being put by everybody. Watching it more closely, in the hidden part of Github, I saw that there were a lot of average developers, and even more bad ones. Phew, I wouldn’t be the worst, so I can dive in!

But what to begin with? I have a lot of codes I’m working on solo, and a project I left behind me for too long was tickling me: my personal website. I read in a GNU/Linux magazine an article talking about Jekyll. I was used to PHP/MySQL, as a lot of people, and I chose to discover this new technology. I found an interesting Jekyll template, {Personal}, so I used it and made some tests. I noticed that the deployment of Jekyll websites could be improved compared to what the official webpage describes. So I offered on Github my solution (which is the subject of the firest publication of my website). I also noticed that {Personal} could be improved with the correction of some lines and the addition of new functionalities. I forked the repo and asked for pull requests.

My first pull requests were very bad: I commited changed on my master, and some pull requests mixed functionalities I wanted to split. It was not an industrial process (again, I was discovering). I wisely closed these pull requests and decided to write down my Github contribution policy, which I’ll describe now (at last!).

My Github usage

My projects

For my projects, it’s pretty simple (and this part will be very short): I simply push on Github everytime I’m happy with my code. For the moment, nobody asked for a pull request on my projects, but I think I’ll watch for useful contributions and accept everything that will:

  • simplify the code (in terms of execution or maintainability);
  • add interesting functionalities;
  • allow a better code integration.

If a pull request asks for a modification of the spirit of my code, I’ll refuse it.

Others’ projects

Here is the most interesting part of the post: I will explain how I work on Github with projects I’ve forked.

When I see a project I use and whose code I may edit, I fork it in my repo, and I immediately create a new branch: master_source. This branch will be along the time the perfect copy of the master of the project forked, regardless the modifications of my master, because I want to be able to make pull requests on the source project.

Let’s say I work on two functionalities (1 & 2). I create a branch for each one, and I submit two pull requests, each functionality being seperated, thus making the lines being more understandable by the owner of the source project, who doesn’t have to read a unique pull request to distinguish 2 functionalities. I now have 4 branches on my personal repo:

  • master, containing my version of the code (my fork);
  • master_source, containing the original code version (the source);
  • B1, containing the modifications of master_source making it include the functionality 1. I make a pull request on the master of the source repo;
  • B2, containing the modifications of master_source making it include the functionality 2. I make a pull request on the master of the source repo;

I had the good suprise that when I pushed on the branch being the object of a pull request, the pull request was being actualized. You don’t have to make another pull request, and that’s very confortable. It’s possible to launch the bases of a new functionality and improve it little by little, waiting the owner of the original repo to review it.

For every pull request, three options:

  • the branch is accepted without major changes: the master branch of the source repo is actualized, and I’ll copy it in mymaster_source. If my master and master_source are the same, I also actualize my master (this is the case if only I’ve never had any of my pull requests refused);
  • the branch is not accepted: the changes interested me, so I keep them in my master branch. It’s on this branch that I’ll be working personally. Everytime I’ll add a new functionality that I’ll judge useful for the source repo, I’ll create a new branch from master_source and I’ll ask for a pull request;
  • the branch is partly accepted, but some stuff have been rejected even though they are good for me: I check which remarks I can take into account and I merge into my master. I merge my master_source with the master of the source repo. My two branches master and master_source will have almost the same functionalities, but the code lines will differ.

To go on with the previous example, let’s say the B1 pull request have been accepted but not the B2. I will have this configuration:

Illustration 01

You see the acceptation of B1 echoed on my master_source, and even if B2 has not been accepted, I kept it in my master. Normally, I should get to this configuration quite quickly, assuming that all of my pull requests won’t be accepted.

Now, I decided to work on several new functionalities from my master, and I’d like two of them, B3 and B4, being integrated to the master of the source repo. I will start from my master_source and make two branches, B3_source and B4_source, this operation couldn’t be very easy if the master and master_source are too different. I will so ask for two pull requests. Let’s say that B3_source has been refused and B4_source accepted. Too bad for B3_source, I will keep B3 in my master. As for B4_source, I can edit some lines regarding how it had been integrated in the master of the source repo, but I’ll integrate B4 in my master no matter what. Of course, I’ll copy the new master of the source repo (which have been improved with B4_source) in my master_source. I’ll have this configuration:

Illustration 02

Here is how I work on Github. If you have any remark on my method, don’t hesitate to contact me, I’ll edit this post if your comments are useful!


DJ Caësar 9114 is a DJ who also codes. He's too lazy to make two different websites, so he made only one, uniting these two passions.