We have a simple branch process where we have a Main branch which is meant to be the source code used in production. We also have one or more branches from Main which are development branches.
We have emergency fixes that go into Main but may not be in one or more of the development branches. From time to time, and especially just before we promote a development branch to Main we merge from Main to the development branch to make sure everything from Main is in the branch. This time it was all there so no action was necessary.
We then merged from the development branch to Main, naturally it identified all the files we had changed in the development branch, but it also came up with a small number of conflicts. Now as we had just successfully merged from Main to the branch I did not expect this.
Investigation showed the following history for one of the files that had a conflict.
In Main
In development branch
It seemed a fix was made in the development branch (10917) and then merged to Main (11090).
For some reason when we merge down to the branch the previous merge up (11090) is not detected and so is shown as a conflict when we try and merge to Main.
In practice the code in both branches is the same but it causes extra work with us having to investigate changes that are not there.
Can not see why this did not merge down? Is our process at fault?
I think this is caused by you didn't get latest of main branch before you try to merge to development branch. Make sure you have get latest both of main and development branch before the merge.
Next time, you can directly merge specific changest, you can select selected changesets then choose 11090.
Related
I'm working with git flow and a doubt arouse about the master branch. I have development and user acceptance working on develop branch and when I finish the test, I merge the develop with master branch and put into production. My question is if something goes wrong after this merge with master branch, I will not have tested it. What should I do to have the master branch tested? How to ensure that the master is not broken? Is there any pattern?
tl;dr: No, you already tested it.
Details:
In a properly implemented Git-Flow strategy, anything you merge into master should be fully ahead of master 1, so you would never need to test what you'll get after merging into master, as it will be the identical state before and after the merge. (And presumably you have fully tested the branch before merging into master!) The reason this is true is that when hotfix branches are merged into master, they should be immediately merged back down into develop too (or into a release branch if one currently exists). This means there should never be any code that is only on master and not yet in the branch you're about to merge into master. As documented by Git Flow regarding completing hotfix branches:
When finished, the bugfix needs to be merged back into master, but also needs to be merged back into develop, in order to safeguard that the bugfix is included in the next release as well. This is completely similar to how release branches are finished.
And also,
The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop.
Side Note: You mentioned that you are merging develop directly into master, and you can do that if it's working for you, but I just want to point out that typically in Git Flow you use a release branch instead. Doing so enables simultaneous development on develop while you are hardening a release as it awaits deployment. Here's a question that discusses this, and my answer there provides some tips for how to avoid creating release branches in Git Flow, if you normally don't need them.
1 In Git we oftentimes say that one branch is "fully ahead" of another branch when the first branch can reach the tip commit of the second branch. For example, develop is ahead of master if the tip commit of master is in the history of the develop branch. In this case however what we actually mean is that all commits with state changes in master are present on develop, and this distinction exists only because of the --no-ff requirement when merging into master, so it's possible that master might have some merge commits that don't yet exist on develop. Those merge commits do not contain any new state though, so we can say from a practical point of view that develop is fully ahead of master.
From a purity standpoint, my personal preference is to always have every commit on master be present in develop or release before merging into master, so that we can say "fully ahead" and mean it from a commit ID standpoint as well. To achieve this, you can slightly tweak the documented Git Flow by, instead of merging release and hotfix branches back to develop after merging into master, merge master back down into develop. This achieves the identical state but also achieves the "fully ahead" meaning that we like to see in Git. It also means anytime you merge anything into master, you could do a fast forward merge, but we choose to use --no-ff instead to maintain a historical record of when the merge occurred, and exactly what was merged. Using this tweak, the fact that you could have done a fast-forward merge is the proof you need that you don't have re-test master after the merge.
If the master branch changed since you forked the develop branch, you certainly could break master after merging develop (especially if you had to sift through merge conflicts), even if develop was working fine on its own. The way to make sure that master isn't broken after merging is to have good unit tests for master to make sure no existing functionality is broken, and then add and run additional unit tests for develop which test the new feature works after its merged.
We have a main work branch that is a child of the Production branch. All work is done in the work branch (or below) and merged in to Production only when we release code. We recently found that there are changesets missing from our Production branch that should have been merged in months ago. But we've merged the work branch in to Production several times since then. I don't know how many changesets are missing, but we are about to have a release and I would like to use this chance to fix this.
Is there a way to overwrite a parent branch (similar to when you overwrite your local copy with latest from source)?
I know I can force changesets, but that requires knowing what changesets to force. Is there a way to identify differences in the changesets included in two branches?
My last resort is to nuke the parent branch and just create a new one, but that seems heavy handed and really isn't ideal.
I have the Development branch forked from the Main branch.
Could I merge the Development branch back to the Main so that Main branch code would be equal the Development branch?
What is the most safe and reliable solution for this?
The easiest way I've found to do this is to do a merge using Visual Studio and the Source Control Explorer.
In the Source Control Explorer, right-click on your development branch and select Branching and Merging > Merge
In the Target Branch drop-down select your trunk ("Main") as the destination. This is likely the default selection if you've branched from Main originally.
There are two options:
All changes up to a specific versions: You choose based on a revision and merge it all up to that revision in one fell swoop. If you have a lot of changes, this can save you some time, but also is riskier in terms of resolving conflicts if there have been a lot of changes in Main.
Selected changesets: You select single or groups of changesets to merge back and then repeat this process until you've merged back what you need. Less risky option, but much more time consuming. I personally prefer this approach so that I can see the changes going back into the trunk and know what to expect as changes.
TFS will instruct you if there are merge conflicts while you are merging. This occurs when you change something in the trunk after you've branched to your development. If one of the changes you've made in development conflict with the changes you've made in the trunk, you will have the chance to resolve this in Visual Studio.
If you do not have any conflicts, your development changes will move into the Trunk and simply merge with the changes you already have there.
I admit one work place they merged the Trunk to the Branches, but its not supposed to work that way.
The generally accepted method is merge the Branch back into the Trunk.
It sounds like you are working in the Trunk ("I can create some additional folder or additional files in the trunk") and wanting to merge into the Branch.
I recommend doing it the standard way: only work in Branches merging back to the Trunk, never coding directly in the Trunk.
I have main and dev branches. I make changes in both and check in. I merge from main to dev and check in. Now I merge from dev to main. I have conflicts. How is this possible?
Resolving a conflict for a merge in one direction is not necessarily appropriate for a merge in another direction. In many workflows you're basically merging in order to keep two branches as similar as possible - for example, taking changes from a development branch into a production branch, and maybe moving critical bugfixes from the production branch back to a development branch. In this sort of workflow, you typically wouldn't want to diverge when merging two branches (you want that critical bugfix in both branches, after all) so it's not obvious why you would have to resolve the merge conflict both times, but that's certainly not the only workflow when working with branches.
I used to work on a Java project that had some utility libraries that we shared with a group working on a different project. At some point, our libraries needed to diverge from theirs for various reasons, so we took a branch of their project and both groups made unique changes to the library. Sometimes it happened that we would fix a bug and sometimes it would happen that they would add a new feature, so we frequently merged back and forth with each other.
You can see here that the results of merging from our branch to theirs should not necessarily be the results of merging from their branch to ours. Let's assume that there was a file where we added some new methods and maybe fixed a few bugs. And let's assume that they'd added a few different methods. When they merged our changes into their branch, they'd get a merge conflict and let's assume they took the bugfixes but did not take our new methods since they didn't need them. Now when we do a merge to get their changes into our branch, we still get a merge conflict - this allows us to take their methods into our file.
If TFS were to make some assumption about the merge from their branch into ours based on the results from our branch into theirs, it would be inaccurate.
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.