8
22 Comments

I'm building a Git Pull Request review tool

I had this idea when I was reviewing a fairly big PR. It was easy to get overwhelmed by looking a GitHub diff and I wanted to take a step-by-step approach.

Then, I started working on a tool that has a timeline at the bottom and a code view as the main screen (similar to video editing software like iMovie). So, as you move in timeline, changes appear in the code view - as if somebody is typing.

Every change can be reordered (so you can start where it makes sense) or it can be marked as viewed/irrelevant etc.

I think this would be useful as a PR author if you want to explain your code to others (by moving diff changes in some logical order) or if you are a reviewer and trying to grasp the idea yourself.

It's still in early stages (and a bit ugly) so I don't have anything to share yet, but I'm curious what do you think about the idea?

on January 7, 2022
  1. 2

    It took a moment for me to realize you meant "Push Request" with "PR". I started reading thinking "what is a public relations review tool, hmm". To filter out people like me, I'd advise saying something like "Git PR Review Tool" or something like that.

    1. 1

      Oops! You are right! :D
      Thank you!

  2. 1

    Update: I actually made the thing! Not done of course, but at least there is something clickable: https://www.gitline.io

  3. 1

    I think it is a good idea to have another way of looking at code. Timeline could give us insight into developers "thoughts process"
    for example, the heat map of the code (parts of the code file where developer returned multiple times) may prove a good place to look into because developer could have some problems there :)

    I'm working on a visualisation of the code (drawing PlantUML diagrams from typescript) and adding time component to it would transform image into a video of code growing :D

  4. 1

    Hi there,
    This seems an interesting approach. But it seems you're focusing on github instead of GIT (maybe that's the intention).

    Have a look a gitlab.com, they have some stuff in place that already cover some of the issues you mention (no timeline though)
    BTW, At Gitlab, a PR is called MR (Merge Request)

    Some notes on previous comments
    Its common to have juniors doing reviews, alone or in pair with seniors. It's a good way for a junior to get understanding about a project and its caveats.

    Also, if a MR/PR has too many changes, then most likely the work is poorly structured and should have been broken down into smaller issues. For example having basic CRUD code to start with (generally this is boiler plate code auto generated, and there ain't much to review) then dependent issues that add up functionality in small chunks that are easy to review and quick to test.

    Have implemented both, along some other good practices and automation in a couple companies in the past, revealing some benefits like productivity up, better project definition, a searchable project history which is very useful in the long term for a big project

    Just my 2cent though

    1. 1

      Thank you for your 2cents! :)
      I will take a look at gitlab (I've used it before, but never actually reviewed anything)

      And I agree with other comments as well. Going forward I will try not to focus on solving "big PR" problems since I agree that in most cases the solution is to just break it down.

      My current plan is to focus on "authors explaining code to others", but will see where will that lead me 🤷‍♂️

      I don't really know what I will build in the end, I just feel there is something to be done in "PR/MR space" because I felt problems there before.

  5. 1

    I really want to see that! 😊

  6. 1

    I agree with @101008, it's not going to get a lot of traction with reviewers. I am an architect and I do code reviews every day. I deal with two main types of reviews: Code addressing an individual task or defect, and branch merges encompassing many such individual tasks. In the first case what I really want to see is whether the code satisfies the acceptance criteria in the original request as stated in the (in my case) Jira ticket that requested it. The Jira ticket itself is often connected to other tickets (support ticket describing the problem, eg). What I really want is to work backwards from the PR to the PR comment, to the Jira ticket, and to its related tickets, all in a way that keeps track of my context and allows me to jump back to where I started with minimal fuss. I don't believe such a tool exists.
    For large branch merges, it's the same issue just at a larger scale. Mostly I want to go back to the original PR, see my notes from the original review, and then if there were merge conflicts that had to be fixed, what was done to satisfy the conflicts.
    The best UI for this IMO is a tool that displays relationships and gives you options for following the traces. You COULD try something like a mindmap but I don't usually need a "big picture" solution. I won't follow 90% of the relationships anyway.
    I like your thinking, however. Visualization is the future.

    1. 1

      Thanks for the feedback!
      I get how this wouldn't be useful for someone like yourself. I got the idea for this when I was 2 weeks in a company with a lot of unknowns which is a different perspective than a tech lead / architect has.

    1. 1

      I don't see how is this related to the idea I wrote about?

  7. 1

    I thought about something like this since I also had the same problem, but I just found there's a VS code extension that makes github PR reviews much easier: https://code.visualstudio.com/blogs/2018/09/10/introducing-github-pullrequests

    I've been using that and it's so much better than the default view on github. The issue with a new PR review tool is that it has to be either an extension in our IDE (VS Code) or something in Github for us to use. We would not use a separate tool for this unless it's miraculously 10x better.

    1. 1

      Yea I know. I'm using vscode extension as well. But I'm not trying to build a tool that will replace it. It is now obvious to me that I should make this more clear going forward :)
      So I think I will start with a tool for PR authors (not reviewers) as a way to explain their work to others. Maybe even with a "export to video" option.

      Thanks for the feedback!

      1. 1

        There is a need for reviewer tools, too - just posted my thoughts on the main thread. No question incorporating such a tool into an existing IDE is a good way to go, so maybe VS is the right one. It looks like that VS extension does not integrate with Jira, but it's open source...

  8. 1

    Sorry about this but I don't think it is a good idea, especially for big Pull Requests. I am a Lead Tech at a startup and I don't code most of the time, I just check my team PRs.
    When there is a big PR you want to check it all at once because you want to be sure not only logic, but also there is not a bad import, wrong requirement, etc.
    So let's say someone is invoking a function or defining a function, I'd like to see if it's correctly called (name, parameters, etc) in the other parts of the code where it is used. If I only have a partial view I can't do that and I have to wait until that's done in the timeline you mention.
    At the end, I am adding cognitive load to my task, and sadly, teh same cognitive load that the developer of that PR had to do (remember to call the function correctly, etc).
    In my opinion, this tool not only doesn't help for this task, but removes an important feature which is being able to see/explore/browse the whole PR at once.

    1. 1

      I see what you mean, thank you for the feedback!

      But I’m not saying this should replace current tools (github diff, vscode view etc) I just think there is an use case for timeline when you are trying to understand something not so familiar. To junior developers, every line can be unknown, and this could help not getting overwhelmed, i think. Especially if the PR author takes some time to prioritize changes (but thats not required).

      I wanted to use it myself when i was onboarding in my last company. To first “mark” the code i understood and have it “written” first so i can paint a picture of what’s going on more easily. Tools i used only had “mark as viewed” for entire file, rather than specific changes.

      But if you are a tech lead and know the codebase well, you probably wont get overwhelmed and hence wont need this.

      Does that make sense?

      1. 1

        It makes sense - the points you are saying are problems, as you mentioned, for new devs.
        But I dont know if the solution is a new UI for PR. In fact, I doubt a new dev in a team should be looking into PR, it is usually the other way around. New devs creates PR and someone who already know the codebase checks them.

        1. 1

          Perhaps my UI solution is not the best. I will test it out and try to focus on the problem i had. Maybe timeline idea will change (it already has a few weeks ago)

          As for new devs reviewing PRs - we do this in the current company i work at. Everybody is reviewing each others work in a team. Usually at the beginning, new dev would not be the only reviewer but we still think it is useful for them to learn about the codebase and also get in a habbit od reviewing code.

          I dont know if this is common or not 🤷‍♂️ But i guess you can get why i got this idea in the first place - checking somebody PR in a unknown codebase

  9. 1

    One thing i haven’t decided yet is what should i focus on - authors or reviewers? 🤔

    Ideally it would serve both, but that is probably not realistic for first the version.

    At first, I thought this will only be useful for reviewers, but then I also spent time in explaining my PR to others (especially juniors). One time i made a video by reimplementing the feature I was working on while recording my screen.
    With this tool, i could reorder changes so it would be easier to record a video from that (or send a link to the app where they could “play” it and read comments)

    For example, if I added a new file, I could choose that it should first start by defining a function, then import dependencies when they are needed etc - define the order in which changes are “typed”

  10. 1

    I like the idea domagojk!

    The PRs I’m personally reviewing aren’t that big, as we intentionally keep them small.

    However, I do see use-cases where this will provide value. Also: Merge conflicts! Even though those are mostly quite small, I always get confused. Could be me, but I could see your product provide additional value there as well!

    1. 1

      Yea, we also try to keep them small, but I think I reviewed a big one every week 😳 (I guess it is more common in startups)

      Right now i don’t see how exactly would my app help with merge conflicts, but I will definitely keep it in mind, than you for that 🙂

    2. 1

      100% agree merge conflicts can be a pain, especially when rebasing and you have git actions monitoring code owner file changes and flagging people to review it. It can end up committing other peoples commits on top of your branch as if they're your own. I know this is my deficiency with git but its definitely a pain point and something I've seen other devs deal with.