Git Process (Merging and Pushing)#

Developers comfortable with Git may use the terminal instead of SourceTree. For a command overview, see the Atlassian Git glossary.

Always pull the latest remote changes into your working branch before starting or merging work.

Naming and commit-message rules#

Name each feature branch after its Jira ticket number — e.g. MD-4369.

Each commit message must include the ticket key and a concise description of the changes.

How to create a feature branch in SourceTree#

The development branch is DbChanges_Staging. Create every standard feature branch from the latest version of this branch.

1. Select Git-flow.
2. Set the development branch to DbChanges_Staging, then click OK. This initialization is required only once.
3. Open Git-flow again and select Start New Feature. Repeat this step whenever you create a feature branch.
4. Enter the Jira ticket number as the feature name, then click OK.

How to push and pull in SourceTree#

After completing the ticket changes — including any database SQL files — review the File Status tab and confirm that only your intended changes are included.

1. Select the changes and Stage them.
2. Enter the commit description and click Commit.
3. When the outgoing commit appears, click Push.
4. Select only your feature branch, then click Push again.

Additional rules:

• Every time you work on a new branch, check that DbChanges_Staging has been pulled with the latest updates before creating the branch.
• Before pulling, review local file changes to prevent conflicts. Discard unintended local changes, or resolve / stash the files that must be retained.
• Use Stash when local changes must be retained temporarily.
• When adding a package dependency, include all related configuration and project files in the commit, e.g. packages.config, Site/site.csproj.
• Do not commit unnecessary generated build files.
• When adding new HTML or C# files, include the corresponding .csproj update containing their paths. Visual Studio should generate this automatically.

How to merge with different environments#

Release-2 and Release-3 are release branches. Merge into them only when required by the ticket or its Fix Version/s configuration.

Merging into DbChanges_Staging (SourceTree)#

1. Pull the latest changes from DbChanges_Staging.
2. Check out the feature branch you are going to merge.
3. Finish Feature.
4. Fix conflicts (if any).
5. Push changes into DbChanges_Staging (or the release branch).
6. Verify that everything works properly.

Feature branch created from a release branch#

1. Ensure your feature branch is up to date with the latest changes from the release branch.
2. Merge the feature branch into the release branch.
3. Resolve any conflicts, then commit.

Feature branch created from DbChanges_Staging, but the change must also land on a release branch#

1. Identify the merge commit on your feature branch that you want to include in the release.
2. Note its commit hash.
3. Switch to the release branch.
4. Cherry-pick the merge commit from your feature branch into the release branch.
5. Resolve any conflicts, then push the changes.
6. Verify that everything works properly.

Database scripts#

Run and commit database scripts through ApexSQL Source Control, using the same ticket-based commit-message rules. All script files are stored in the TSQL folder.

When modifying an existing SQL file (stored procedure, trigger, etc.), add a change comment inside the file.

Rollback procedures#

Use git log to view the commit history and identify the commit hash you want to roll back to. Then use git revert to create a new commit that undoes the changes. Revert only your own changes. After reverting, verify that the project works properly.

Resolving conflicts#

If you encounter merge conflicts:

1. Locate each conflicted file and resolve the differences. Git conflict blocks are marked with <<<<<<< HEAD, =======, and >>>>>>> branch-name.
2. Compare both versions carefully and integrate the required changes without omitting or duplicating lines.
3. After resolving all conflicts, commit the result and push it to the intended branch.
4. Verify the application functions correctly after the merge.

SprintQB (ManexCloud project)#

If your ticket is related to the ManexCloud project:

• Use the SprintQB branch and create the feature branch from it.
• Run Visual Studio as an administrator when working with ManexCloud.

Manex Service (Cube Service)#

1. Implement and test the fix in the ManexService project.
2. Push code changes to your feature branch.
3. Publish the .exe file and attach it to the ticket for testing.
4. After final validation, upload the .exe to the SharePoint release folder.