However, this workflow makes merge conflicts more likely. If there are no conflicts, you can safely merge these commits. If you continue to work on the head branch, then create a new pull request between the two branches, the pull request will include all of the commits since the common ancestor, including commits that you squashed and merged in the previous pull request. When you squash and merge the pull request, GitHub creates a commit on the base branch that contains all of the changes you made on the head branch since the common ancestor commit.īecause this commit is only on the base branch and not the head branch, the common ancestor of the two branches remains unchanged. When you create a pull request, GitHub identifies the most recent commit that is on both the head branch and the base branch: the common ancestor commit. If you plan to continue work on the head branch of a pull request after the pull request is merged, we recommend you don't squash and merge the pull request. Squashing and merging a long-running branch
For more information, see " Configuring commit squashing for pull requests". People with maintainer or admin access to a repository can configure their repository's default merge message for all squashed commits to use the pull request title, the pull request title and commit details, or the pull request title and description. The pull request title, followed by the pull request numberĪ list of the commit messages for all of the squashed commits, in date order The body text of the commit message for the single commit The title of the commit message for the single commit, followed by the pull request number Depending on how the repository is configured and the number of commits in the pull request, not including merge commits, this message may include the pull request title, pull request description, or information about the commits. When you squash and merge, GitHub generates a default commit message, which you can edit. If you squash these commits into one commit while merging to the default branch, you can retain the original changes with a clear Git history. Work-in-progress commits are helpful when working on a feature branch, but they aren’t necessarily important to retain in the Git history. You can use squash and merge to create a more streamlined Git history in your repository. To squash and merge pull requests, you must have write permissions in the repository, and the repository must allow squash merging. Pull requests with squashed commits are merged using the fast-forward option.
Instead of seeing all of a contributor's individual commits from a topic branch, the commits are combined into one commit and merged into the default branch. When you select the Squash and merge option on a pull request on, the pull request's commits are squashed into a single commit. To merge pull requests, you must have write permissions in the repository. The pull request is merged using the -no-ff option.
When you click the default Merge pull request option on a pull request on, all commits from the feature branch are added to the base branch in a merge commit.
0 kommentar(er)
