feat(git): add “Share to GitHub” flow

[wanling0000]

Closes #12350

This PR is part of GSoC 2025 — Git Support for JabRef.
It implements the Share to GitHub flow

• New dialog to enter Repository URL (HTTPS), GitHub username, and Personal Access Token (PAT).
• Optional “Remember Git settings”.
• Initializes a Git repo for the current .bib file if needed, sets origin, creates an initial commit, and pushes (creates upstream if remote is empty).
• Warns if the remote is not empty / behind to avoid overwriting.
• Adds inline help: link to GitHub PAT docs and “Create new repository” page.

Steps to test

Tip

Keep one .bib per folder when testing. Git init will commit everything in the folder except what’s ignored by .gitignore.

1. Prepare on GitHub

• Create an empty repository (no README/License) or pick an existing repo you want to use.
• Ensure you have a PAT with repo scope.

2. In JabRef

• Open (and save) a library so it has a file path.
• Go to File → Git → Share this library to GitHub.

3. In the dialog, fill in:

• Repository URL (HTTPS)
• GitHub username
• PAT
• Optionally tick Remember Git settings
• Click Share.

4. Expected results

• If the remote is empty: an initial commit is created and pushed; upstream is set.
• If the remote is not empty: a warning is shown to pull first; no destructive action is performed.

5. Verify on GitHub

• The repo should contain the committed .bib and .gitignore (and any other files in that folder not ignored).
• Upstream tracking exists for the current branch.

Screenshots

Mandatory checks

• I own the copyright of the code submitted and I license it under the MIT license
• [/] Change in CHANGELOG.md described in a way that is understandable for the average user (if change is visible to the user)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (if change is visible to the user)
• [/] Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• [/] Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[wanling0000]

I tried using Stacked Branches in GitButler, but every time I needed to update the PR at the bottom of the stack, I had to force push the entire stack...

So finally gave up using Stacked Branches...

[koppor]

Review "instructions" (if someone wants to try AI)

• How are credentials stored? Is this using JabRefs credential system
• Are the language keys grouped together correctly?
• Why is "http" allowed in GitHub URLs? Shouldn't it be https only? Shouldn't that be a helpe rmethod?
• Does it work if there is already an existing GitHub connection?
• Does it work if ther eis a "giti init" made but no remote?

[wanling0000]

Review "instructions" (if someone wants to try AI)

• How are credentials stored? Is this using JabRefs credential system

Thanks for pointing this out, I did find a security issue here.

If the user chooses not to remember their GitHub credentials, we still store the username and PAT in memory (via credentialsProvider).

When the user choose to remember them, we save them in GitPreferences and use the Password class from the shared database module to encrypt and decrypt the PAT based on the username.

Do you think this is an appropriate way to handle encrypted credentials in this case? Or would you recommend a better or more standard approach within JabRef?

[koppor]

• How are credentials stored? Is this using JabRefs credential system
  Thanks for pointing this out, I did find a security issue here.

If the user chooses not to remember their GitHub credentials, we still store the username and PAT in memory

This is OK.

When the user choose to remember them, we save them in GitPreferences and use the Password class from the shared database module to encrypt and decrypt the PAT based on the username.

This is not good 😅

Option 1:

• In JabRef's preferences, have a store for github username and github password - similar to proxy settings (org.jabref.logic.net.ProxyPreferences)

Option 2: provider-based store

• In JabRef's preferences, have store for provider/username/password - similar to org.jabref.gui.preferences.websearch.WebSearchTabViewModel

One can store "provider" using "domain".

Use case:

Users might have

• GitHub
• GitHub enterprise (e.g., https://github.tik.uni-stuttgart.de/)
• GitLab
• Custom GitLab hostings
• CodeBerg

and much much more.

---

For this phase, option 1 is enough and as follow-up we can support multiple Git hosting solutions.

[Siedlerchr]

When entering some rubbish, JabRef freezes and becomes unresponsive. You are probably blocking the main javafx thread.

[Siedlerchr]

Check the javafx threading

[trag-bot]

@trag-bot didn't find any issues in the code! ✅✨

[trag-bot]

@trag-bot didn't find any issues in the code! ✅✨

addressed