To use the version of Git™ provided with projects, when you add a project to source control or
retrieve from source control, select
Git in the
Source control tool list.
If you add an existing project to Git source control, you create a local Git repository in that sandbox. You can specify a remote repository later. See Add a Project to Source Control
If you want to clone a remote Git repository to create a project, select New > Project > From Git on the MATLAB® Home tab. After you specify a remote repository to retrieve from, a local repository is created. You can also pull, fetch, and push changes from and to the remote repository. See Clone Git Repository or Check Out SVN Repository.
You cannot add empty folders to Git source control. Use Check Project instead. See Pull, Push, and Fetch Files with Git.
To use a Git server for your remote repository, you can set up your own
Git server or use a Git server hosting solution. If you cannot set up a server and
must use a remote repository via the file system using the
file:/// protocol, make sure that it is a bare
repository with no checked out working copy.
To make your project publicly available on GitHub®, see Share Project on GitHub. Sharing adds Git source control to the open project and the project’s remote repository is GitHub.
You can manage your models and source code using Git in projects.
The Git integration with the project provides distributed source control with support for creating and merging branches. Git is a distributed source control tool, so you can commit changes to a local repository and later synchronize with other remote repositories.
Git supports distributed development because every sandbox contains a complete repository. The full revision history of every file is saved locally. This enables working offline, because you do not need to contact remote repositories for every local edit and commit, only when pushing batches of changes. In addition, you can create your own branches and commit local edits. Doing so is fast, and you do not need to merge with other changes on each commit.
Capabilities of Git source control:
Local full revision history
Local access that is quicker than remote access
Tracking of file names and contents separately
Enforcing of change logs for tracing accountability
Integration of batches of changes when ready
These capabilities do not suit every situation. If your project is not appropriate for offline working or your repository is too large for a full local revision history, for example, Git is not the ideal source control. In addition, if you need to enforce locking of files before editing, Git does not have this ability. In that situation, SVN is the better choice.
When you use Git in a project, you can:
Create local Git repositories.
Pull and fetch files from remote Git repositories.
Create and switch branches.
Merge branches locally.
Push files to remote Git repositories.
This diagram represents the distributed Git workflow.
If you want to use Git to merge branches in a project, you must also install a command-line Git client that is available systemwide. You can use other Git functionality without any additional installation.
Some clients are not available system wide, including the
environment provided by GitHub (Git Shell on the
Start menu). Installing command-line Git makes it available systemwide, and then the project can locate
Check if Git is available by using the command
!git in MATLAB.
If Git is not available, install it.
Download the Git installer and run it. You can find command-line Git at:
In the section on adjusting your PATH, choose the install option to
Use Git from the Windows Command Prompt. This
option adds Git to your
PATH variable, so that the project
can communicate with Git.
In the section on configuring the line-ending conversions, choose the option Checkout as-is, commit as-is to avoid converting any line endings in files.
On Linux®, Git is available for most distributions. Install Git for your distribution. For example, on Debian®, install Git by entering:
sudo apt-get install git
On Mac, on Mavericks (10.9) or above, try to run
from the Terminal. If you do not have Git installed already, it will prompt you to install Xcode Command Line
Tools. For more options, see
If you are working with long path files, run this command in MATLAB:
!git config --global core.longpaths true
To avoid corrupting models, before using Git to merge branches, register model files. See Register Model Files with Git.
After you install a command-line Git client, you can prevent Git from corrupting your Simulink® models by inserting conflict markers. To do so, edit your
.gitattributes file to register model files as binary. For
If you do not already have a
in your project root folder, create one by entering in MATLAB:
Add these lines to the
*.mlx -crlf -diff -merge *.mat -crlf -diff -merge *.fig -crlf -diff -merge *.mdl -crlf -diff -merge *.slx -crlf -diff -merge *.mlapp -crlf -diff -merge *.p -crlf -diff -merge *.mdlp -crlf -diff -merge *.slxp -crlf -diff -merge *.sldd -crlf -diff -merge *.slxc -crlf -diff -merge *.mlproj -crlf -diff -merge *.mldatx -crlf -diff -merge *.slreqx -crlf -diff -merge *.sfx -crlf -diff -merge *.sltx -crlf -diff -merge
Check for other file types you use in your projects that you also need to
register as binary to avoid corruption at check-in. Check for files such as
.docx, etc. Add a line to the attributes file for
each file type you need.
*.mexa64 -crlf -diff -merge *.mexw64 -crlf -diff -merge *.mexmaci64 -crlf -diff -merge *.xlsx -crlf -diff -merge *.docx -crlf -diff -merge *.pdf -crlf -diff -merge *.jpg -crlf -diff -merge *.png -crlf -diff -merge
Restart MATLAB so you can start using the Git client with the project.
After you have installed a command-line Git client and registered your model files as binary, you can use the merging features of Git in projects.
You can reduce your Git repository size by saving Simulink models without compression. Turning off compression results in larger SLX files on disk but reduces repository size.
To use this setting with new SLX files, create your models using a model template with SLX Compression set to none. For existing SLX files, set compression and then save the model. For more information, see Set SLX Compression Level.
To reuse code from another repository, you can specify Git submodules to include in your project.
To clone an external Git repository as a submodule:
On the Project tab, in the Source Control section, click Submodules.
In the Submodules dialog box, click the + button.
In the Add Submodule dialog box, in the Remote box, specify a repository location. Optionally, click Validate.
In the Path box, specify a location for the submodule in your project and click OK. The Submodules dialog box displays the status and details of the submodule.
Check the status message, and click Close to return to your project.
After using Pull on the top-level project, check submodules are up to date by clicking Submodules and then click Update. If any submodule definition have changed, then the update ensures that the submodule folder contains the correct files. Update applies to all child submodules in the submodule hierarchy.
When you want to manage a submodule, open the Submodules dialog box.
To get the latest version of a submodule, in the Submodules dialog box, click Fetch.
After fetching, you must merge. Check the
Status message in the Submodules dialog box
for information about your current branch relative to the remote
tracking branch in the repository. When you see the message
Behind, you need to merge in
changes from the repository to your local branch.
Click Branches and merge in the origin changes to your local branch using the Branches dialog box. See Pull, Fetch, and Merge.
If you make changes in your submodule and want to send changes back to the repository:
Perform a local commit in the parent project.
Open the Submodules dialog box and click Push.
If you want other project users to obtain your changes in the submodule when they clone the parent project, make sure the index and head match.
In the Submodules dialog box, check the index and head values. The index points to the head commit at the time you first cloned the submodule, or when you last committed the parent project repository. If the index and head do not match, you must update the index.
To update the index, commit your changes in the parent project, and then click Push in the Submodules dialog box. This action makes the index and head the same.