Attribution of Work in Programming Teams with Git Reporter

Many courses in computer science feature team projects which expose students to challenges resembling those in the software industry. For a fair assessment in team projects, measuring each student's contribution is a prerequisite. As version control systems store snapshots of a team's work, they can help make students' contributions transparent. However, available tools do not offer the required functionality to effectively analyze the distribution of work in a group. In this paper, we introduce Git Reporter, a new tool for measuring contributions in projects based on Git, the most widely used version control system. Git Reporter categorizes students' contributions based on importance and summarizes the distribution of work. Moreover, our tool provides a detailed mapping from each part of the project to its respective author. We found that using Git Reporter helps teaching assistants evaluate the quality of students' contributions. Furthermore, it significantly increases teaching assistants' confidence in their grading decision when compared with Git or a popular tool based on Git. A survey conducted among students indicates that Git Reporter may raise group awareness in student teams and help them divide the work more equally. Git Reporter is available as an open-source tool supporting assessment and team work. Furthermore, Git Reporter can support research in computing education and software repository mining by providing improved metrics compared to existing tools.


INTRODUCTION
Programming courses at universities often feature projects that are assigned to teams of students [9,33].Besides fostering programming skills, such assignments also expose students to challenges that resemble those in real-world projects [11].In team projects, students acquire valuable soft skills for collaborating with others.
Many project-based programming courses employ tools used in the industry, thus further preparing students for their careers.One technical skill of particular importance is the use of a version control system (VCS).Such systems store multiple snapshots of a software project.This allows software engineers to work on a snapshot of the project and share their results through the VCS.
In the past, version control has been found to be a skill that many graduates were lacking [7].Consequently, VCSs have become an essential part in computer science curricula in more recent years.Nowadays, VCSs as well as automated testing have been "identified as the two most popular tools in computing education" [5].These tools allow instructors to track students' progress, thus, making early interventions for struggling students possible [6].
VCSs may also support instructors in grading students [9,33].A grading approach in which all team members are awarded the same grade is common, but not fair, as it does not account for an uneven distribution of work within a team [19].Hence, most students prefer an assessment which considers individual contributions to at least some extent [32].However, determining these individual contributions poses a challenge for instructors [9,19,20,33].
Another common assessment approach involves peer evaluation where students are rated by other team members [19].Peer evaluation, however, relies on subjective ratings which, for instance, may involve biases, thus, potentially adversely affecting underrepresented groups of students [24,28].Some students may also be reluctant to openly report on their team members' efforts [19].
On the other hand, instructors basing their grades on students' self-reports and presentations are prone to biases as well.One such bias is the Halo effect where instructors' grading process is influenced by student characteristics unrelated to their performance, for instance their personality [9,31].
VCSs can help alleviate assessment-related problems, as they make individual contributions transparent.While inspecting every single snapshot in a large project may be infeasible for instructors, tools exist that help summarize the distribution of work by providing a set of contribution-related metrics.However, several tools, which we further describe in subsection 2.2, suffer from drawbacks, such as stalled maintenance or dependence on a specific version control platform (e.g., GitHub, GitLab).Moreover, these tools usually base their attribution of authorship on Git, which, as described in subsection 2.1, may lead to distorted contribution statistics.
In this work, we describe Git Reporter, an open-source tool aimed at providing objective metrics related to individual contributions in software projects using Git.These metrics allow instructors and TAs to make informed decisions in their grading process.Git Reporter's source code is available at https://github.com/Migutti/GitReporter.Furthermore, Git Reporter can be used to provide students with regular contribution-related feedback.This form of feedback can be used individually or in teams to monitor and evaluate the distribution of work, thus, promoting self-regulated learning and socially shared regulation of learning [17].Feedback produced by Git Reporter may raise group awareness (i.e., inform students about their teammates' activities).Group awareness can motivate students and help reduce social loafing [25] -a phenomenon where individuals "exert less effort on collective tasks than on individual tasks" [22].
In this work, we evaluate how Git Reporter can (i) support student teams with feedback on their distribution of work and (ii) support instructors and TAs in their grading process.In particular, we aim to answer the following research questions: (1) To what extent does Git Reporter help students see the contributions of their teammates (i.e., help raise group awareness)?(2) To what extent does Git Reporter help students divide their work?(3) How does Git Reporter influence students' behavior?(4) To what extent does Git Reporter accelerate TAs' grading process compared to Git, a version control platform, and an existing tool that summarizes contributions in a Git project?(5) To what extent does Git Reporter increase TAs' confidence in their grading compared to Git, a version control platform, and an existing tool that summarizes contributions in a Git project?(6) To what extent does the use of Git Reporter lead to different grading decisions by TAs compared to an existing tool that summarizes contributions in a Git project?

