Amazon CodeCatalyst is no longer open to new customers. Existing customers can continue to use the service as normal. For more information, see [How to migrate from CodeCatalyst](migration.md). # Reviewing code with pull requests in Amazon CodeCatalyst A pull request is the primary way you and other project members can review, comment on, and merge code changes from one branch to another. You can use pull requests to review code changes collaboratively for minor changes or fixes, major feature additions, or new versions of your released software. If you use issues to track work on your project, you can link specific issues to pull requests to help you track what issues are being addressed by the code changes in the pull request. When you create, update, comment on, merge, or close a pull request, an email is automatically sent to the author of the pull request as well as any required or optional reviewers for the pull request. **Tip** You can configure what pull request events you that will receive emails about as part of your profile. For more information, see [Sending Slack and email notifications from CodeCatalyst](notifications-manage.md). Pull requests require two branches in a source repository: a source branch that contains the code that you want reviewed, and a destination branch, where you want to merge the reviewed code. The source branch contains the AFTER commit, which is the commit that contains the changes you want to merge into the destination branch. The destination branch contains the BEFORE commit, which represents the state of the code before the pull request branch is merged into the destination branch. **Note** While you are creating a pull request, the difference displayed is the difference between the tip of the source branch and the tip of the destination branch. Once you create the pull request, the displayed difference will be between the revision of the pull request you choose and the commit that was the tip of the destination branch when you created the pull request. For more information about differences and merge bases in Git, see [git-merge-base](https://git-scm.com/docs/git-merge-base) in the Git documentation. While a pull request is created for a specific source repository and branches, you can create, view, review, and close them as part of working with your project. You do not have to view the source repository in order to view and work with pull requests. A pull request state is set to **Open** when you create it. The pull request remains open until you either merge it in the CodeCatalyst console, which changes the state to **Merged**, or close it, which changes the state to **Closed**. When your code has been reviewed, you can change the pull request state in one of several ways: + Merge the pull request in the CodeCatalyst console. The code in the source branch of the pull request will be merged into the destination branch. The pull request status will change to **Merged**. It can't be changed back to **Open**. + Merge the branches locally and push your changes, and then close the pull request in the CodeCatalyst console. + Use the CodeCatalyst console to close the pull request without merging. This will change the status to **Closed**, and it will not merge the code from the source branch into the destination branch. Before you create a pull request: + Commit and push the code changes you want reviewed to a branch (the source branch). + Set up notifications for your project, so other users can be notified about any workflows that run when you create a pull request. (This step is optional but recommended.) **Topics** + [ # Creating a pull request ](pull-requests-create.md) + [ # Viewing pull requests ](pull-requests-view.md) + [ # Managing requirements for merging a pull request with approval rules ](source-pull-requests-approval-rules.md) + [ # Reviewing a pull request ](pull-requests-review.md) + [ # Updating a pull request ](pull-requests-update.md) + [ # Merging a pull request ](pull-requests-merge.md) + [ # Closing a pull request ](pull-requests-close.md) # Creating a pull request Creating pull requests helps other users see and review your code changes before you merge them into another branch. First, you create a branch for your code changes. This is referred to as the source branch for a pull request. After you commit and push changes to the repository, you can create a pull request that compares the contents of the source branch to the contents of the destination branch. You can create a pull request in the Amazon CodeCatalyst console from a specific branch, from the pull requests page, or from the project overview. Creating a pull request from a specific branch automatically provides the repository name and source branch on the pull request creation page. When you create a pull request, you will automatically receive emails about any updates to the pull request, as well as when the pull request is merged or closed. **Note** While you are creating a pull request, the difference displayed is the difference between the tip of the source branch and the tip of the destination branch. Once the pull request has been created, the displayed difference will be between the revision of the pull request you choose and the commit that was the tip of the destination branch when you created the pull request. For more information about differences and merge bases in Git, see [git-merge-base](https://git-scm.com/docs/git-merge-base) in the Git documentation. You can use the **Write description for me** feature when creating pull requests to have Amazon Q automatically create a description of the changes contained in a pull request. When you choose this option, Amazon Q analyzes the differences between the source branch that contains the code changes and the destination branch where you want to merge these changes. It then creates a summary of what those changes are, as well as its best interpretation of the intent and effect of those changes. This feature is only available in the US West (Oregon) Region for CodeCatalyst pull requests. The **Write description for me** feature is not available for pull requests in linked repositories. **Note** **Powered by Amazon Bedrock**: AWS implements [automated abuse detection](https://docs.aws.amazon.com//bedrock/latest/userguide/abuse-detection.html). Because the **Write description for me**, **Create content summary**, **Recommend tasks**, **Use Amazon Q to create or add features to a project**, and **Assign issues to Amazon Q** feature with Amazon Q Developer Agent for software development features are built on Amazon Bedrock, users can take full advantage of the controls implemented in Amazon Bedrock to enforce safety, security, and the responsible use of artificial intelligence (AI). **To create a pull request** 1. Navigate to your project. 1. Do one of the following: + In the navigation pane, choose **Code**, choose **Pull requests**, and then choose **Create pull request**. + On the repository home page, choose **More**, and then choose **Create pull request**. + On the project page, choose **Create pull request**. 1. In **Source repository**, make sure that the specified source repository is the one that contains the committed code. This option only appears if you did not create the pull request from the repository's main page. 1. In **Destination branch**, choose the branch to merge the code into after it is reviewed. 1. In **Source branch**, choose the branch that contains the committed code. 1. In **Pull request title**, enter a title that helps other users understand what needs to be reviewed and why. 1. (Optional) In **Pull request description**, provide information such as a link to issues or a description of your changes. **Tip** You can choose **Write description for me** to have CodeCatalyst automatically generate a description of the changes contained in the pull request. You can make changes to the automatically generated description after you add it to the pull request. This functionality requires that generative AI features are enabled for the space and is not available for pull requests in linked repositories. For more information, see [Managing generative AI features](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-generative-ai-features.html). 1. (Optional) In **Issues**, choose **Link issues**, and then either choose an issue from the list or enter its ID. To unlink an issue, choose the unlink icon. 1. (Optional) In **Required reviewers**, choose **Add required reviewers**. Choose from the list of project members to add them. Required reviewers must approve the changes before the pull request can be merged into the destination branch. **Note** You cannot add a reviewer as both a required reviewer and an optional reviewer. You cannot add yourself as a reviewer. 1. (Optional) In **Optional reviewers**, choose **Add optional reviewers**. Choose from the list of project members to add them. Optional reviewers do not have to approve the changes as a requirement before the pull request can be merged into the destination branch. 1. Review the differences between the branches. The difference displayed in a pull request is the changes between the revision in the source branch and the merge base, which is the head commit of the destination branch at the time the pull request was created. If no changes display, the branches might be identical, or you might have chosen the same branch for both the source and the destination. 1. When you are satisfied that the pull request contains the code and changes you want reviewed, choose **Create**. **Note** After you create the pull request, you can add comments. Comments can be added to the pull request or to individual lines in files as well as to the overall pull request. You can add links to resources, such as files, by using the @ sign followed by the name of the file. **To create a pull request from a branch** 1. Navigate to the project where you want to create a pull request. 1. In the navigation pane, choose **Source repositories**, and then choose the repository that contains the branch where you have code changes to review. 1. Choose the drop-down arrow next to the default branch name, and then choose the branch you want from the list. To view all the branches for a repository, choose **View all**. 1. Choose **More**, and then choose **Create pull request**. 1. The repository and the source branch are preselected for you. In **Destination branch**, choose the branch where you will merge the code once it has been reviewed. In **Pull request title**, enter a title that will help other project users understand what must be reviewed and why. Optionally, provide more information in **Pull request description**, such as pasting in a link to related issues in CodeCatalyst, or adding a description of the changes you made. **Note** Workflows that are configured to run for pull request create events will run after the pull request is created, if the destination branch for the pull request matches one of the branches specified in the workflow. 1. Review the differences between the branches. If no changes are displayed, the branches might be identical, or you might have chosen the same branch for both the source and the destination. 1. (Optional) In **Issues**, choose **Link issues**, and then either choose an issue from the list or enter its ID. To unlink an issue, choose the unlink icon. 1. (Optional) In **Required reviewers**, choose **Add required reviewers**. Choose from the list of project members to add them. Required reviewers must approve the changes before the pull request can be merged into the destination branch. **Note** You can't add a reviewer as both required and optional. You can't add yourself as a reviewer. 1. (Optional) In **Optional reviewers**, choose **Add optional reviewers**. Choose from the list of project members to add them. Optional reviewers do not have to approve the changes before the pull request can be merged into the destination branch. 1. When you are satisfied that the pull request contains the changes that you want reviewed and includes the required reviewers, choose **Create**. If you have any workflows configured to run where the branch matches the destination branch in the pull request, you will see information about those workflow runs in **Overview** in the **Pull request details** area after the pull request is created. For more information, see [Adding triggers to workflows](workflows-add-trigger-add.md). # Viewing pull requests You can view pull requests for a project in the Amazon CodeCatalyst console. The project summary page displays all open pull requests for a project. To view all pull requests regardless of state, navigate to the pull requests page for your project. When viewing a pull request, you can choose to have a summary of all comments left on changes to the pull request created for you. **Note** **Powered by Amazon Bedrock**: AWS implements [automated abuse detection](https://docs.aws.amazon.com//bedrock/latest/userguide/abuse-detection.html). Because the **Write description for me**, **Create content summary**, **Recommend tasks**, **Use Amazon Q to create or add features to a project**, and **Assign issues to Amazon Q** feature with Amazon Q Developer Agent for software development features are built on Amazon Bedrock, users can take full advantage of the controls implemented in Amazon Bedrock to enforce safety, security, and the responsible use of artificial intelligence (AI). **To view open pull requests** 1. Navigate to the project where you want to view pull requests. 1. On the project page, open pull requests are displayed, including information about who created the pull request, what repository contains the branches for the pull request, and the date the pull request was created. You can filter the open pull request view by source repository. 1. To view all pull requests, choose **View all**. You can use the selectors to choose between the options. For example, to view all pull requests, choose **Any status** and **Any author**. Alternatively, in the navigation pane, choose **Code**, and then choose **Pull requests**, and then use the selectors to refine your view. 1. On the **Pull requests** page, you can sort pull requests by ID, title, status, and more. To customize what information and how much information is displayed on the pull requests page, choose the gear icon. 1. To view a specific pull request, choose it from the list. 1. To view the status of workflows runs associated with this pull request, if any, choose **Overview** and review the information in the **Pull request details** area of the pull request under **Workflow runs**. A workflow run will occur if the workflow is configured with pull request create or revision events, and if the destination branch requirements in the workflow match the destination branch specified in the pull request. For more information, see [Adding triggers to workflows](workflows-add-trigger-add.md). 1. To view linked issues, if any, choose **Overview** and review the information in the **Pull request details** under **Issues**. If you want to view a linked issue, choose its ID from the list. 1. (Optional) To create a summary of comments left on the code changes in revisions of the pull request, choose **Create content summary**. The summary will not include any comments left on the overall pull request. **Note** This functionality requires that generative AI features are enabled for the space, is not available for linked repositories, and is only available in the US West (Oregon) Region. For more information, see [Managing generative AI features](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-generative-ai-features.html). 1. To view the code changes in the pull request, choose **Changes**. You can quickly view how many files have changes in the pull request, and what files in the pull request have comments on them, in **Files changed**. The number of comments shown next to a folder indicates the number of comments on files in that folder. Expand the folder to view the number of comments for each file in the folder. You can also view any comments left on specific lines of code. **Note** Not all changes in a pull request can be displayed in the console. For example, you cannot view Git submodules in the console, so you cannot view differences in a submodule in a pull request. Some differences might be too large to display. For more information, see [Quotas for source repositories in CodeCatalyst](source-quotas.md) and [Viewing a fileViewing the history of changes to a file](source-files-view.md). 1. To view quality reports for this pull request, choose **Reports**. **Note** A workflow must be configured to generate reports in order for them to show up in your pull requests. For more information, see [Testing with workflowsTesting with workflows](test-workflow-actions.md). # Managing requirements for merging a pull request with approval rules When you create a pull request, you can choose to add required or optional reviewers to that individual pull request. However, you can also create requirements that all pull requests must meet when merging to a specific destination branch. These requirements are called approval rules. Approval rules are configured for branches in a repository. When you create a pull request whose destination branch has an approval rule configured for it, the requirements for that rule must be met in addition to approvals from any required reviewers before you can merge the pull request to that branch. Creating approval rules can help you maintain quality standards for merges to branches such as your default branch. Approval rules that are applied to the default branch of your source repository will behave a little differently than approval rules applied to other branches. Any rule applied to the default branch will be automatically applied to any branch you specify as the default branch. The branch that was formerly set as the default branch will still keep the rules applied to it. When you create approval rules, you should consider how that rule will be met by your project users both in the present and in the future. For example, if you have six users in your project, and you create an approval rule that requires five approvals before it can be merged to the destination branch, you have effectively created a rule that requires everyone except the person who created the pull requets to approve that pull request before it can be merged. **Note** You must have the Project administrator role to create and manage approval rules in CodeCatalyst projects. You cannot create approval rules for linked repositories. You cannot delete approval rules, but you can update them to require zero approvals, which effectively removes the rule. **To view and edit approval rules for destination branches for pull requests** 1. Navigate to the project where your repository resides. 1. Choose the name of the repository from the list of source repositories for the project. Alternatively, in the navigation pane, choose **Code**, and then choose **Source repositories**. Choose the repository where you want to view approval rules. 1. On the overview page of the repository, choose **Branches**. 1. In the **Approval rules** column, choose **View** to see the status of any rules for each branch of the repository. In **Minimum number of approvals**, the number corresponds to the number of approvals required before a pull request can be merged to that branch. 1. To create or change an approval rule, choose **Manage settings**. On the settings page for the source repository, in **Approval rules**, choose **Edit**. **Note** You must have the **Project administrator** role to edit approval rules. 1. In **Branch**, choose the name of the branch for which you want to configure an approval rule from the drop-down list. In **Minimum number of approvals**, enter a number, and then choose **Save**. # Reviewing a pull request You can use the Amazon CodeCatalyst console to collaboratively review and comment on the changes included in a pull request. You can add comments to individual lines of code in the difference between the source and destination branches, or in the difference between revisions of the pull request. You can choose to create a summary of comments left on the code changes in the pull request to help you quickly understand the feedback left by other users. You can also choose to create a Dev Environment to work on code. **Note** **Powered by Amazon Bedrock**: AWS implements [automated abuse detection](https://docs.aws.amazon.com//bedrock/latest/userguide/abuse-detection.html). Because the **Write description for me**, **Create content summary**, **Recommend tasks**, **Use Amazon Q to create or add features to a project**, and **Assign issues to Amazon Q** feature with Amazon Q Developer Agent for software development features are built on Amazon Bedrock, users can take full advantage of the controls implemented in Amazon Bedrock to enforce safety, security, and the responsible use of artificial intelligence (AI). **Tip** You can configure what pull request events you that will receive emails about as part of your profile. For more information, see [Sending Slack and email notifications from CodeCatalyst](notifications-manage.md). Pull requests show what the difference will be between the revision of the pull request and the commit that was the tip of the destination branch when you created the pull request. This is called the merge base. For more information about differences and merge bases in Git, see [git-merge-base](https://git-scm.com/docs/git-merge-base) in the Git documentation. **Tip** When working in the console, particularly if you have had a pull request open for a while, consider refreshing your browser to ensure you have the latest revision available for a pull request before you start to review it. **To review a pull request in the CodeCatalyst console** 1. Navigate to your project. 1. Navigate to the pull requests by doing one of the following: + If the pull request is listed on the project page, choose it from the list. + If the pull request is not listed on the project page, choose **View all**. Use the filters and sort to find the pull request, and then choose it from the list. + In the navigation pane, choose **Code**, and then choose **Pull requests**. 1. Choose the pull request you want to review from the list. You can filter the list of pull requests by typing part of its name in the filter bar. 1. In **Overview**, you can review the name and title of the pull request. You can create and view comments left on the pull request itself. You can also view the details of the pull request, including information about workflow runs, linked issues, reviewers, the author of the pull request, and feasible merge strategies. **Note** Comments left on specific lines of code appear in **Changes**. 1. (Optional) To add a comment that applies to the entire pull request, expand **Comments on pull request**, and then choose **Create comment**. 1. (Optional) To view a summary of all comments left on changes in revisions of this pull request, choose **Create comment summary**. **Note** This functionality requires that generative AI features are enabled for the space and is only available in the US West (Oregon) Region. For more information, see [Managing generative AI features](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-generative-ai-features.html). 1. In **Changes**, you can see the differences between the destination branch and the most recent revision of the pull request. If there is more than one revision, you can change what revisions are compared in the difference between them. For more information about revisions, see [Revisions](source-concepts.md#revision-concept). **Tip** You can quickly view how many files have changes in the pull request, and what files in the pull request have comments on them, in **Files changed**. The number of comments shown next to a folder indicates the number of comments on files in that folder. Expand the folder to view the number of comments for each file in the folder. 1. To change the way differences are displayed, choose between **Unified** and **Split**. 1. To add a comment to a line in the pull request, go to the line you want to comment on. Choose the comment icon that appears for that line, enter a comment, and then choose **Save**. 1. To view changes between revisions in a pull request, or between its source and destination branches, choose from the available options in **Comparing**. Comments on lines in revisions are preserved in those revisions. 1. If you’ve configured your workflow to generate a code coverage report on pull request triggers, you can view the line and branch coverage findings in the relevant pull request. To hide code coverage findings, choose **Hide code coverage**. For more information, see [Code coverage reports](test-workflow-actions.md#test-code-coverage-reports). 1. If you want to make code changes to the pull request, you can create a Dev Environment from the pull request. Choose **Create Dev Environment**. Optionally add a name for the Dev Environment or edit its configuration and then choose **Create**. 1. In **Reports**, you can view the quality reports in this pull request. If there is more than one revision, you can change what revisions are compared in the difference between them. You can filter the reports by name, status, workflow, action, and type. **Note** A workflow must be configured to generate reports in order for them to show up in your pull requests. For more information, see [Configuring quality reports in an action](test-config-action.md). 1. To view a specific report, choose it from the list. For more information, see [Testing with workflowsTesting with workflows](test-workflow-actions.md). 1. If you are listed as a reviewer of this pull request and want to approve the changes, make sure that you are viewing the most recent revision, and then choose **Approve**. **Note** All required reviewers must approve a pull request before it can be merged. # Updating a pull request You can make it easier for other project members to review code by updating the pull request. You can update a pull request to change its reviewers, its links to issues, the title of the pull request, or its description. For example, you might want to change the required reviewers for a pull request to remove someone who's away on vacation, and add someone else. You can also update a pull request with further code changes by pushing commits to the source branch of an open pull request. Each push to the source branch of a pull request in the CodeCatalyst source repository creates a revision. Project members can view the differences between revisions in a pull request. **To update the reviewers for a pull request** 1. Navigate to the project where you want to update the reviewers of a pull request. 1. On the project page, under **Open pull requests**, choose the pull request where you want to update reviewers. Alternatively, in the navigation pane, choose **Code**, choose **Pull requests**, and then choose the pull request you want to update. 1. (Optional) In **Overview**, in the **Pull request details** area, choose the plus sign to add required or optional reviewers. Choose the **X** next to a reviewer to remove them as an optional or required reviewer. 1. (Optional) In **Overview**, in the **Pull request details** area, choose **Link issues** to link an issue to the pull request, and then either choose an issue from the list or enter its ID. To unlink an issue, choose the unlink icon next to the issue you want to unlink. **To update files and code in the source branch of a pull request** 1. To update multiple files, either [create a Dev Environment](devenvironment-create.md), or clone the repository and its source branch and use a Git client or an integrated development environment (IDE) to make changes to the files in the source branch. Commit and push the changes to the source branch in the CodeCatalyst source repository to automatically update the pull request with the changes. For more information, see [Cloning a source repository](source-repositories-clone.md) and [Understanding changes in source code with commits in Amazon CodeCatalyst](source-commits.md). 1. To update an individual file in a source branch, you can use a Git client or IDE as you would for multiple files. You can also edit it directly in the CodeCatalyst console. For more information, see [Editing a file](source-files-edit.md). **To update the title and description of a pull request** 1. Navigate to the project where you want to update the title or description of a pull request. 1. The project page displays open pull requests, including information about who created the pull request, what repository contains the branches for the pull request, and when the pull request was created. You can filter the open pull request view by source repository. Choose the pull request that you want to change from the list. 1. To view all pull requests, choose **View all**. Alternatively, in the navigation pane, choose **Code**, and then choose **Pull requests**. Use the filter box or sort functions to find the pull request you want to change, and then choose it. 1. In **Overview**, choose **Edit**. 1. Change the title or description, and then choose **Save**. # Merging a pull request After your code has been reviewed and all required reviewers have approved it, you can merge a pull request in the CodeCatalyst console using a supported merge strategy, such as fast-forward. Not all merge strategies supported in the CodeCatalyst console are available as choices for all pull requests. CodeCatalyst evaluates the merge and only allows you to choose between merge strategies that are available in the console and capable of merging the source branch into the destination branch. You can also merge a pull request with your choice of Git merge strategies by running the **git merge** command on your local computer or a Dev Environment to merge the source branch into the destination branch. You can then push those changes in the destination branch to the source repository in CodeCatalyst. **Note** Merging the branch and pushing the changes in Git does not automatically close the pull request. If you have the Project administrator role, you can also choose to merge a pull request that has not yet met all the requirements for approvals and approval rules. ## Merging a pull request (console) You can merge a pull request in the CodeCatalyst console if there are no merge conflicts between the source and destination branches and if all required reviewers have approved the pull request. If there are conflicts, or if the merge can't be completed, the merge button is inactive, and a **Not mergeable** label is displayed. In that case, you must obtain approval from any required approvers, resolve conflicts locally if necessary, and push those changes before you can merge. Merging a pull request will automatically send an email to the creator of the pull request as well as any required or optional reviewers. It will not automatically close or change the status of any issues linked to the pull request. **Tip** You can configure what pull request events you that will receive emails about as part of your profile. For more information, see [Sending Slack and email notifications from CodeCatalyst](notifications-manage.md). **To merge a pull request** 1. Navigate to the project where you want to merge a pull request. 1. On the project page, under **Open pull requests**, choose the pull request you want to merge. If you do not see the pull request, choose **View all pull requests** and then choose it from the list. Alternatively, in the navigation pane, choose **Code**, choose **Pull requests**, and then choose the pull request you want to merge. Choose **Merge**. 1. Choose from the available merge strategies for the pull request. Optionally, select or deselect the option to delete the source branch after merging the pull request, and then choose **Merge**. **Note** If the **Merge** button is inactive, or you see the **Not mergeable** label, either required reviewers have not yet approved the pull request, or the pull request can't be merged in the CodeCatalyst console. A reviewer who has not approved a pull request is indicated by a clock icon in the **Pull request details** area in **Overview**. If all required reviewers have approved the pull request but the **Merge** button is still inactive, you might have a merge conflict. Choose the underlined **Not mergeable** label to see more details about why the pull request can't be merged. You can resolve merge conflicts for the destination branch in a Dev Environment or the CodeCatalyst console and then merge the pull request, or you can resolve conflicts and merge locally, and then push the commit that contains the merge to the source branch in CodeCatalyst. For more information, see [Merging a pull request (Git)](#pull-requests-merge-git) and your Git documentation. ## Override merge requirements If you have the **Project administrator** role, you can choose to merge a pull request that has not yet met all the requirements for required approvals and approval rules. This is referred to as overriding the requirements for a pull request. You might choose to do this if a required reviewer is unavailable, or if an urgent need arises to merge a specific pull request into a branch that has approval rules that cannot be met quickly. **To merge a pull request** 1. In the pull request where you want to override requirements and merge, choose the drop-down arrow next to the **Merge** button. Choose **Override approval requirements**. 1. In **Override reason**, provide details of why you are merging this pull request without it meeting the approval rules and required reviewer requirements. While this is optional, this is highly recommended. 1. Optionally choose a merge strategy, or accept the default. You can also choose to update the automatically-generated commit message with more details. 1. Select or deselect the option to delete the source branch on merge. We recommend that you retain the source branch when overriding the requirements for merging a pull request until you've had a chance to review the decision with other team members. 1. Choose **Merge**. ## Merging a pull request (Git) Git supports many options for merging and managing branches. The following commands are some of the options that you can use. For more information, see the available documentation on the [Git website](https://git-scm.com/doc). Once you have merged and pushed your changes, manually close the pull request. For more information, see [Closing a pull request](pull-requests-close.md). **Common Git commands for merging branches** | | | | --- |--- | | Merges changes from the source branch in the local repo to the destination branch in the local repo. | `git checkout destination-branch-name` `git merge source-branch-name` | | Merges the source branch into the destination branch, specifying a fast-forward merge. This merges the branches and moves the destination branch pointer to the tip of the source branch. | `git checkout destination-branch-name` `git merge --ff-only source-branch-name` | | Merges the source branch into the destination branch, specifying a squash merge. This combines all commits from the source branch into a single merge commit in the destination branch. | `git checkout destination-branch-name` `git merge --squash source-branch-name` | | Merges the source branch into the destination branch, specifying a three-way merge. This creates a merge commit and adds the individual commits from the source branch to the destination branch. | `git checkout destination-branch-name` `git merge --no-ff source-branch-name` | | Deletes the source branch in the local repo. This is useful to do as a clean-up for your local repo after merging to the destination branch and pushing the changes to the source repository. | `git branch -d source-branch-name` | | Deletes the source branch in the remote repository (the source repository in CodeCatalyst) using the local repo's specified nickname for the remote repository. (Note the use of the colon (`:`).) Alternatively, specify `--delete` as part of the command. | `git push remote-name :source-branch-name` `git push remote-name --delete source-branch-name` | # Closing a pull request You can mark a pull request as **Closed**. This does not merge the pull request, but it can help you determine which pull requests require action and which pull requests are no longer relevant. We recommend closing a pull request if you no longer plan to merge those changes, or if the changes were merged by another pull request. Closing a pull request will automatically send an email to the creator of the pull request as well as any required or optional reviewers. It will not automatically change the status of any issues linked to the pull request. **Note** You cannot re-open a pull request after it has been closed. **To close a pull request** 1. Navigate to the project where you want to close a pull request. 1. On the project page, open pull requests are displayed. Choose the pull request that you want to close. 1. Choose **Close**. 1. Review the information, and then choose **Close pull request**.