How to: Work with branches in Access

Pull the work of others, switch to another branch or start a new one, while the database stays open in Access and no code is lost.

Code you change in Access lives in the database. git sees it only after an export has written it into the sources. A git switch or git pull in a terminal therefore works on sources that may be older than the database: a module changed in Access stays behind on the old branch, or the next export overwrites what the pull brought.

The SDK runs the branch steps through the same check as wkl-office changes:

In the add-in the steps are in the menu Branch of the group Project on the ribbon tab WKL SDK and on the toolbar WKL SDK of the VBA editor. The menu caption is the current branch, followed by ↑ and the number of commits to push and ↓ and the number of commits to pull, as of the last fetch or pull (main ↑2 ↓1). On the command line the same steps are wkl-office pull and wkl-office switch.

In Access or in the VBA editor:

1. Open Branch and choose Pull. The result is in the tab Output. If something waits for a decision, the tab Changes opens.
2. To switch, open Branch and choose a branch under Switch to. A branch that exists only on the remote is marked so; switching to it makes a local branch that tracks it.
3. If the VBA editor holds code that is not saved, or Access holds changes that are not exported, the add-in asks Export the changes made in Access and switch to branch? Choose Export and switch. The code is saved, the changes are exported, then the branch is switched.
4. After the switch, choose Import n object(s) to bring the changed objects into the open database, or Rebuild and reopen to build it anew from the sources of the branch. A rebuild is needed when tables, references or data differ; the question says so.
5. New branch… asks for the name. A name that git does not accept or that a branch already has cannot be confirmed.

On the command line:

wkl-office pull Customers.acproj
wkl-office pull Customers.acproj --push
wkl-office switch Customers.acproj feature/phone --create --export
wkl-office switch Customers.acproj main --import

Deciding a conflict after a pull. The tab Changes lists what waits:

• An object changed in Access and by the pull shows Both changed. Keep Access keeps your version, Keep source takes the version of the pull; the step is wkl-office sync <object> --keep access|source on the command line.
• A file git could not merge shows Resolve merge conflict. Select it and choose Resolve merge: Keep mine keeps the version of your branch, Take theirs the version of the pull. To merge both by hand, double-click the row: the file opens in Visual Studio Code. Remove the conflict markers, save, and choose Resolve merge again, then Mark as merged. The last file resolved concludes the merge with a commit carrying git's own message. Then import the merged sources with Import changes.

• A switch never loses code: work that exists only in Access is exported first, after you agreed. git then takes the changed source files along to the other branch, or refuses the switch when that branch has another version of the same file. Then nothing changes, and you can commit the export first.
• The pull imports only what it brought. An import that was waiting before the pull keeps waiting.
• A pull with a merge conflict of an earlier pull that is not resolved yet is refused.
• The import needs the database of the project open in Access. On the command line without an open database, switch lists the objects; import them later with wkl-office import --changed, or rebuild.
• The SDK starts git without a console. A question git would ask on the console fails at once. Sign-in through a credential helper, such as Git Credential Manager, still opens its own window.
• Only git. In a Subversion working copy the branch menu reads The project is in no git working copy, and pull and switch refuse.

• How to: Commit what was changed in Access
• How to: Use the Access add-in
• Command-line reference: pull, switch, changes, status and sync