BACKGROUND
Several tools for measuring team members' contributions to a software project take advantage of commands that Git offers.In subsection 2.1, we outline some of Git's functionality and point out problematic aspects.In subsection 2.2, we present existing tools that aim at measuring the distribution of work in a Git project.

Measuring Contributions with Git
A Git project is stored in a repository.To save a snapshot or version of the repository's current state, a contributor creates a new commit.
Git can calculate the differences between two successive commits.To this end, Git compares all files that have changed between the old version to the new one.For each file, Git lists all lines in the old (new) state of the file that do not appear in the new (old) version as deletions (insertions).These identified changes form the basis for attributing file contents to their respective authors.
Git supports branches -a feature that allows multiple new versions to be developed simultaneously.Versions that diverged from a common parent commit can be merged into a new commit.A snapshot resulting from a merge has multiple parent commits.
A Git feature called Git blame attributes each line of a version to the student responsible for its insertion.Thus, by using Git, we can obtain the number of insertions, deletions and commits per author and determine the authorship of each line in the final commit.However, these numbers alone do not allow for a precise estimation of a student's contribution.
First, any change in a line results in a deletion and insertion, thus, changing the line's author.Such a change in authorship takes place even if the edit was negligible (e.g., adding white space).This behavior may severely distort contribution statistics, as a student's editor may reformat the code automatically on saving a file.
Second, Git does not consider the type of an inserted or deleted line (e.g., code lines are usually more relevant than comments).
Finally, another problematic aspect concerns the restructuring of code in a programming project.Git's default difference algorithm does not detect lines that are moved within files.Hence, such lines are counted as deletions and insertions and authorship is assigned to the person who moved the line.
While the third problem can be solved by calling Git blame with specific options, the two first aspects remain problematic, potentially distorting the estimated distribution of contributions.Git's peculiarities described here and in the literature (e.g., [8]) have to be taken into account when analyzing Git repositories.

Existing Git Tools
As claimed on the project's GitHub page, "Gitinspector is used as a grading aid by universities worldwide" [1].Examples include [4,12,13].This tool lists each contributor's number of commits as well as inserted and deleted lines.Furthermore, it shows how many lines of each contributor remained in the latest analyzed commit, i.e., the number of survived lines.Gitinspector can distinguish code from comments and its HTML report includes a crude assignment of each file to its main contributor.However, as also mentioned by [26], a major drawback is Gitinspector's "lack of maintenance, with the last release in 2016.Currently, it supports only Python 2.7, which has been deprecated since 2020".Gitinspector's age posed a real problem in our teaching experience, as several teaching assistants were unable to execute the program on their computers.Git Reporter solves this problem, as it is written in Python 3.Moreover, in contrast to Gitinspector, our tool is intended to give a more fine-grained overview showing how many lines are empty or contain only one symbol (e.g., an opening or closing brace).Git Reporter provides more detailed information also on the file level, by displaying the attribution of each line to its author.
Another open-source tool for analyzing Git repositories is Git-Quick-Stats (GQS) [2].Promoted as "a simple and efficient way to access various statistics in a git repository" [2], this project is still actively maintained.In past semesters of the course described in this paper, this tool was used to summarize students' contributions in team assignments.GQS outputs the number of inserted and deleted lines as well as the number of commits per contributor.A major disadvantage, however, is that GQS only summarizes information provided by Git, thus suffering from Git's shortcomings described in subsection 2.1 As both, Gitinspector and GQS, have their shortcomings, there is a need for a capable and up-to-date tool for measuring and visualizing team efforts in programming projects.In recent years, more and more tools were developed aiming to fill this gap.Parizi et al. [29] emphasize the need for an open-source tool, as paid products might be too expensive for universities.However, while [29] discuss a prototype of a possible solution, we are not aware of a publicly available version of their tool.Several other tools seem to share this drawback, including those presented in [21] and [3].
Besides contributions to code, GitLab Analyser [14] also tracks activities, such as working on issues and merge requests.However, dependence on the Windows operating system and the version control platform GitLab prevent it from being universally applicable.Furthermore, [14] state that the tool can count insertions and deletion, but they do not mention survived lines.The feature for counting survived lines is also missing in a recently presented dashboard application called Concert [16] which integrates VCS data provided by GitHub with information from discussion forums.
GitCanary [30] provides a rich dashboard for Git projects with charts visualizing several metrics including the distribution of work.To us, this tool seemed very promising, however, its scarce documentation and the possibility to address Git's shortcomings described above led us to write a new tool for measuring contributions.

