This quick start provides a brief overview of how Zulip uses Git and GitHub.

Those who are familiar with Git and GitHub should be able to start contributing
with these details in mind:

We use GitHub for source control and code review. To contribute, fork
zulip/zulip (or the appropriate
repository, if you are working on something else besides
Zulip server) to your own account and then create feature/issue branches.
When you’re ready to get feedback, submit a work-in-progress (WIP) pull
request. We encourage you to submit WIP pull requests early and often.

We use a rebase-oriented workflow. We do not use merge
commits. This means you should use gitfetch followed by gitrebase
rather than gitpull (or you can use gitpull--rebase). Also, to prevent
pull requests from becoming out of date with the main line of development,
you should rebase your feature branch prior to submitting a pull request, and
as needed thereafter. If you’re unfamiliar with how to rebase a pull request,
read this excellent guide.

We use this strategy in order to avoid the extra commits that appear
when another branch is merged, that clutter the commit history (it’s
popular with other large projects such as Django). This makes
Zulip’s commit history more readable, but a side effect is that many
pull requests we merge will be reported by GitHub’s UI as closed
instead of merged, since GitHub has poor support for
rebase-oriented workflows.

We use zulipbot to manage our issues and
pull requests to create a better GitHub workflow for contributors.

We provide some handy Zulip-specific Git scripts
for developers to easily do tasks like fetching and rebasing a pull
request, cleaning unimportant branches, etc. These reduce the common
tasks of testing other contributors’ pull requests to single commands.

The following sections will help you be awesome with Zulip and Git/GitHub in a
rebased-based workflow. Read through it if you’re new to git, to a rebase-based
git workflow, or if you’d like a git refresher.