We use bitbucket at work.
I have an issue that I don't know how to solve.
Whenever I create a PR, bit bucket will show the diff for people to review it.
Modifications yet to be reviewed will appear in bold, whereas modifications already reviewed will appear not in bold.
If I push a commit to my branch, adding new modifications, these will be displayed in bold as well.
Once nothing remains in bold, people can mark the PR as approved.
Now, the issue is: if I rebase my branch while it is under review, then all PR review history is lost.
Every modification in the branch is displayed in bold again.
That is quite annoying, especially for a big PR.
I would expect that all patches of my branch that did not cause any conflict when rebased to remain in bold; and that only the conflict resolutions to appear in bold in order to be reviewed.
But if some code changes that are totally unrelated to my own branch have been pushed to master, and I want to rebase my branch on top of master, then I would expect bitbucket to keep the PR review history.
Is this achievable?
Thanks,
Julien
Related
In my company we have the following workflow: development is done on a dev branch, once author wants to merge the changes he/she squashes the changes and create a Pull Request. If during the review turns out the rework is needed then the author adds new commits to the branch. Once everything is approved the author should squash commits and rebase the code (if needed). Then the maintainer merges the branch to the master branch, which results in one commit only to be added (plus the merge commit). This is to keep the log neat.
However occasionally the maintainer overlooks the fact the commits on the dev branch weren't squashed which results in multiple "work in progress" commits to be included in the master branch. We want to avoid the situation. The question is how to do that?
I was looking through Pull Request "merge check" plugins that could e.g. disable "Merge" button if there is more than 1 commit between source and destination branches, but so far I haven't found any.
I know we could enable automatic squashing on merge but we decided not to squash automatically. We feel it's better for us if the squash is done manually by the developer, e.g. commit message may be corrected accordingly.
Correcting the history in the master branch is also not possible due to our policy forbidding rewriting history on that branch.
I have a Bitbucket repo where the most recent changes are pushed by another developer teammate. His push is more important and I want to make sure my local is same as the latest in the repo. I have not made any changes but still Xcode shows me this warning. I am fine is all my local is overwritten. How do I do it? Should I check the box when I am pulling changes in Xcode from the BitBucket repo? Or do I need to do a git pull from terminal?
If you want to merge another branch into yours, you should always commit your changes first. When conflicts emerge, you just solve them and there you go, you are on the latest commit with your changes preserved.
If, however, you prefer rebase instead of merge - you HAVE to commit your uncommited changes first, then you can rebase on the latest commit from the other developer's branch, the nice thing about rebase is that it keeps the git history cleaner while also leading you trough the conflict solving, because it basically tries to put each commit of yours on top of the commit that you are rebasing onto, so it sort of "guides" you trough resolving conflicts as you have small chunks of code to resolve and then continue rebase.
Try to read more on this. This article summarises the difference between merge and rebase:
https://www.freecodecamp.org/news/an-introduction-to-git-merge-and-rebase-what-they-are-and-how-to-use-them-131b863785f/
In TFS, when I link a work item in a PR, the PR gets approved, merged and the a CI deployment is performed, then I bet TFS should be able to see that the linked workitem(s) have been deployed production. I shouldn't have to look into master or develop branch to see if the code I am looking for is in place.
So, when looking at that particular work item (in epic, on board, wherever) I should be able to see some kind of deployment status.
Is that an out-of-the-box feature or does that require a plugin?
Actually the "deployment status" can be checked with the linked Pull Request and commit.
Once the PR gets approved, merged and the CI deployment is performed, the code changes will be checked in. Normally we can check if the code changes are really there by navigating to the specific merged branch.
Actually, when you looking at that particular work item, you can check the linked PR and commit to know the deployment status.
When you link a work item in a PR which is not approved and
completed, then you can see that there is only a Pull
Request with the ID under the All Links tap in the work item.
Once the PR is approved and completed, you can see that there is a
commit linked to the work item.
So, when you see a corresponding Commit linked there, that means the changes are deployed. You can also double click the linked PR and commit to open them to see the change details.
What I would like to achieve is that no longer used (feature) branches in gerrit are blocked for the submission of new changes and patches.
The gerrit documentation just says how to do it, but not what the effect is (or I did not see it).
I could try to find out by running a few experiments, but that will not necessarily give me the full picture. Can someone point me to more documentation or tell me from experience and/or insight into the codebase?
Possible effects could be:
No more pushes to refs/for/deletedBranch allowed (certainly)
Branch removed from underlying git repo (I guess not)
Not yet merged changes posted to refs/for/deletedBranch disappear (hopefully not, there should be a guard against this case)
Already submitted/merged changes and their patchsets disappear from the listing of merged changes (hopefully not)
What will really happen?
I have a main branch and a dev branch in TFS. I merged changes from the main branch up into the dev branch fine. Now when I try merging up again it says there is nothing to merge.
However when I merge down from the dev branch to the main branch, it magically decides that a bunch of files have differences (which are only present in the main branch). Why does it decide this? Because TFS is comparing using the wrong changelist version from the dev branch! It is using the second to last changelist, not the latest one like I asked!
Sure I could resolve this by doing a force merge, but then every file in main would be marked as changed when it actually hasn't. What I want is for TFS to actually WORK in a logical way, does anybody know a work-around for this behaviour?
Even though this question has been asked a long time ago.
First things first, you are working on a dev branch and you have a main branch like the published one, so when you merge up to main you should get all changesets you checked in on dev branch.
If that is not the case, make sure you have nothing in pending changes to make sure you checked your changes in.
I work with a workspace for each branch not sure if you do this, make sure that you are on the workspace of the main branch and right click on dev branch and do the merge accordingly.
Hope this is what you were asking for.