THE GIT REPORTER 3.1 Preliminary Version of the Git Reporter
As existing tools have their shortcomings, there is a need for a capable new tool for measuring individual efforts in programming projects.To fill this gap, we created the Git Reporter.The goal for Git Reporter's preliminary version was to count insertions and deletions of each commit in a way that is similar to Git.In the resulting report (which we call the Git report), these counts are listed for the whole project, for each author and for each file.The number of commits is presented in the Git report as well.
Already in its preliminary version, Git Reporter differs from Git's default functionality in several aspects.Git Reporter applies a difference algorithm which finds the largest common subsequence.In order to tackle the problem of distorted statistics when code blocks are moved, the algorithm is executed on the resulting difference recursively.Hence, the authorship of moved lines does not change.In contrast, several existing tools mistake moved lines for deletions and insertions.
For merge commits, Git Reporter compares the changes to all parent commits whereas Git only considers the first parent.Insertions and deletions of merge commits are listed separately in our report.GQS and Gitinspector do not have such a feature.
Additionally, the Git report provides a mapping from each line to its author.This gives an overview of which parts of the project a contributor is responsible for.This functionality roughly corresponds to Git blame, but the result is more precise due to the differences to Git's default difference algorithm mentioned above.

Student Opinions on the Preliminary Version of The Git Reporter
Course setting.The preliminary version of the Git Reporter was used in the course Object-Oriented Programming 1 which is offered in the second semester of several study programs related to computer science at a European university of technology.In this course, the assessment is based on the students' performance in three assignments.We focus on assignment 2 (A2) which was the first team assignment and accounted for 60 % of the achievable points.Each Over the course of the semester, nine questionnaires were administered, the last of which concerned students' opinions on Git and Git Reporter in its preliminary version as well as their experience with A2.Of the 309 students registered for A2, 145 participated in the last questionnaire.132 students stated that they have looked at the Git report during A2; the remaining 13 students did not find the Git report or were not interested in it.All students who participated in the survey gave their consent to use their responses together with other data, including their grades, for research purposes.
Potential for improving Git Reporter.Among other questions, the questionnaire asked students to provide suggestions for improving the Git Reporter.Table 1 summarizes the most frequent responses.
The most frequent suggestion (identified in 15 responses) was to neglect contributions that merely format code.Format-related modifications include adding or deleting white space, which is performed automatically by some editors on saving a file.Renaming variables to make them style-guide-compliant is another example of format-related changes.Formatting code and writing new code require different skills; thus, they should be treated differently.
Renaming of files also led to wrong contribution attributions (6 responses).Git Reporter considered students who renamed a file as the file's author even if the file's content was written by another team member.Two students claimed that moving blocks of code also resulted in insertions and deletions.Git Reporter accounted for moving code within a file, however, not between files.
Several other categories of student responses concern the issue that different lines in a source file can differ in complexity (9 responses).Different levels in complexity can arise from the code's task (e.g., writing many short functions can be less complex than implementing an intricate algorithm).Furthermore, writing comments is considered less complex than writing code (8 responses).Empty lines should be considered separately as well (2 responses).
The preliminary version of the Git report provided students with the number of lines inserted and deleted by each student.However, it did not include information on how many lines inserted by each student survived until the project was submitted (5 responses).
Five students advocated UI improvements for the Git report, for instance, by adding diagrams to visualize contributions.

