Change Map

Inspiration

When working with code on GitHub, a pull request can change many files at once. Opening the list of changed files is easy, but understanding how those changes fit together can take much longer. A reviewer may need to jump between source files, tests, configuration files, and documentation just to understand what changed and what needs attention.

I wanted to make this process easier. Instead of asking developers to read a long list of files one by one, what if GitHub could show them how the changes fit together and suggest a useful order for reviewing them?

That idea became Change Map.

What it does

Change Map gives GitHub pull requests a more useful review view. It turns a list of changed files into a visual map that helps developers understand the work before going through the details.

With Change Map, developers can:

• See the full picture: View changed files grouped into source code, tests, configuration, and documentation.
• Follow a review path: Get a suggested order for checking related files instead of working through a long list without context.
• Find important changes: See file relationships and identify areas that may need closer attention.
• Keep track of progress: Mark files as reviewed and see what remains.
• Open real pull requests: Load a public GitHub pull request and explore its changed files.

How I built it

I designed Change Map around a simple idea: a good code review should help developers understand the changes, not just display them.

The project uses GitHub's available pull request data to collect changed file names and diff information. It then groups files by their purpose and uses the available information to build a visual map. A review panel lets developers move through the suggested order and track their progress.

The goal is to keep the interface familiar to GitHub users while adding a different way to explore a pull request. The existing file list remains useful, but the map provides another view when a change is difficult to understand.

Challenges and what I learned

One challenge is that file names alone cannot explain every relationship in a codebase. A test file may be related to a source file, but naming patterns are not always reliable. The review order must therefore be presented as a suggestion, not as a guarantee that every important dependency has been found.

Another challenge is making the feature useful for both small and large pull requests. A simple change should remain quick to review, while a larger change should benefit from grouping, navigation, and a clear overview.

Building Change Map helped me think more carefully about how developers read code, how small interface changes can improve existing tools, and how to make a new feature useful without trying to replace the workflow people already know.

What comes next

I would like to improve the file relationship map, make the suggested review order more accurate, and add better ways to compare source changes with their related tests.

In the future, Change Map could become an optional view inside GitHub's existing Files changed tab. Developers could switch between the familiar file list and the visual review map whenever they need a clearer understanding of a pull request.

Change Map is built around one simple goal: make code reviews easier to understand, one change at a time.

Built With

• api
• css
• git
• github
• html
• javascript
• react
• rest
• typescript
• vite