Skip to main content

​
Overview

This guide walks you through the process of submitting a pull request (PR) to Minecraft Community Edition.

​
Before You Start

Before creating a pull request:
  1. Read the Contributing Guidelines
  2. Ensure your development environment is set up correctly
  3. Follow the Code Style Guide
  4. Test your changes thoroughly

​
Pull Request Template

When you create a PR, you’ll be prompted to fill out a template with the following sections:

​
What does this PR do?

Provide a clear, concise description of what your PR accomplishes: 
## What does this PR do?

Adds support for custom block rendering with transparency effects.

​
Why?

Explain the motivation behind the changes: 
## Why?

Transparent blocks were not rendering correctly in certain lighting 
conditions, causing visual artifacts. This fix ensures proper alpha 
blending for all transparent block types.

​
How to test

Provide clear steps for reviewers to test your changes: 
## How to test
- [ ] Place glass blocks in various lighting conditions
- [ ] Verify water renders correctly behind glass
- [ ] Check that stained glass colors display properly
- [ ] Test in both day and night cycles

​
Screenshots / Videos

If your changes affect visuals or gameplay, include screenshots or videos: 
## Screenshots / Videos

![Before](url-to-before-image)
![After](url-to-after-image)
Delete this section if not applicable.

​
Testing Checklist

Before submitting your PR, verify the following:
1

Builds without errors

Your code must compile successfully:
# Build the solution in Visual Studio
# or use MSBuild from command line
msbuild MinecraftConsoles.sln /p:Configuration=Release
  • Debug build succeeds
  • Release build succeeds
  • All platforms build (if applicable)
2

Tested in-game

Test your changes in the actual game:
  • Feature works as expected
  • No crashes or exceptions
  • Performance is acceptable
  • No visual glitches
  • Multiplayer compatible (if applicable)
3

No new warnings

Your changes should not introduce compiler warnings:
  • Check the build output for warnings
  • Fix any warnings your changes introduced
  • Verify existing warnings weren’t made worse
PRs that introduce new compiler warnings may be rejected.

​
Submission Guidelines

​
Code Requirements

Original Work

Your PR must be your own work. Be prepared to provide proof of ownership if requested.

AI Usage

AI assistance for bug fixes is fine, but fully AI-generated implementations are not acceptable.

Code Quality

Follow the project’s code style and maintain high code quality standards.

Testing

Thoroughly test your changes before submitting.

​
Creating the Pull Request

1

Create a feature branch

Work on a dedicated branch:
git checkout -b feature/my-new-feature
# or
git checkout -b fix/bug-description
2

Commit your changes

Make clear, atomic commits:
git add .
git commit -m "Add transparency support for custom blocks"
Use descriptive commit messages that explain what and why.
3

Push to your fork

Push your branch to GitHub:
git push origin feature/my-new-feature
4

Open the pull request

  • Navigate to the repository on GitHub
  • Click “New Pull Request”
  • Select your branch
  • Fill out the PR template completely
  • Click “Create Pull Request”

​
Review Process

Once you submit your PR:

​
What Reviewers Look For

  1. Functionality: Does it work as described?
  2. Code Quality: Is the code well-written and maintainable?
  3. Style Compliance: Does it follow the code style guide?
  4. Testing: Has it been adequately tested?
  5. Documentation: Are comments clear and helpful?
  6. Impact: Does it affect other parts of the codebase?

​
Addressing Feedback

When reviewers provide feedback:
  1. Respond promptly: Address comments in a timely manner
  2. Ask questions: If feedback is unclear, ask for clarification
  3. Make changes: Update your code based on feedback
  4. Push updates: Push new commits to the same branch
  5. Mark resolved: Mark conversation threads as resolved when addressed
# After making changes based on feedback
git add .
git commit -m "Address review feedback: improve error handling"
git push origin feature/my-new-feature

​
Automated Checks

Your PR may be subject to automated checks:
  • Build verification: Ensures code compiles
  • Warning detection: Checks for new compiler warnings
  • Code analysis: Static analysis for common issues
All checks must pass before merging.

​
Merging Criteria

Your PR will be merged when:
  • ✅ All checklist items are completed
  • ✅ Code builds without errors
  • ✅ No new warnings introduced
  • ✅ Tested in-game successfully
  • ✅ Code review approved by maintainer(s)
  • ✅ All automated checks pass
  • ✅ Conflicts resolved (if any)

​
After Merging

Once your PR is merged:
  1. Delete your branch (optional but recommended): 
    git branch -d feature/my-new-feature
git push origin --delete feature/my-new-feature
  2. Update your local repository: 
    git checkout main
git pull origin main
  3. Celebrate: Your contribution is now part of the project!

​
Common Issues

​
Merge Conflicts

If your PR has conflicts: 
# Update your branch with latest main
git checkout main
git pull origin main
git checkout feature/my-new-feature
git merge main

# Resolve conflicts, then:
git add .
git commit -m "Resolve merge conflicts"
git push origin feature/my-new-feature

​
Failed Builds

If the build fails:
  1. Check the build logs for errors
  2. Reproduce the build locally
  3. Fix the issues
  4. Push the fixes

​
Stale PRs

If your PR becomes stale:
  • Rebase on the latest main branch
  • Verify everything still works
  • Ping reviewers if needed

​
Best Practices

Each PR should address a single feature or bug. Avoid mixing unrelated changes.
Clear PR descriptions help reviewers understand your changes quickly.
The more testing you do, the faster your PR will be reviewed and merged.
Engage constructively with reviewers. Their goal is to help improve the code.
Reviewers are volunteers. It may take time to review your PR.

​
Questions?

If you have questions about the PR process:
  • Check existing PRs for examples
  • Ask in the repository discussions
  • Reach out to maintainers
Thank you for contributing to Minecraft Community Edition!

Build docs developers (and LLMs) love

Get started for freeTalk to us