/core-rules)
    * [ Governance ](/docs/latest/contribute/governance)
    * [ Report a Security Vulnerability ](/docs/latest/contribute/report-security-vulnerability)
  * [ Maintain ESLint ](/docs/latest/maintain/)
    * [ How ESLint is Maintained ](/docs/latest/maintain/overview)
    * [ Manage Issues and Pull Requests ](/docs/latest/maintain/manage-issues)
    * [ Review Pull Requests ](/docs/latest/maintain/review-pull-requests)
    * [ Manage Releases ](/docs/latest/maintain/manage-releases)
    * [ Working Groups ](/docs/latest/maintain/working-groups)

#  Submit a Pull Request

##  Table of Contents

  1. Getting Started 
  2. Working with Code 
    1. Step 1: Create a new branch 
    2. Step 2: Make your changes 
    3. Step 3: Rebase onto upstream 
    4. Step 4: Run the tests 
    5. Step 5: Double check your submission 
    6. Step 6: Push your changes 
    7. Step 7: Send the pull request 
  3. Following Up 
    1. Updating the Pull Request Title 
    2. Updating the Code 
    3. Rebasing 

If you want to contribute to an ESLint repo, please use a GitHub pull request.
This is the fastest way for us to evaluate your code and to merge it into the
code base. Please don’t file an issue with snippets of code. Doing so means
that we need to manually merge the changes in and update any appropriate
tests. That decreases the likelihood that your code is going to get included
in a timely manner. Please use pull requests.

##  Getting Started

If you’d like to work on a pull request and you’ve never submitted code
before, follow these steps:

  1. Set up a [ development environment ](./development-environment) . 
  2. If you want to implement a breaking change or a change to the core, ensure there’s an issue that describes what you’re doing and the issue has been accepted. You can create a new issue or just indicate you’re [ working on an existing issue ](./work-on-issue) . Bug fixes, documentation changes, and other pull requests do not require an issue. 

After that, you’re ready to start working on code.

##  Working with Code

The process of submitting a pull request is fairly straightforward and
generally follows the same pattern each time:

  1. Create a new branch 
  2. Make your changes 
  3. Rebase onto upstream 
  4. Run the tests 
  5. Double check your submission 
  6. Push your changes 
  7. Submit the pull request 

Details about each step are found below.

###  Step 1: Create a new branch

The first step to sending a pull request is to create a new branch in your
ESLint fork. Give the branch a descriptive name that describes what it is
you’re fixing, such as:

    
    
    git checkout -b issue1234
    
    
    1  
    

You should do all of your development for the issue in this branch.

**Note:** Do not combine fixes for multiple issues into one branch. Use a
separate branch for each issue you’re working on.

###  Step 2: Make your changes

Make the changes to the code and tests, following the [ code conventions
](./code-conventions) as you go. Once you have finished, commit the changes to
your branch:

    
    
    git add -A
    git commit
    
    
    1  
    2  
    

All ESLint projects follow [ Conventional Commits
](https://www.conventionalcommits.org/) for our commit messages. (Note: we
don’t support the optional scope in messages.) Here’s an example commit
message:

    
    
    tag: Short description of what you did
    
    Longer description here if necessary
    
    Fixes #1234
    
    
    1  
    2  
    3  
    4  
    5  
    

The first line of the commit message (the summary) must have a specific
format. This format is checked by our build tools. Although the commit message
is not checked directly, it will be used to generate the title of a pull
request, which will be checked when the pull request is submitted.

The ` tag ` is one of the following:

  * ` fix ` \- for a bug fix. 
  * ` feat ` \- either for a backwards-compatible enhancement or for a rule change that adds reported prob