When working with and closing a pull request you have three merge options Create a merge commit, Squash and merge and Rebase and merge. I wonder how these options translate into actual Git commands - especially with regards to --no-ff
.
The merge dialog lists these two (step 1 & step 2) examples:
git fetch origin
git checkout -b develop origin/develop
git merge master
And:
git checkout master
git merge --no-ff develop
git push origin master
But I'm confused as these are the same examples for all three options. This can't be right. So I guess I just misunderstood the user interface here.
What are the commands for Git and is --no-ff
being used anywhere?
Adding a pull request to a merge queueOn GitHub.com, navigate to the main page of the repository. Under your repository name, click Pull requests. In the "Pull Requests" list, click the pull request you would like to add to a merge queue. Click Merge when ready to add the pull request to the merge queue.
In a pull request, you propose that changes you've made on a head branch should be merged into a base branch. By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch.
The most commonly used strategies are Fast Forward Merge and Recursive Merge. In this most commonly used merge strategy, history is just one straight line. When you create a branch, make some commits in that branch, the time you're ready to merge, there is no new merge on the master.
If you enable auto-merge for a pull request, the pull request will merge automatically when all required reviews are met and all required status checks have passed. Auto-merge prevents you from waiting around for requirements to be met, so you can move on to other tasks.
When working with and closing a pull request you have three merge options Create a merge commit, Squash and merge and Rebase and merge. I wonder how these options translate into actual Git commands - especially with regards to
--no-ff
.
The GitHub "make a merge" button corresponds to:
git checkout <branch>
git merge --no-ff -m <message> <commit-hash>
where the message
part is something you'd have to generate by hand, since your local Git does not know the details of the pull request (its number, and any other repository). The branch
part is your target branch: the one you want the merge commit to be on, after the merge completes.
Note that you must have the specified commit-hash
commit object in your repository at this point. GitHub's behind-the-scenes manipulation means that it is available in the Git repository on GitHub, but it's listed under a refs/pull/
reference, rather than a branch name, in that repository.
The GitHub "squash and merge" button corresponds to:
git checkout <branch>
git merge --squash <commit-hash>
git commit
with the git commit
being required because the command-line --squash
flag turns on the command-line --no-commit
flag.
The GitHub "rebase and merge" button corresponds—somewhat roughly—to:
# maybe: create a branch name (consider using git checkout -b next)
git checkout <commit-hash-or-branch-name>
git rebase <branch>
git checkout <branch>
git merge --ff-only <hash-or-name>
# maybe: delete a branch name
This is the most complicated one: the commit-hash-or-name
is either the commit hash ID that you would supply to the other two, or a branch name that identifies that commit hash ID, preferably a temporary name you just made up for the duration of this operation. The git rebase
operation must then succeed on its own—if not, GitHub itself won't offer you the ability to do a rebase-and-merge.
If the rebase operation does succeed and you chose to do it with a detached HEAD, you must now save the hash ID of the rebased commit. If you chose to do it using some temporary branch name, nothing special is required at this point.
Now that the original chain of commits has been copied by the rebase operation, now you git checkout
the branch you want to update-by-fast-forward and run the git merge --ff-only
operation. The name or hash ID you supply here is the one that the successful rebase operation either produced as the tip of the detached HEAD, or updated into the temporary branch name.
If you used a temporary branch name, you should now delete that temporary branch name.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With