XTRABYTES Promotes Transparency with GitHub

By Bigglet

XTRABYTES recent announcement that they’re making their GitHub commits public has some investors wondering why that might be relevant to them. The article below helps demystify how GitHub works and explains why such a move is important. 

Introduction

In brief, GitHub is a web-based service that allows developers to save, edit and process different versions of project source-codes. By providing an overview of a program’s version, viewers are able better comment on software bugs or other issues within the code. This is often done in the framework of transparency, as GitHub essentially opens a project’s source-code to the public for review, feedback and improvements. Others view the service as a social network for developers, However, neither of these descriptions explain what GitHub actually is. Let us elaborate.

The Git in GitHub

The system functions on the “Git” code. Git is an open-sourced code developed by Linus Torvalds (developer of the Linux platform) that functions as a distributed version-control system. It provides a full repository of project versions, including their full tracking and history of adjustments. Importantly, GitHub is a decentralized application and thus does not rely on a central authority.

Git makes it easy for developers to share and review each other’s work. Developers are able to gain easy access to a project’s history and submit new, instantly-accessible versions as well. They then can make new adjustments and upload a once more corrected version. By using these features, developers are able to dramatically improve projects in a relatively short time. 

In essence, these project versions are drafts that can be optimized by anyone who has access to them. Imagine you’re writing an assay in Word and you want to safely store it for others to review and make adjustments on it. Submit the document to GitHub, share it and ask them to improve it where needed. A Word document however is small compared to most computer projects. Unfortunately, the need to store data in a secure and orderly fashion is often overlooked by developers when constructing large-scale projects.

The Hub in GitHub

While Git helps making and tracking project changes easier, it lacks non-development features that multi-developer projects require. These include such issues as tracking, code discussion/review, etc. Consequently, GitHub created a web-based service around Git. GitHub’s clean and user-friendly environment encourages use by non-developers.  No complex programming skills are required to use the website, as GitHub’s user-interface handles all the code processing that would otherwise be required to be input manually (without the “hub” access).

Forks, pull-requests and merging

How exactly does GitHub manage all this? We will have to cover some basics first. Let us start with a repository, the place where all project data is stored. Whether decentralized (Git or Mercurial) or centralized (Subversion or Perforce), project developers depend upon repositories to store “versions” of a project. The project data stored within these repositories include (1) the historical records of a project; (2) the commits of a project and (3) a set of reference commits, called heads.

Forks

A project (or more precisely, blockchain) can be forked when two different program versions exist that are not fully compatible. This incompatibility can be accidental or deliberate (called a hard fork). Accidental forks typically occur when a project is updated. Here, two versions create different programs (or ledgers) that are incompatible with each other. In this case, the developer must rapidly eliminate any conflicts and bugs that prevent these two versions from “merging”. Hard forks occur when developers decide that deliberate program changes must be made regardless of whether they create version incompatibilities. When a hard fork occurs, a coin’s or program’s users must update their application(s) in order to continue using this new version.

In GitHub, users can improve an existing project by downloading the repository and adjusting the code. This new code can then be uploaded as a new repository (or in some cases be merged with the existing project). In order to combine the codes of both into one solid repository (known as a merge request), one must initiate a pull-request.

Before GitHub, projects were usually “patched”. That is, a full list of adjustments had to be typed and validated in person. GitHub circumvents this by providing a easy-to-use real-time working environment.

Pull requests

Once you’ve downloaded an original project, forked it and improved the source code, you could end up with a superior project compared to the original. In this case it could be beneficial to use this version over the original as it performs better or has other benefits over the old. You can now submit a pull request and provide more details in the comment section. The developers can see exactly what has been changed and whether they want to accept it. If a pull request is accepted, it will be listed in your GitHub portfolio, where other people can see which contributions you made to which project(s).

Final Word

By using GitHub, XTRABYTES is making good on its promise of greater transparency and better communication. GitHub provides XTRABYTES with the capacity to open-source its project code (albeit only on the front-end for now).  And once XTRABYTES reaches patent pending status, it will enable everyone to review the project’s core source-code (or back-end code) as well. Indeed, by submitting pull requests with their adjusted code, community members can actually participate in helping improve the project.

For community projects such as XTRABYTES, GitHub serves as an indispensable tool. No online tool is better situated to provide the benefits that accrue from community-reviewed source-code. 

 

Leave a Reply

Be the First to Comment!

avatar
  Subscribe  
Notify of