3.2. The Wireshark Git repository

3.2. The Wireshark Git repository
Prev	Chapter 3. Work with the Wireshark sources	Next

Git is used to keep track of the changes made to the Wireshark source code. The official repository is hosted at GitLab, and incoming changes are evaluated and reviewed there. For more information on GitLab see their documentation.

Why Git? Git is a fast, flexible way of managing source code. It allows large scale distributed development and ensures data integrity.

Why GitLab? GitLab makes it easy to contribute. You can make changes locally and push them to your own work area at gitlab.com, or if your change is minor you can make changes entirely within your web browser.

Historical trivia: GitLab is the fourth iteration of our source code repository and code review system. Wireshark originally used Concurrent Versions System (CVS) and migrated to Subversion in July 2004. We migrated from Subversion to Git and Gerrit in January 2014, and from Gerrit to GitLab in August 2020.

Using Wireshark’s GitLab project you can:

Keep your private sources up to date with very little effort.
Receive notifications about code reviews and issues.
Get the source files from any previous release (or any other point in time).
Browse and search the source code using a web interface.
See which person changed a specific piece of code.

3.2.1. Git Naming Conventions

Like most revision control systems, Git uses branching to manage different copies of the source code and allow parallel development. Wireshark uses the following branch naming conventions:

master. Main feature development and odd-numbered development releases.

release-x.y, master-x.y. Stable release maintenance. For example, release-3.4 is used to manage the 3.4.x official releases.

Tags for major releases and release candidates consist of a “v” followed by a version number such as “v3.2.1” or “v3.2.3rc0”. Major releases additionally have a tag prefixed with “wireshark-” followed by a version number, such as “wireshark-3.2.0”.