Commit and push changes to Git repository

After you've added new files to the Git repository, or modified files that are already under Git version control and you are happy with their current state, you can share the results of your work. This involves committing them locally to record the snapshot of your repository to the project history, and then pushing them to the remote repository so that they become available to others.

Set your Git username

Git needs to know your username to associate commits with an identity. If you have not set your username, MPS will prompt you to specify it when you first attempt to commit changes.

Open the Terminal and execute one of the following commands:
- To set a name for every Git repository on your machine, use $ git config --global user.name "John Smith"
- To set a name for a single repository, use $ git config user.name "John Smith"

Commit changes locally

In MPS, you can commit changes in one of the following ways:

In the Commit tool window: this is the default way for new installations. This new UI supports a totally different approach to the commit procedure: unlike using the modal Commit dialog, you are always in the commit mode, and, therefore, can add changes to the commit when they are ready, make a series of small commits, and write the commit message iteratively.
Through the Commit Changes dialog: this is the default way for existing users. You can switch to the new UI in Settings/Preferences | Version Control | Commit.

Commit changes from the Commit tool window

Open the vertical Commit tool window located on the left:
As your changes are ready to be committed, select the corresponding files or a changelist.

If you press Ctrl+K, the entire active changelist will be selected.

You can also select files under the Unversioned Files node — MPS will stage and commit these files in one step.
Enter the commit message. You can click at the bottom-right corner to choose from the list of recent commit messages.

You can also edit the commit message later before you've pushed the commit.

You can customize commit message rules, in the Settings/Preferences dialog Ctrl+Alt+S under Version Control | Commit Dialog. There is also a quick-fix and the Reformat action that wrap a long line or reformat the message.
If you need to perform pre-commit checks, upload files to a server after the commit, or commit with advanced options, click in the bottom-right corner of the tool window:

The following options are available:
- Author: if you are committing changes made by another person, you can specify the author of these changes.
- Amend commit: lets you add local changes to the latest commit.
- Sign-off commit: select if you want to sign off your commit to certify that the changes you are about to check in have been made by you, or that you take the responsibility for the code you're committing.
  When this option is enabled, the following line is automatically added at the end of the commit message: Signed off by: <username>
- In the Before Commit area, select the actions you want MPS to perform before committing the selected files to the local repository.
When you're ready, click Commit, or click the arrow on the Commit button to display the available options:
- Commit and Push (Ctrl+Alt+K): push the changes to the remote repository immediately after the commit. You will be able to review the current commit as well as all other commits before they are pushed to the remote.
- Create Patch: generate a patch based on the changes you are about to commit. In the Create Patch dialog, type the name of the patch file and specify whether you need a reverse patch.
- Remote Run: run your personal build. This option is only available when you are logged in to TeamCity. Refer to TeamCity plugin documentation for details.

Commit changes from the Commit dialog

Select the files you want to commit or an entire changelist in the Local Changes view and press Ctrl+K or click Commit on the toolbar.

The Commit Changes dialog that opens lists all files that have been modified since the last commit, as well as all newly added unversioned files.
Review the list of files you're about to commit, and clear the checkboxes next to files and directories that you don't want to include in the commit. Changes in the excluded files will remain in the active changelist and you can commit them later.

You can also select files under the Unversioned Files node — MPS will stage and commit these files in one step.
Enter a commit message.

You can click Commit Message history Ctrl+M to choose from the list of recent commit messages.

You can also edit the commit message later before you've pushed the commit.

You can customize commit message rules, in the Settings/Preferences dialog Ctrl+Alt+S under Version Control | Commit Dialog. There is also a quick-fix and the Reformat action that wrap a long line or reformat the message.
If necessary, you can perform pre-commit checks, upload files to a server after the commit, or commit with advanced options. These options are available on the right-hand side of the dialog:
- Author: if you are committing changes made by another person, you can specify the author of these changes.
- Amend commit: lets you add local changes to the latest commit.
- Sign-off commit: select if you want to sign off your commit to certify that the changes you are about to check in have been made by you, or that you take the responsibility for the code you're committing.
  When this option is enabled, the following line is automatically added at the end of the commit message: Signed off by: <username>
- In the Before Commit area, select the actions you want MPS to perform before committing the selected files to the local repository.
When you're ready, click Commit, or click the arrow on the Commit button to display the available options:
- Commit and Push (Ctrl+Alt+K): push the changes to the remote repository immediately after the commit. You will be able to review the current commit as well as all other commits before they are pushed to the remote.
- Create Patch: generate a patch based on the changes you are about to commit. In the Create Patch dialog, type the name of the patch file and specify whether you need a reverse patch.
- Remote Run: run your personal build. This option is only available when you are logged in to TeamCity. Refer to TeamCity plugin documentation for details.

Commit part of a file

Sometimes when you make changes that are related to a specific task, you also apply other unrelated code modifications that affect the same file. Including all such changes into one commit may not be a good option, since it would be more difficult to review, revert, cherry-pick them, and so on.

MPS lets you commit such changes separately in one of the following ways:

