Git is a DVCS. The Eclipse Foundation reported in its annual community survey that as of May 2014, Git is now the most widely used source-code management tool, with 42.9% of professional software developers reporting that they use Git as their primary source control system2. This figure grounds the selection of Git in this Thesis. This
section outlines the main operations supported by Git (i.e. commit, branch and merge) and its web counterpart, GitHub (i.e. fork and pullRequest).
C.2.1 Data Structures: the Git Object Model
The major difference between Git and other VCSs (e.g. CVS, Subversion) is the way it stores data: as a set of snapshots of a mini filesystem instead of a set of changes. Every time a client saves (i.e. commits) the state of the project, Git takes a snapshot of all the files. Git includes four objects: TREE, BLOB, COMMIT and
TAG (see Figure C.1) which are characterized along the following properties: sha
(unique hash identifier based on the objects’ content), type (“tree”, “blob”, “commit” or “tag”), content and size (in bytes). TREEobjects, represent file-system directories,
which can contain furtherTREEs andBLOBs. BLOBobjects, represent a file storing data. COMMITobjects, represent a version (i.e. snapshot) for the project at a certain
time. COMMIT’s project attribute, hold the top-level directory for the project artefacts. Commit objects, are preceded by its antecesor commit (zero parents for the first commit in the commit history, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches). Commit objects, contain additional metadata: message (user entered message describing the changes), commiter (the user who performs the commit), author (the user responsible for the change) and time (the moment on which the commit was performed). Note, that a COMMIT
object does not itself contain any information about what was actually changed. All changes are calculated by comparing the contents of the project tree referred to by the commit, with the trees associated with its parent. Finally, TAGobjects serve to
tag special commits, such as, releases, hot-fixes, etc. A Git REPOSITORY, comprises
1https://tinyurl.com/jb37na6
Figure C.1: Git Object Model
all objects aforementioned. Additionally, Git repositories, haveBRANCHEs, which is
just a lightweight movable pointer to a COMMIT. Git repositories must have at least one branch (i.e. the default branch). The default branch, is destined for the main- line of development. When a Git repository is created, Git automatically creates a branch named master, and sets it as the repository’s default branch. Git repositories further include: repository owner user, repository name, a little description about the repository project, the currentBranch the user is working at, the uri of the repository, a origin, if the repository is a clone of another Git the repository, and the remote repository to which it synchronizes (if any).
C.2.2 Git Basic Operations
Commit. A commit operation makes permanent the software changes to a repository. Git, converts the users’ working directory into a Git snapshot, i.e. COMMITObject(see
Figure C.2). When a commit operations is performed, the branch moves forward automatically, pointing to the last commit performed. This way, commit objects are chained together, with each new snapshot pointing to its predecessor (c2 points to c1). Over time, a sequence of changes is represented as a series of commit objects, known as the repository history. The operation, can be implicitly described as,COMMIT: USER XREPOSITORY XBRANCH XTREE XSTRING-> COMMITOBJECT3.
Figure C.2: Commit operation
Figure C.3: Branch + Commit Operation
Branch. It launches a separate line of development. Branches are created upon an existing commit (users must set first the branch-to-be name). Figure C.3, depicts the repository before and after performing a branch operation to create branch1 upon master. When branch operation is performed, branch1 points to c2 commit object. Further commits to branch1 (i.e. commit c3), make the two branches diverge. The branch operation can be described as BRANCH: REPOSITORY x BRANCH x IDENTIFIER-> BRANCH.
Merge. Often, a branch is fused (i.e. merged) with other branches to reunite disparate efforts. Figure C.4, depicts a merge operation scenario, where the headBranch will be merged into the baseBranch. Git does a simple three-way merge, using the two commit objects pointed to by branches c3 and c2, and their common ancestor (i.e. c1). As a result, a new commit, c4, is created for baseBranch. When this process does not go smoothly (i.e. different changes where made to the same part of the
Figure C.4: Merge Operation
Figure C.5: Fork Operation
same file), Git adds standard conflict-resolution markers to the files that have conflicts, so that users can detect them, and resolve them manually. The merge operation can be defined as:MERGE: UserXRepositoryXBranchXBranch ->COMMITOBJECT.
GitHub4is the largest open source Git repository hosting service. GitHub provides
a Web-based graphical interface, and introduces social functionalities that make developer’s identity and activities visible to other users [ref -Social Coding in GitHub]. This is particularly interesting for SPLs where two different teams need to collaborate: domain engineers and application engineers. GitHub introduces two new operations: fork and pull request.
Fork. This is the mechanism to make copies (i.e. clones) of entire repositories across GitHub users. When a user clicks on the fork button, GitHub automatically copies that repository to the user who requests the fork. This operation keeps both repositories connected, the source repository knows all its forks repositories, while the forked repository sets its origin attribute with the source repository uri . Fork operation is defined as,FORK: REPOSITORY XUSER-> REPOSITORY.
Pull request. Whenever one of the users thinks his changes to the repository are appropriate for the other party, he can send him back as form of a pull request. A pull request operation, is basically a merge request between two repository branches. The user sending the request must specify the following attributes: (i) the base repository and base branch, where changes should be applied, (ii) the head repository and the head branch, meaning what changes the user like to apply, and (iii) a message, describing the proposed changes. Changing the base repository branch, changes who is notified of the pull request (the base repository gets the request). Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary. A pull request operation
Figure C.6: GitHub additional object Model (partial model).
can be described as: CREATEPULLREQUEST: USERx REPOSITORYx REPOSITORY X BRANCH X BRANCH ->PULLREQUEST. Both operations, require Git to handle
additional objects, which are depicted in Figure C.6. This model of collaboration is commonly called the fork&pull model, which is very popular for the development of open-source projects.