Best Branching and Merging strategies in Gerrit
Step 1 – First Lets read this article about Best Branching and Merging strategies in git
Best Branching and Merging strategies in git
Step 2 – Now Lets learn the Gerrit Merge Types
Step 3 – Time to Learn the Types of Submit in Gerrit
Step 4 – Finally, You must read the recommendations below
Best Branching and Merging strategies in git
Step 1 – First you need to learn the needs of branches. This is very good read.
Step 2 – Now time has come to Learn best branching model in Git.
Step 3 – Now, Lets understand, what is the kind of merges we have in Git?
Step 4 – Are you still having a questions, Please post in the comment section.
Perforce Merging Process
In Perforce when we have conflict in files, “?” notion comes with the files which says this need to be resolved. Once you select the file and click on Resolve, it will be given following options…
1. Accept Changed file (Only one files differs from the base
2. Merge yours and theirs if no conflict exists
3. Accept yours
4. Accept theirs
5. Merge yours and theirs including conflict markers
Interactive – Interactively resolve files one at a time
Let’s try to first resolve the conflict with Auto options but if the conflict is not resolved then try to use interactive option which gives greater flexibility to resolved the conflict and submit the changes.
The merging functionality in TFSC is centered on the following typical development scenarios:
- Scenario 1: The catch-up merge— The user wants to merge all changes from a source branch that have not yet been migrated to the target branch. The source and target can be a subtree or an individual file/folder.
- Scenario 2: The catch-up no-merge— The user wants to discard nonmerged changes in the source branch from the set of candidate changes for future merges between the specified source and target.
- Scenario 3: The cherry-pick merge— The user wants to merge individual change sets from the source branch to the target branch. Changes introduced to those files prior to the specified change set should not be migrated.
- The user can specify the change sets to merge with a change set number.
- The user can specify individual file revisions to merge between the source and target.
- Scenario 4: The cherry-pick no-merge— The user wants to discard a single change set from the list of all possible changes to merge between the source and target so that this change set never appears in the list of candidates for a cherry pick merge.
- Scenario 5: Merge history query— The user wants to know whether the specified change set has been merged into the target branch. If it has, the user wants to know what change set the merge was committed in. The user also wants to know if part of the change set has been merged, but not all.
- Scenario 6: Merge candidate query— The user wants to obtain a list of change sets that have been committed to a source branch but have not yet been migrated to the target branch. From this list, the user selects change sets to migrate with a cherry pick merge.
How TFSC Addresses the Scenarios
TFSC merging is designed to provide users with an extremely powerful and flexible tool for managing the contents of branches. Merges can be made into a single file or into a tree of related files. Merges can also migrate the entire change history of the specified source files or an individual change set or revision that might contain a specific fix or feature that should be migrated without moving other changes from the source in the process. Merging the entire change history prior to a given point in time is known as a catch-up merge (Scenarios 1 and 2), whereas selecting individual change sets or revisions to merge is known as a cherry-pick merge (Scenarios 3 and 4). The merge command also allows users to query for merge history and merge candidates and perform the actual merge operation.
TFSC presents merge history and candidate merges as a list of change sets that have or can be migrated between a source and a target branch. Merges can be made to a subset of files in a change set, creating a situation in which a partial change set has been merged. In this case, TFSC represents the partial state of the merge and allows the user to finish merging the change set later.
Merges are pending changes in TFSC. The user can choose to perform several merge operations within a workspace without committing changes following each merge. All these merges can be staged in the user’s workspace and committed with a single check-in as a single change set. In addition, the pending merge operation can be combined with the checkout and rename commands to interject additional changes to the files that will be committed with the merge.
Hopefully you followed this summary and are still with me. Now let’s go into how branching works in TFSC.
Reference: The Build Master: Microsoft’s Software Configuration Management Best Practices