At my company we ask developers to squash commits on feature branches before merging into develop. Once squashed, the developer pushes to GitHub and logs into GitHub to create a pull request.
When the pull request is merged, we end up seeing two commits in the history of the develop branch:
A commit saying "merged pull request"
The single, squashed commit from the feature branch
Why does this happen? And how can we avoid it? I've read a similar Q&A about avoiding "merge commit hell" but my goal is to use the GitHub UI to create, track, and discuss pull requests.
The commit you're seeing is a merge commit; generally these are auto-created by git any time you do a non-fast-forward merge, but you can also force one to always be created. And that is what GitHub does when you use the merge button.
If you don't want merge commits, then you need to cherry-pick commits onto master instead of using the merge button. There is no way to do this within the GitHub web UI.
Edit: GitHub has now added squash and merge and rebase and merge capabilities within their web UI:
Related
I am not too familiar with GitHub, but I have a feature branch that I want to merge its current changes to master multiple times. Ideally, I want to break up the pull requests so that one pr doesn't get too long. So for example I want a pr for the frontend first. After that is merged, I will push changes for the backend and create another pr. I wanted to make sure that the same feature branch can have multiple prs to master (but there will only be one open pr).
Is this allowed in Github?
#aspiringsomeone, it is a good strategy to keep each PR incremental, self-contained and concise. However, it is good to create a new branch for new set of changes (features). In GIT, branches are just markers and don't consume too much space/resources. After your PR is merged, you can delete the branch and create a new branch for next PR.
In your case, first branch could be feature1_frontend (Hopefully, these changes don't depend on backend or somehow disabled until backend changes are ready). After PR_1 is merged, you can create feature1_backend branch and use it for next PR, say PR_2. As and when PR review is complete and it is merged, you can delete corresponding branches and move on.
Ideally, pull requests should be independent.
Do not keep a long-lived feature branch on hand and keep merging it (the same branch). That is a good way to end up with a zillion merge conflicts. You should always delete a PR branch as soon as it is merged.
But don't worry. If one pull request has to depend on another, there's a much better approach: In GitHub you can actually open multiple PRs that stem from one another, and that's probably the way to proceed here. So:
Branch off of your main branch to form feature1 and push it and open a PR asking to merge to the main branch.
Branch off of feature1 to form feature2 and push it and open a PR asking to merge to feature1.
Branch off of feature2 to form feature3 and push it and open a PR asking to merge to feature2.
Here's the cool part. When feature1 is approved and merged to the main branch, GitHub will automatically rebase the feature2 PR so that it is now asking to merge to the main branch, which is just what you want. And so on.
When I work on my branch, my pushes don't show up on GitHub, so the pushes don't turn GitHub progress graph boxes green. When I work in the main branch, everything is fine. Could somebody please help me?
You need to merge your branch with the main branch. Or push both branches to github and make a pull request and merge the branches on github.
To push all your branches to github:
git push -u --all
now all your branches should appear
After you pushed all your branches you can use a pull request to merge the 2 branches.
Cick on New pull request.
From the dropdowns select the branches you want to merge. And then click create pull request. A message box will appear. Write the commit message you want and click again Create pull Request.
After you have created the pull request
If you have no code conflicts. You should see the picture above. If there are code conflicts you need to either resolve them in your IDE or via the command line.
If you want to merge branches without pushing to github here is a useful link.
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
I'm trying to create a Pull Request in GitHub repository from one branch to another branch. On completing the Pull Request, I see 2 commits being added:
Is there a way to get rid of the commit "Merge pull request from ..." via settings?
In ADO repository, there is an option to "Rebase and fast-forward" to get rid of that commit. Is there something similar in GitHub?
Thank you!
When merging a pull request on GitHub, you have 3 options when you click on the drop down button beside the button to merge the PR:
Create a merge commit
Squash and merge
Rebase and merge
While the first one is selected by default, you can choose the 2nd or 3rd option in case you want to avoid the merge commit as mentioned in your question.
All the 3 options are also explained in detail in this GitHub documentation.
In the spirit of testing the "there are no dumb questions" theory, why does Github's squash-and-merge strategy update the committer after merging a pull request?
That is, suppose I author a pull request in my fork of a project. Suppose it has two commits in it. Suppose I ask the project maintainer to now merge my pull request to master of the upstream project.
Suppose she chooses the squash-and-merge strategy so that there will be one commit at the end.
Suppose further that the merge can be accomplished via a fast-forward, i.e. as simple as possible a case as I can think of. (Fast-forward merges should just update the branch pointer, which seems to me like it would leave the commit completely unchanged.)
Why is it, then, that the latest commit on master after the squash and merge operation features me as the author (I understand that part) but the maintainer as the committer? Isn't that an alteration of a commit, and doesn't squashing and fast-forward merging ensure that commits are not altered?
Is Github silently doing the equivalent of something like git amend under the covers?
Isn't that an alteration of a commit
More than an alteration: a creation of a new commit, which reflect the changes of your two commits.
And your two commits are no longer referenced by the main repo: it references only the squashed commit.
That new commit has still you as an author, but is committed by the maintainer.
I was working only on my master branch (silly, I know!) and I pushed the commit to my repo and then opened a pull request against upstream.
Someone wanted me to fix this commit so I've done it and made another commit with pull request but now, there is pull request with 2 commits - how merge that commits together?
if I understand correctly (not entirely sure) the word you are looking for is "squash":
Squash my last X commits together using Git