Commit and push changes
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.
Commit changes locally
- Invoke the commit dialog in one of the following ways:
- Press N/A.
- In the Local Changes tab of the Version Control tool window, select a changelist or files you want to commit and click the Commit Changes button on the toolbar or select Commit Changes on the context menu of the selection.
- On the main menu, choose or .
The Commit Changes dialog lists all files that have been modified since the last commit, and all newly added unversioned files.
- Enter a commit message and select the Before Commit actions you want MPS to perform before committing the selected files to the local repository.
- Select the following options in the Git section if necessary:
- Author: if you are committing changes made by another person, you can specify the author of these changes.
- Amend commit: select this option if you want to add the local changes to the latest commit (see Combine staged changes with the previous commit (amend commit) for details).
- Sign-off commit: Select this option if you want to sign off your commit, i.e. 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 in question.
When this option is enabled, the following line is automatically added at the end of the commit message: Signed off by: <username>
- Click the Commit button or hover the mouse over this button to display one of the following available commit options:
- Commit and Push: push the changes to the remote repository immediately after the commit.
- Create Patch: generate a patch based on the changes you are about to commit. In the Create Patch dialog that opens, 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.
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 the current branch to its tracked branch or to any other remote branch.
- Press N/A or choose VCS | Git | Push from the main menu. 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).
- 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.
- 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.
- 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 Allow force push option is enabled (see Version Control Settings: Git), otherwise, you can only perform the
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 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
pushwas 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 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.
--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