Because Data Science & AI Workbench projects are structured as Git repositories, familiar Git rules apply for sharing your changes with project collaborators. Adding a user or group of users to a project as collaborators provides them with access to edit project files and commit changes to the project’s remote Git repository. Workbench tracks all changes to projects and lets you know when files have been updated, so you can choose which version to work with.
The only project setting collaborators can edit is the default editor.

​
Adding collaborators to a project

To add a user or group of users as collaborators for a project:
  1. From the Projects page, open the project you want to collaborate on.
  2. Select Share from the left-hand navigation.
  3. Begin typing a user or group name in the Add New Collaborator dropdown to search for matches. Select the correct entry, then click Add.
Collaborators added to your project will see it on their Projects page, and if others share their projects with you, they’ll appear on yours.

​
Removing collaborators from a project

Removing collaborators from a project revokes their access to the project’s remote repository, so they will no longer see the project or be allowed to commit and push changes to the repository. To remove collaborators from a project:
  1. From the Projects page, open the project you want to remove collaborators from.
  2. Select Share from the left-hand navigation.
  3. Click the collaborator you want to remove.
  4. Click Remove.
Removing collaborators from a project while they have a session open results in a 500 Internal Server Error message for them. Communicate with collaborators prior to removing them from projects.

​
Saving vs. committing changes

When you open a project session, you’re working with a local copy of the project’s remote Git repository. Changes you save only affect your local project repository. When you’re ready to update the project or share your updates with others, you must commit and push your changes to the project’s remote repository.

​
Committing and pushing changes

  1. From a project session, click Commit and push changes.
  2. Select checkboxes for the files you want to commit to your project’s remote repository.
    If files you’ve added or modified aren’t displayed in this list, verify the changes are saved locally, then try again.
    Some editors create hidden folders that are only used internally to capture the state of your files between auto-save operations. Anaconda recommends you add hidden folders to your project’s .gitignore file, so they are excluded from version control.
  3. Enter a commit message for your changes. Best practice for commit messages is to make the message descriptive of your changes.
  4. If necessary, enter a meaningful label or version number as a Tag for your project. This enables you and your project collaborators to manage and deploy specific builds of the project.
    Any commits pushed to the latest version of a project are included when the project is downloaded, even if you have not tagged the commits to a new version of the project.
  5. Click Commit and Push. A notification appears informing you that your local changes have been pushed to the project’s remote repository.
If your changes conflict with updates made by other collaborators, a list of impacted files will display in red. To resolve your conflicts:
  • Cancel - This won’t resolve any file conflicts, but it will cancel the commit.
  • Commit - Overwrite your collaborators’ changes. Exercise caution! Collaborators might not appreciate having their work overwritten, and important work could be lost!
  • Selectively Commit - Commit only those files that don’t have conflicts by unchecking the ones highlighted in red.
Committing changes to the project’s remote repository involves a full synchronization. This means that as you push your local repository changes, any updates that have been committed to the project that do not conflict with the changes you’re committing are simultaneously pulled to your local project repository. This means that, after committing your changes, your local project repository will match the remote project repository.

​
Pulling changes

When working on a project with other users, you will need to manage keeping your local project repository current with changes that they have committed to the project’s remote repository. A badge appears on Pull Changes whenever a commit has been made to the project, indicating that you need to update your local project repository. To pull changes to your local project repository: From a project session, click Pull Changes. If there are no file conflicts, your local repository is updated. If the remote repository contains conflicts with changes you have made locally, you can choose one of the following options:
  • Cancel - This won’t resolve any file conflicts, but it will cancel the pull.
  • Keep Theirs and Pull - Discards your local changes in favor of theirs. Your changes will be lost.
  • Keep Mine and Pull - Discards changes on the remote repository in favor of your local changes. Their changes will be overwritten.
  • Keep Both and Pull - This saves the conflicting files with different filenames so you can compare the content of the files and decide how you want to reconcile the differences.
If you have a file open that has been modified by pulling changes, close and reopen the file for the changes to appear. If you do not, the next time you save the file, you will receive a File has been overwritten on disk alert in JupyterLab. This alert lets you choose whether to cancel the save, discard the current version and open the version of the file on disk, or overwrite the file on disk with the current version.