# Jumping into existing codebases

DevFeed: [Jumping into existing codebases](<https://devfeed.tech/articles/jumping-into-existing-codebases-21607.md>)

Original publisher: [Read original article](<http://miqu.me/blog/2015/11/15/jumping-into-existing-codebases/>)

Author: Miguel Angel Quiñones

Published: 2015-11-15T18:55:18Z

Content type: article

Language: en

Sources: [Miguel Quinones](<https://devfeed.tech/sources/miguel-quinones.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [Code](<https://devfeed.tech/topics/code.md>), [Homebrew](<https://devfeed.tech/topics/homebrew.md>), [HTML](<https://devfeed.tech/topics/html.md>)

Tags: [articles](<https://devfeed.tech/tags/articles.md>), [developers](<https://devfeed.tech/tags/developers.md>), [git](<https://devfeed.tech/tags/git.md>), [history](<https://devfeed.tech/tags/history.md>), [make](<https://devfeed.tech/tags/make.md>), [time](<https://devfeed.tech/tags/time.md>), [visualization](<https://devfeed.tech/tags/visualization.md>)

## AI overview

A developer shares a practical method for becoming productive in an existing codebase. The article recommends examining Git history and repository statistics, using git_stats and Gource to understand contributors, code changes, and project structure, and reviewing commit-message conventions.

## Source excerpt

I've recently changed workplace - we're hiring! - and I've jumped into an existing codebase. This is a good time to review what I like to do when I start to work on a project in these circumstances. When you don't start a greenfield project, which is most of the time for many developers, you need to rapidly and effectively get to grasp with all the code, so you can become productive and acknowledgeable with any changes that need to be done. There's some things I always do in these cases. Examining the repository Git stats I always like to start with the repository itself. Looking at the history, commits and overall activity. Many times you will find that developers are not used to providing consistent and meaningful commit messages (how many times you've seem WIP feature X commit message?). So looking at the history is not informative. So I prefer to look at global statistics instead. Assuming you will work with a git repository, the first tool I like to use is git stats. As easy as: 1 2 3 gem install git_stats cd <repo> git_stats generate Running this tool will result in a nice html document giving insights about authors, commits, files and lines of code. It's mostly informative but it's good to get an overview of the key collaborators of a project, who created, and most importantly, who deleted the most lines of code! Gource A very interesting way to see the commit history in a graphical way is gource. I always like to run it for 5 minutes just to get a feel of the rush of the project, and basically to see in a glance what are the core parts of the codebase. It also is very funny to look at, and you can get a feel what is the core part of the repository, what parts changed the most, and the number of developers working at the same time. It's available via homebrew as well so very easy to install and run: 1 2 3 brew install gource cd <repo> gource Check the available options, like seconds-per-day, to customize how you see the animation. I like to run it with 2 seco