- 2Installing Flosum
- 3Setting up Flosum integration user
- 4Connecting sandboxes to Flosum
- 5Setting up users in Flosum
- 6Setting org permissions
- 7Decide on naming convention
- 8Initialize the repository
- 9Setting up workflow permissions Application Development Flow
- 10Pulling changes from dev sandboxes
- 11Branching strategy
- 12Conflict and Merge strategy
- 13Static Code Analysis
- 15Regression testing
- 16Reference Architecture Integrations
- 18TFS/Azure Devops
- 19Git Integrations Compliance & Governance
- 20Compliance & Governance
Flosum uses a distributed version control so that multiple developers can simultaneously edit the same component. Thus, temporary or partial edits by one person do not interfere with another person's work.
Flosum integrates work done simultaneously by different team members. In most cases, edits to different files or even the same file can be combined without losing any work. In rare cases, if two people make conflicting edits to the same line of a file, then the version control system requests human assistance in deciding what to do.
When a user commits the changes to the repository or merges branches, the changes are automatically categorized by the version control.
The changes are categorized as:
1. "Components that will not be committed": If the user is committing the same version of the component that is already in the version control, it will categorize the component in this section.
2. "Components that are safe to commit": If the user is committing a new component or if both the component versions are changed by same person (Autoresolved), then it is categorized as a component that is safe to commit.
3. "Components that have conflicts": If another user has committed changes to the same component that the current user is committing, then the component shows in the conflict section.
Figure 1: Committing changes to the repository
Flosum allows you to edit the components inline and make changes to the components before committing them to the repository. The user can look at the older version of the components and review it side-by-side with the newer version of the component.
The legend will show green or red to indicate whether the line has been added or removed.
The lines/text can be moved from right to left or removed from the left version depending on the user's needs.
Once you are done making changes, click "Save" to accept the changes and commit them to the target. The Saved changes are moved to the target on commit but are not saved in the source by default. We can use the "Save Merged component on source branch" option to also save the changes to source branch. (Please refer to screenshot below.)
If you don't want to go into each conflict and merge it, you can select the "Force commit(commit the version to Repository as-is)" option shown in the screenshot below. This will change all the conflicts to merged status and move the code that is in the source branch as a new version to the target.
In order to change an individual Conflict into Merged without making any changes to the source component, just open the merge conflict screen and click the "Save" button without making any changes.
Figure 2 : Save Merged changes in Source
For Apex and VisualForce code, the merge editor shows the “Ignore White Space” checkbox.
Figure 2: Code merge screen
1. The arrows allow the user to jump from diff to diff
2. Lines Merge - Allows us to go to line level merging from block level merging (i.e each line can be merged individually)
3. Manual Edit - Allows us to open both the versions in a mode where text can be manually edited in the left window.
4. Merge Add All button - With a single click move all the changes from right to left
5. Merge Remove All button - With a single click remove all the lines from left version that are not there in right version
6. Undo - Undo the latest changes done
7. Merge All arrow - Does the actions in Step 4 and 5 above in a single click
8. Arrow does a block level merge.
This merge feature is also available while merging branches or doing an Impact Analysis in a Deployment.