select modified code chunks, that you want to include in a commit right in the Commit Changes dialog and leave other changes pending so that you can commit them later.
put different code chunks into different changelists on the fly, when you edit code, and then commit these changelists separately.

You can also create a new changelist and make it active, then all changes that you make after that will fall into that changelist, while any modifications you made before that will stay where they are.

Select chunks you want to commit

Open the vertical Commit tool window on the left or invoke the Commit Changes dialog.
To display the differences between the repository version and the local version of the selected file, in the Commit tool window, click on the toolbar or press Ctrl+D.

If you're using the Commit Changes dialog, click Diff.
Select the checkbox next to each chunk of modified or newly added code that you want to commit, and leave other changes unselected:

You can also select Move to Another Changelist from the context menu of a modified chunk to split changes between different changelists that you can commit separately.

To assign a custom shortcut for this action: in the Settings/Preferences dialog Ctrl+Alt+S, select Keymap and look for the Move Lines to Another Changelist action under Version Control Systems.
Click Commit. Unselected changes will stay in the current changelist, so that you can commit them separately.

Put changes into different changelists

When you make a change to a file in the editor, click the corresponding change marker in the gutter.
In the toolbar that appears, select the target changelist for the modified code chunk (or create a new changelist):
Commit each changelist separately.

Push changes to a remote repository

Before pushing your changes, sync with the remote and make sure your local copy of the repository is up-to-date to avoid conflicts.

MPS allows you to upload changes from any branch to its tracked branch or to any other remote branch.

Do one of the following:
- To push changes from the current branch press Ctrl+Shift+K or choose VCS | Git | Push from the main menu.
- To push changes from any local branch that has a remote, select this branch in the Branches popup and choose Push from the list of actions.
The Push Commits dialog opens showing all Git repositories (for multi-repository projects) and listing all commits made in the current branch in each repository since the last push.

If you have a project that uses multiple repositories that are not controlled synchronously, only the current repository is selected by default (for details on how to enable synchronous repositories control, refer to Version Control Settings: Git).

You can press Ctrl+Q for the selected commit to display extra info, such as the commit author, time, hash and the commit message.
If there are no remotes in the repository, the Define remote link appears. Click this link and specify the remote name and URL in the dialog that opens. It will be saved and you can edit it later via VCS | Git | Remotes (for details, see Add a remote repository).
If you want to modify the target branch where you want to push, you can click the branch name. The label turns into a text field where you can type an existing branch name, or create a new branch. You can also click the Edit all targets link in the bottom-right corner to edit all branch names simultaneously.

Note that you cannot change the local branch: the current branch for each selected repository will be pushed.

You can also switch to the editing mode by pressing Enter or N/A for the selected element.
If you want to preview changes before pushing them, select the required commit. The right-hand pane shows the changes included in the selected commit. You can use the toolbar buttons to examine the commit details.

If the author of a commit is different from the current user, this commit is marked with an asterisk.

If you select an entire repository, all files from all commits will be listed in the right pane.

If the same file was modified within several commits, it will only be listed once if you select these commits or the entire repository, and if you invoke the Differences Viewer for this file, all changes will be zipped together.
Click the Push button when ready and select which operation you want to perform from the drop-down menu: Push or Force push.

These choice options are only available if the current branch is not listed in the Protected branches field (see Version Control Settings: Git), otherwise, you can only perform the push operation.

Update your working copy if push is rejected

If push is rejected because your working copy is outdated, MPS displays the Push Rejected dialog, provided that the Auto-update if push of the current branch was rejected option in the Git settings page of the Settings Preferences dialog is not selected. Do the following:

If your project uses several Git repositories, specify which of them you want to update. If you want to update all repositories, no matter whether push was rejected for them or not, select the Update not rejected repositories as well option. If this option is cleared, only the affected repositories will be updated.
If you want MPS to apply the update procedure silently the next time push is rejected using the update method you choose in this dialog, select the Remember the update method choice and silently update in the future option.

After you leave this dialog, the Auto-update if push of the current branch was rejected checkbox in the Git settings page of the Settings Preferences dialog will be selected, and the applied update method will become the default one.

To change the update strategy, deselect this option to invoke the Push Rejected dialog the next time push of the current branch is rejected, apply a different update procedure, and select the Remember the update method choice option once again.
Select the update method (rebase or merge) by clicking the Rebase or Merge button respectively.

When do I need to use force push?

When you run push, Git will refuse to complete the operation if the remote repository has changes that you are missing and that you are going to overwrite with your local copy of the repository. Normally, you need to perform pull to synchronize with the remote before you update it with your changes.

The --force push command disables this check and lets you overwrite the remote repository, thus erasing its history and causing data loss.

A possible situation when you may still need to perform --force push is when you rebase a pushed branch and then want to push it to the remote server. In this case, when you try to push, Git will reject your changes because the remote ref is not an ancestor of the local ref. If you perform pull in this situation, you will end up with two copies of the branch which you then need to merge.

If you decide to force push the rebased branch and you are working in a team, make sure that:

Nobody has pulled your branch and done some local changes to it
All pending changes have been committed and pushed
You have the latest changes for that branch

Last modified: 18 June 2020