Enhanced Version of the Git Reporter
To solve the major problems identified in the student survey, we add a preprocessing step in the enhanced version of the Git Reporter.Before comparing any two snapshots, we transform all lines into a standardized form by removing white-space.With this additional step, we are able to ignore all format-related changes where students merely insert or delete white-space characters.Thus, changes restricted to white space are neither counted as insertions nor deletions and formatting does not change the authorship of a line.
After this first step, the whole file is parsed to categorize the lines, based on their complexity.In particular, Git Reporter differentiates between (i) empty lines, (ii) lines that only contain one symbol (e.g., a brace), (iii) code, and (iv) comments.For each of these four line categories, insertions and deletions are counted separately, which results in a more fine-grained measure of each student's contribution.These counts per category as well as the total number of lines are displayed in the Git report.In contrast to GQS, it is now, for instance, possible to detect students, who at first glance seem to have a large contribution based on the total insertion count, but who are mostly responsible for writing comments rather than code.
Git Reporter is able to recognize comments in C++, as this is the language used in our course.Languages sharing the same comment syntax (e.g., C, Java, and JavaScript) are automatically supported as well.Detecting comments with a different syntax (e.g., Python) requires updating the parser.Git Reporter's modular structure ensures that this additional feature will be easy to implement.
Despite being able to recognize comments, we consider the issue regarding complexity as only partially solved in Table 1.More work is required to identify the complexity of code based on what the code does.We plan to tackle this issue in a future release.
Another step was added after applying the difference algorithm comparing two commits.Lines that do not match are not immediately classified as insertion or deletion.Instead, they are compared one by one to detect modifications.A modification occurs, if a line of the newer commit replaces a similar line from the older commit.The minimum similarity threshold -measured as ratio of matching characters -to detect a modification rather than an insertion and deletion can be configured.In contrast to Git Reporter's preliminary version, the authorship of a modified line does not change.Such a line is attributed to the original author.
With all the improvements mentioned above, the mapping of lines to their authors is more precise.In case of formatting or otherwise slightly changing a line, the line's authorship is not transferred to the last contributor and the original author is preserved.The enhanced version of Git Reporter additionally offers statistics about the survived lines, which -due to the improvements -are more representative than the corresponding results reported by Git blame and Gitinspector.Furthermore, survived lines are listed separately per line category by Git Reporter.
Note that some further enhancements still need to be made.For instance, the movement of code blocks between files is not detected yet.Once this feature is implemented, the issue of renaming files, which some students deemed problematic, will be solved as well.Moreover, UI-related enhancements suggested by students are an open issue that we are currently working on.

EVALUATION 4.1 Student Survey
The last questionnaire of the semester contained questions which help answer the first three RQs regarding students's use of Git Reporter.Note that the responses refer to the preliminary version of the tool, as students were provided with its report during A2.
Usefulness of a report.Students were asked whether i) Git, ii) the Git report helped them see their team members' contributions.Question i) was answered by all 145 students, whereas question ii) was answered by 132 students who had a look at the report during A2.Students responded by choosing an item on a seven-point Likert scale ranging from strongly disagree to strongly agree.
Figure 1   We also asked the students whether the Git report supported them in dividing the workload among team members.As shown in panel (a) of Figure 2, approximately 75 % of the students agree that a report such as the one produced by the Git Reporter can help divide a team's workload.However, only about half of the students agree that the preliminary version of the Git report helped them divide their work equally, as can be seen in panel (b) of Figure 2. We believe that the enhanced version of Git Reporter will improve the usefulness of the tool, however, we leave the evaluation of these improvements as a promising avenue for the future research.
Influence of the Git report on students' contributions.Besides the report's usefulness to students, we were also interested in the Git report's impact on student behavior.Hence, we asked students how much code they would have written if there had been no Git report.The aggregated responses are represented in panel (a) of Figure 3.We see that almost three in four students did not feel influenced regarding the amount of code.However, almost 20 % claimed that they would have written more code.Of these students, 54 % received an excellent grade and 29 % a good grade.The remaining 17 % received a grade equivalent to a C.This result suggests that more capable students tended to deliberately do less of the work -perhaps in order to give other team members a chance to contribute.
We also asked students, whether the Git report influenced the number of commits they created.Panel (b) of Figure 3 shows that 84 % claim that they did not produce more or less commits due to the Git report.The results summarized in Figure 3 suggests that the Git report's influence on the number of commits is weaker than on the amount of code students write.

