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.
Wanna know how to update feature branch with respect to base branch (i.e. development)
I don't wanna use commands; so that's why I prefer Github Desktop
Suppose I have the following branches
master
development
API-Integration
Now I have finished my changes on the API-Integration branch and if someone committed changes on the development branch, then how can I update my feature branch (API-Integration) ;
We can use the below steps. Adding the link with screenshot as well for your reference.
In GitHub Desktop, click Current Branch.
Click Choose a branch to merge into BRANCH.
Click the branch you want to merge into the current branch, then click Merge BRANCH into BRANCH.
Github desktop merge branches
We're new to branching and our solution has recently been converted into branches. We have three of them: DEV -> QA -> RELEASE.
We have set up our Release build definition which builds $/OurCollection/TeamProject/Release. After build, in the associated changesets there were changesets that are checked in DEV and changesets merged from DEV into QA. None of this changeset were merged into Release branch. That they show in the associated changesets is quite a surprise. Is this an intended feature which I'm not aware of or did we set up our build wrongly?
I would appreciate any insight into this matter. This is important info since we plan to use associated changesets to build release notes and now there are thing that are not in a build.
You need to make sure you just mapped the branch Release in Workspace mappings. Check the screenshot below:
If you mapped all branches or the whole team project, then changesets in other branches will be associated.
Let’s say branch A is a created from trunk. The branch A is in testing stage. Now there is a new project and will be release after branch A. However the project must start and cannot wait the branch A to be released. There is a big change in branch A and branch B is a few changes. I want to create a branch B from branch A. When branch A is release, it merge to the trunk. After branch B is completed and released, the branch B merge to the branch A and then Branch A merge back to trunk. Is it possible in TFS to merge trunk as the above approach?
TFVC branches are hierarchal. You can do a baseless merge, but that typically indicates a failure in your branching strategy.
The "modern" approach is to minimize the number of branches you create (or eliminate branches entirely) and instead rely on feature toggles to isolate work-in-progress, so that your codebase is always integrated.
We are using the release number for TFS branches. I have just created a new TFS branch with an upcoming release number. However, the client has since changed the release number which we would like to keep parallel TFS branch name.
The branch is new and no changes have been made to it yet.
What issues I can expect if I rename the branch?
Is it better to create new branch from main with the new release number?
A rename is a branch+delete under the covers.
You would be best creating a new branch with in tact history.