Make Your Changes Public
When you edit files in your workspace, you're working within your local repository, which means that only you can see them. To share your private changes with your team, you'll need to push them to a shared project repository (the remote repo).
When you make changes in your workspace, an yellow dot appears next to the branch name in the header to let you know that you have uncommitted changes:
Description of the illustration git-header-badge.png
-
The first step you must perform is a commit. When you make a commit, you're basically grouping together the files in your local branch that you eventually want to move to the remote branch. You also provide a description of the changes you're making in the commit, which can be very helpful later if you need to track down which files were changed.
For example, suppose you added a new dynamic layout to include a field. When you committed the changes, you added a commit message describing the update, "Added new layout X for field Y". You then added a rule for the new layout, using the commit message "Added rule Z for layout X". By reviewing the history for the repository (using the Git History tab at the bottom of the Designer), you can easily see what files were changed and the reasons for changing them:
Description of the illustration githistory.png -
The second step is push, which synchronizes all the files you have committed thus far (since the last push) with the remote branch. If you have edited some files but haven't committed them, you'll be prompted to commit before you can push.
Note:
You can use the Publish action in the header if you want to commit, push, and merge the remote branch into themain
branch in one operation. See Publish Your Extension. Don't use Publish if you're not ready to merge the remote branch into the main
branch.
Commit Your Changes to the Local Branch
As you work on your application in the Designer, you can use the Commit option to save your changes to the local branch.
When you make a commit, you're basically grouping together the files in your local branch that you eventually want to copy to the remote branch. You also provide a description of the changes you're making in the commit, which can be very helpful later if you need to track down which files were changed.
Commit your changes as often as you can, so you have a string of commits with messages that clearly describe your updates.
To commit changes in your workspace:
Push Your Changes to the Remote Branch
Use the Push option to move changes you've committed from the local branch in your workspace to the remote branch, thus making your changes visible to team members. You'll need to explicitly commit your changes before you can push them to a remote branch.
Note:
Before you commit and push your changes, you should update the source files in your workspace by pulling the most recent versions from the repository. If the file versions in the remote branch are newer than the versions in your workspace, you’ll see a status message when attempting to push your changes that the push was rejected and that you should pull the most recent versions from the repository.To push your commits from the local branch in your workspace to the remote branch: