We have a protected feature branch (EPIC) with pull request to master.
That feature branch has conflicts now.
To resolve conflicts we have to open a new pull request with merged master and resolved conflict based on EPIC.
When reviewing the new PR we see all changes from master (which can be really a huge amount of changes) and changes on conflicts.
What we are interested in, is just to review changes on conflicts, not the whole history from master.
Is there a way to hide all changes from master on GitHub and view only resolved conflicts?
Related
Is there any way to replace merge with rebase at GitHub PRs? I looked through protected branches settings but didn't find such option.
GitHub now (Feb. 2022) supports this:
More ways to keep your pull request branch up-to-date
The Update branch button on the pull request page lets you update your pull request's branch with the latest changes from the base branch.
This is useful for verifying your changes are compatible with the current version of the base branch before you merge.
Update your pull request branch by rebasing:
When your pull request's branch is out of date with the base branch, you now have the option to update it by rebasing on the latest version of the base branch.
Rebasing applies the changes from your branch onto the latest version of the base branch, resulting in a branch with a linear history since no merge commit is created.
To update by rebasing, click the drop down menu next to the Update Branch button, click Update with rebase, and then click Rebase branch.
Previously, Update branch performed a traditional merge that always resulted in a merge commit in your pull request branch. This option is still available, but now you have the choice.
Note: Because rebasing rewrites the history of the branch, if you are working with the branch locally, you will need to fetch it and do a hard reset to ensure your local branch matches the branch on GitHub.com.
Learn more about keeping your pull request in sync with the base branch.
I doubt github supports this, as you should never rebase a public branch. From the official git docs:
Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.
The easiest solution would be to simply use a merge. If you don't like that for any reason, you could create a new branch from main, apply the desired changes (e.g. by using git cherry-pick, or git diff in conjunction with patch), and then delete the old branch and create a new PR. If you really want to use rebase, you can do so locally and force-push the branch, but again, that's a really bad idea as it falsifies history and breaks the branch for everybody else.
I am working in my local branch-1 and my colleague works on his local branch branch-2.
He already committed and pushed the branch to his origin/develop and created a Pull request to upstream/develop. So now it is waiting for review and approving the pull request by someone else.
The problem is, in my local branch I need to edit one same file, which my colleague worked on. So my branch and his branch will containe the same file with different code. If his branch would be already in upstream, then I could merge it to my branch and resolve the conflict locally without problems.
However now it is in Pull request status waiting for review and I don't have time to wait, I need to create also my Pull request.
How and when will the conflict be solved, as the file with conflict is in both pull requests now, will git recognize it now or? As those branches are not in upstream yet.
Whichever branch is merged first, the other PR will have a merge conflict that must be resolved. If yours is merged first, theirs will suddenly have to fix a conflict. If their PR is merged, yours will have a conflict.
The PR main page will show the conflict and won't allow it to be merged.
The other answer is the correct one, but I want to add another possible course of action.
If your two separate features need to follow (for whatever business/architecture related reasons) merging order, where branch-1/feature-1 must be before branch-2/feature-2 and also at the same time, you need to create a PR for your feature, then what you need to do is rebase your branch on top of your colleagues branch and create a PR that way.
Once branch-1 is merged, then rebase branch-2 onto the latest upstream/develop. This will force you to resolve conflicts and update the PR accordingly.
I'm having an issue where GitHub doesn't automatically rebase/merge my pull requests at all, even if commits to master since the PR branch was created don't even touch the same files the PR itself touches, so there aren't any merge conflicts at all.
I know this is possible in GitHub, I've encountered a few repositories myself where PRs don't require a rebase and merge conflicts are automatically resolved.
The repository in question is here.
I've tried going through the project settings but I cannot seem to find a setting that says that this is an issue. Also, if I rebase my PRs manually, it usually happens automatically without me being prompted to resolve any conflics.
This is configured in the required status checks section, found in Settings → Branches → Protected Branches. The relevant setting is "Require branches to be up to date before merging".
If this feature is enabled, and status checking is set to "strict" (it is by default), then
you'll need to bring the head branch up to date after other collaborators merge pull requests to the protected base branch.
I have a forked a repo on GitHub. I have a master on this fork so that I can branch features separately and do pull requests to the upstream/master per feature. The only time my master changes is when the origin changes, meaning I don't merge my features into my master. I have updated my master from the origin and I now need to merge those changes into one of my feature branches.
The problem I am encountering is that I seem to have about 40 Unstaged files in my master branch. There appears to be 2 to 3 of each file marked: ~Automatic Revision, ~HEAD, or ~HEAD_0.
I am not terribly familiar with Git, though the basic concepts seem to be straight forward. I think most of my issues are me not understanding how sourcetree works.
First, Why would there be Unstaged/Uncommitted changes immediately after checking out my master?
Second, How can I be sure I am merging a complete copy of my master to my feature branch so that I am not unnecessarily altering files that are not part of my feature changes while issuing my pull request from my feature branch back to the upstream/master?
Resolved by deleting and re-cloning master branch.
I've found a repository on GitHub I would like to fork - but not the current version.
I want to fork the repo as it was quite a few commits back - is this possible? The repo has not marked any releases, so I'm not sure how to do this. I could obviously copy the code as it was in that commit, but I would prefer to fork, as then I get the link back to the original repo.
You can only fork the current repository.
You can reset the forked repository's master branch to an earlier commit though, making it look like as if you had forked it at that point.
See: How can I rollback a github repository to a specific commit?
If you reset every branch, it effectively resets your repository to an earlier state of the original repository (with exception of branch-independent data, like configuration, hooks etc which are not reset). Since it's possible that not all branches contain the commit from the master branch, you might need to look up commits by date for each branch, to reset them to the last commit before the commit from which you want to fork.
I was also unable to do this using github, but Sourcetree handled it perfectly.
Switched to the desired branch.
Found the commit that I wanted as the head of my new branch and right clicked.
Selected "branch."
My commit was already selected.
Name this new branch, create, and push.
Can also be done by selecting the "branch" button.
You then select the commit that you want as your new head, give it a name, and create it.