Study with Teaching Assistants
To analyze how Git Reporter can affect TAs' grading process (i.e., RQs 4, 5, and 6), we conducted a study, in which eight TAs simulated assessing the distribution of work in student repositories.
To select an interesting sample of repositories for our study, we first calculated the contributions within each team using GQS and Git Reporter.For each obtained distribution of work, we then calculated the inequality among team members using the Gini index [15].This inequality measure ranging from 0 (i.e., perfect equality) to 1 (i.e., perfect inequality) was also used in other research to summarize the distribution of student contributions in Git projects [18].For our study, we selected those 22 (of 103) repositories where the Gini indices based on GQS and Git Reporter differed the most, with absolute differences ranging from 0.118 to 0.440.
The TAs evaluated each repository assigned to them in three steps.In the first evaluation step, TAs estimated the distribution of work by using only the functionality that Git and the version control platform provide by default.This includes Git blame and the history of commits accessed through the browser.Each TA had five minutes for this first step.In the second step, the TAs were allowed to additionally use either GQS or Git Reporter for three minutes.In the third step, they were allowed to use an additional tool for three more minutes.If they used GQS (Git Reporter) in the second step, they were provided with the results by Git Reporter (GQS) in the third step.
Each repository was analyzed by two TAs.We assigned TAs randomly, but only to repositories they did not grade during the semester to eliminate a potential source of biases, such as the Halo effect [9].Each repository was analyzed by one TA using GQS in the second step and Git Reporter in the third step.We call this order of tools order 1.Another TA looked at the same repository with the two tools in reversed order, that is Git Reporter in step 2 and GQS in step 3, which we call order 2. By having two TAs evaluating a repository in different orders, we can exclude the order as a potential confounder in our experiment.
Six TAs analyzed six repositories each (three in order 1 and three in order 2), while two TAs examined four repositories each (two in each order).Thus, 22 repositories were evaluated by two TAs each.
Confidence.After each step, the TAs estimated the students' contributions and specified how confident they feel in their estimation on a Likert scale ranging from 1 (not confident at all) to 7 (very confident).When using Git and the version control platform alone (i.e., evaluation step 1), the TAs' response indicated uncertainty (i.e., a response less than 4) in more than 60 % of the analyzed repositories.For the remaining repositories, the responses were neutral.Confidence increased significantly with a tool in step 2.
When evaluating a repository in order 1 (i.e., using GQS before Git Reporter), confidence also increased significantly when additionally using Git Reporter compared to using Git and GQS.This result was obtained using the one-sided Wilcoxon signed-rank test (p-value 1.68e-4).
To ensure that this finding is not caused by the order of tools, we also tested whether step 3 improved the confidence with evaluation order 2 as well.With GQS following the Git Reporter, we did not find a significant rise in confidence from step 2 to step 3 (p-value 0.73).In fact, the confidence even tended to drop when additionally using GQS in step 3.This suggests that after having seen the history of commits and Git Reporter results, some TAs even felt confused by the GQS results.
Change in results when changing tools.TAs' confidence in their estimations is also reflected by the change in their estimation when compared to the next evaluation step.We can measure the change in estimated distributions of work using the Kullback-Leibler divergence (KLD) [23].The KLD is zero if two distributions are equal and positive otherwise.The measured KLD between step 2 and step 3 is significantly higher for evaluation order 1 than for evaluation order 2, with a p-value of 1.67e-5 in a one-sided Wilcoxon signed-rank test.This means that the TAs' estimations of contributions change significantly more when moving from GQS to Git Reporter than from Git Reporter to GQS.
After using Git Reporter in step 2, the majority of TAs did not change their estimated distribution of work when additionally being provided with GQS results (14 of 22 repositories).In evaluations in order 1, however, there was only one repository where the TA did not change their decision from step 2 when additionally being provided with Git Reporter in step 3.

Time.
After each evaluation step TAs also indicated how much longer they would think about the distribution of work until arriving at an estimation.Focusing on evaluations in order 2, we can compare Git and the version control platform (i.e., step 1) with Git Reporter.Even when considering the three extra minutes spent in step 2, the time TAs would need for an estimation decreased significantly when using Git Reporter, as confirmed by a one-sided Wilcoxon signed-rank test (p-value 2.13e-4).
When comparing GQS and Git Reporter in evaluation order 1, we found that the needed time decreased even when penalizing Git Reporter due to the three extra minutes in step 3.However, this decrease was not significant (p-value 0.072).
Assessing the quality of contributions.For each repository, TAs additionally indicated to which extent tools help them assess the quality of students' contributions.The results are shown in Figure 4.For GQS, TAs indicated a lack in support in approximately 45 % of the repositories.On the other hand, TAs mostly felt supported by Git Reporter when assessing the quality of contributions.The quality of contributions can be inferred from Git Reporter's statistics.

