GIT sounds like it strays quite a bit from typical source control manager (I'll use the typical abbreviation "SCM" here) behavior, so it may need some glue. You can provide the glue via scripts. If GIT is the only system one has experienced, then I can imagine it would be confusing how to map its behavior into the typical SCM actions.
Some of your questions are answered in SlickEdit's Help system topic on its Version Control support:
Overview of Version Control
Version control is accessed from the Tools → Version Control menu, by right-clicking within a file or buffer, or by right-clicking on an item in the Files list of the Open tool window.
The History, Difference, Lock, and Properties commands operate on the current buffer. For SCC version control systems, the SCC provider's function is called. For command line version control systems, the specified command is run, and the output is displayed.
The Check In, Get, Check Out, Unlock, Add, and Remove commands show a dialog box and operate on all files selected. This dialog will allow you to easily choose from files currently open, the files in the current project, or files in the current workspace. Note that CVS operations are different and designed to work especially well with CVS. Also, for SCC version control systems, you can select from files that are valid for that command. For example, when using the Check In command, you can click Available to view all files that can currently be checked in.
Use the Manager command to bring up the version control system's user interface. For many command line systems there will not be a program to call for this.
Menu items that appear grayed out for a command line version control system are blank. For SCC version control systems, Lock is always unavailable because the SCC interface does not make allowances for a lock command. It is possible to receive an Operation not supported message when running some commands if an SCC version control system does not implement an interface to that operation.
Some more specific answers follow below. But you invoke these commands -- so you can choose what you want them to do. The only one that SE invokes automatically on your behalf is "Checkout", the rest are invoked by you. For example, if you want "History" to launch your favorite game, you can make it do that.
What does SE want this command to do? I would assume it refers to adding new files that are currently not in the repository,
Yes. Use this to add a file to the SCM. It sounds like GIT has two modes -- local repository, or remote repository. Probably pick which way you want the Add command to work. You can always write a custom macro for the other flavor.
Use this to record your changes in the SCM. If there are multiple commands for different contexts, write a script that figures out the context and then invokes the appropriate command.
Again, we cannot assume that assume that we are working from a remote repository.
Use this to let the SCM know that you want to edit the file. If there are multiple commands for different contexts, write a script to disambiguate and invoke an appropriate command.
Difference between what? A file's current state, compared to the state of the HEAD? The entire repository compared to the HEAD? Beats me.
Use this to see the edits you've made to the file, i.e. compared to the state of the file before you told the SCM that you wanted to edit the file. Or at least that's typically what people want a diff command to do in an SCM. If you want it to do something different, fill in whatever command you want it to do.
Get what? How does this differ from Checkout?
Use this to get the head revision from the SCM.
Of the whole repository? Of a single file? In the former case,
Use this to view the history of the file being edited.
AFAIK, Git has no support of locking, so this can't be implemented here.
Apparently for GIT, leave it blank.
Use this to launch a GUI program for viewing the repository.
Of what? A file? Revision? No idea, personally.
Use this to view/edit SCM properties of the file being edited. Or whatever kind of properties you feel are appropriate to view in the context of SCM. Or leave it blank.
Is this supposed to be 'remove a file from the filesystem, and from the repository.'?
Use this to tell the SCM that you want to remove the file from the SCM. Or whatever "remove" means to you. If there are multiple actions that differ by context, write a script to infer context and invoke an appropriate command.
Again, locking not supported, so unlocking does nothing too.
Apparently for GIT, leave it blank.
Hope that helps.
SlickEdit's Help could be a little more verbose about the SCM stuff, but in all fairness it sounds like GIT is an atypical SCM. SlickEdit's commands mirror the standard SCM actions -- even if some SCMs use different terms, the similarities between most SCMs make it pretty clear how SlickEdit assumes the user will want to use the commands.