Documentation

Looking for something in particular?

Automation V3: Working with Git

Best practices

Below are some best practices for using Git with Provar.

The following workflow is recommended.


Keep in mind the following best practices when using Version Control:

  • Commit changes to Version Control early and often
  • Make useful commit messages, which can be referenced against the changes made in the commit
  • Have commits reviewed by a peer before committing them to the master branch
  • Sync other updates regularly from the master branch
  • Make regular backups
  • Follow a peer review process (see below)

When Launching Provar Automation, you will see the option to Import a test project from GitHub or GIT. 

Click this option and it will take you to the following screen where you can import your Git-based project into Provar:

Once you provide the Repository Address/URI, it will open the authentication screen where you can provide your GitHub username and Personal Access Token (PAT):

If you select Store in Secure Store, then Provar will save the GitHub authorization token to your keychain for future use.

View of a successful Git Import screen:

Peer review

Peer Review is a necessary process that should be performed regularly during developing new Test Cases.

A suggested Peer Review process is as follows:

  1. Review the check-in comments added to Version Control, which should detail the changes made
  2. Pull the changes to be reviewed from the branch to the local repository
  3. Perform the peer review
  4. Once verified, push the changes to the master branch

Cloning project from master

Start your work by getting the latest version of the Provar Project from Git. This is done by cloning the Project from the Master branch to your local directory.

Refer to Cloning a Project for steps on how to do this.

Creating a new branch

Once you have cloned the Project from the remote repository, consider whether you need to create a new branch for your work. This will depend on the workflow your team is following.

In general, you should update a new branch rather than make changes on the Master.

However, it is not always necessary to create a different branch for each tester in your team when working on the same project.

For example, you can also try to co-ordinate your team members to prevent multiple team members from updating the same Test Cases simultaneously. This will reduce the need to merge changes when syncing.

In general, it is a good idea to plan how many branches are required and how they will be used, rather than creating a new branch for every new team member.

You may need multiple branches if you are testing different versions of the System Under Test (SUT) at the same time. This will allow you to have different views of your Test Cases, depending on the functionality being tested.

To create a new branch, click on the Git view on the bottom panel in Provar Automation. Then from the Git Settings tab, click Switch Branch:

Select New Branch

Give the branch a name.

Click Finish.

This will create the branch on your local directory. It will then need to be pushed to the remote repository. To do this, click the Git Staging tab and select Push HEAD in the bottom right:

The following screen is displayed.

Click Push to confirm the push.

You should receive a confirmation push dialog once completed:

Once this is complete, you can begin working usually in Provar. Once you have completed your changes in Provar and want to push your work back to the remote repository, move on to the next section.

Synchronizing a project


Before pushing any work back to the remote repository, it is a good idea to synchronize your Project in case any changes have been made since it was cloned. Doing this before pushing changes to the repository will reduce the effort needed to resolve conflicts later.

To synchronize your project click the Git Repositories tab then right-click the branch you want to perform the synchronization with:

This will open the Team Synchronizing Perspective (once you confirm the dialog option):

Once this has been completed, you can double-click on any updated files to confirm the changes.

Making commits and pushing to Git


Once you are ready to commit and push your changes to Git, open the Git Staging tab from the Git menu:

Review the details entered below the Commit Message section and click OK.

On the Git Staging, enter a Commit message and select the files you want to push by selecting them and clicking the green ‘+’ icon, or by selecting the double ‘++’ to stage all changes for commit.

Click Commit and Push.

You should receive a push confirmation message:

Merging to master branch


To merge code into the Master branch, go to your GitHub repository in a browser.

Go to your Branch and click on New pull request.

Confirm the changes and click on Create Pull Request:

If you have access, you will be prompted with the option to merge pull requests.

Click Files Changed, review the files, then click the Review changes dropdown.

To approve, enter any summary comments as wanted, then choose the Approve radio button and click Submit review:

Click Merge pull request.

Click Confirm Merge.

The following success message should display.

Other Pull Requests can be created in the same way for other branches.

Resolving conflicts


While working on separate branches and merging the code, you may face some conflicts related to Test Cases and Page Objects added to the branch that conflicts with code already present on the master branch.

For example, after creating a Pull Request for your branch, you may see the following message:

To resolve the conflict, click the Resolve Conflict button on the message, then analyze the difference in the files.

Update/Remove the code that conflicts and click on Mark as resolved:

Once all conflicts have been resolved, commit the merge:

Then merge the branch to master:


Feedback

Was this article helpful for you?
Documentation library

Trying to raise a case with our support team?

We use cookies to better understand how our website is used so we can tailor content for you. For more information about the different cookies we use please take a look at our Privacy Policy.

Scroll to Top