DISCUSSION
Feedback on a team's distribution of work increases group awareness and can support students' monitoring processes.Thus, it fuels regulated learning [17].Feedback can motivate students and support them in organizing their work.
Other tools, such as the one presented in [25] and [27], support group awareness at specified points in time.Instructors can use Git Reporter to support group awareness throughout a project by automatically providing students with the tool's report on each push to the version control platform (via continuous integration).
The students surveyed in this paper had the opportunity to access feedback produced by the preliminary version of Git Reporter on each push.40 % of these students claimed that Git Reporter helped them see what other team members were working on.Almost half of the surveyed students stated that Git Reporter helped them divide their work.In the enhanced version, we addressed several issues raised by students.Thus, we think that the enhanced version and future versions will support students even more.
Instructors and TAs can also benefit from Git reporter.As our tool can be integrated into any continuous integration pipeline, it can be used to point to struggling students and teams with uneven contributions, thus enabling early intervention.
Furthermore, our study has shown that Git Reporter can support the grading process.In our study, TAs faced repositories with several hundred commits.Gauging individual contributions in such projects poses a challenge and several TAs pointed out that they had to guess the distribution of work even with the support of GQS.
Git Reporter provided them with a more fine-grained report which increased TAs' confidence in their grading.
While Git Reporter can be run from the command line, it can also be integrated in other programs.This will allow dashboard designers to develop applications powered by Git Reporter.We are currently also working on a dashboard to present Git Reporter's results in a clearer and more interactive way.
However, basing the assessment on quantitative measures, such as students' contributions, might lead to repercussions by increasing the chance of students adapting their behavior to manipulate these metrics.This problem is also known as Campbell's law [9,10].
In our survey, some well-performing students indicated a welcome adjustment in their behavior due to the Git report.By reducing the amount of code they wrote, they gave other team members a chance to contribute to their team's project.In the past, we have witnessed how capable students can play a dominant role preventing other team members from contributing to the project.Git Reporter might help alleviate such problems.
A few students reported in our study that they created some artificial commits, however, not in order to cheat, but to compensate for Git Reporter's attribution of authorship to students who have merely renamed a file.We expect this and other shortcomings of Git Reporter to be resolved in the near future.
To reduce the incentive for students to adapt their behavior, instructors may base their estimation of contributions on other means, for instance, peer evaluation.While peer evaluation has proven useful in many contexts, it also has its drawbacks.For instance, [27] found it "challenging to deal with missing data".Furthermore, validating peer evaluations is important [27].Git Reporter could prove helpful in this regard.
When interpreting our findings, threats to validity have to be taken into account.First, the study with TAs was based on a sample of student repositories.This sample was not random, but one where GQS and Git Reporter showed a high level of disagreement.Second, even though TAs have used the preliminary version of Git Reporter during the semester (but not the enhanced version which was used in the study), it was not possible to conceal from the TAs which tool was developed by us.However, the responses on Likert scales were not the only indicators for the TAs' preference for Git Reporter over Git and GQS.The distributions of work estimated by TAs also revealed a high level of trust in Git Reporter's results.

CONCLUSION
In this work, we introduce Git Reporter, a tool for assessing contributions in Git projects.We discuss how Git's default algorithms may lead to distorted contribution statistics.By reducing the dependence on Git, we address shortcomings of existing tools.
We describe how the development of Git Reporter evolved and how feedback by students was used to improve our tool.The student survey also provided insights into how our tool can support and encourage students to divide their team's work more equally.
Furthermore, a study among teaching assistants showed how Git Reporter can increase confidence in their grading process.Given the widespread use of Git-based team projects in computer science curricula, we believe that many students and instructors could benefit from using our open-source tool.

Figure 1 :
Figure 1: Students' opinions on whether (a) Git and (b) the Git Report help them see their teammates' contributions.

Figure 2 :
Figure 2: Students' views on whether the (b) Git report or (a) a similar report can help divide the work in a team.

Figure 3 :
Figure 3: Contributions if there had not been a Git report. percentage

Figure 4 :
Figure 4: TAs indicate that Git Reporter better reflects the quality of contributions compared to Git-Quick-Stats.

Table 1 :
Students' ideas for improving the preliminary version of Git Reporter.Issues printed in bold (italics) are solved (partially solved) in the enhanced version of Git Reporter.
shows the distribution of responses.Most students agree that Git shows what other team members have been working on.However, only 40 % agree that the Git report helped them see what other team members were contributing.Git helped me see, what the other team members had been working on.
(b) The Git report helped me see, what the other team members had been working on.percentage