Source Control and Git Release Notes
Updates for code hosting, source control platforms, and Git clients.
Products (7)
Latest Source Control and Git Updates
- Nov 11, 2026
- Date parsed from source:Nov 11, 2026
- First seen by Releasebot:Nov 11, 2026
Issue types and fields are available for personal accounts
GitHub brings issue types and customizable fields to personal-account repositories, helping developers organize work and plan across projects. It also lets users create labels and milestones directly from an issue.
Issue types and issue fields are now generally available on repositories owned by personal accounts. This brings the same planning capabilities to individual developers and open source maintainers to standardize your workflows and organize issues across repositories.
Get started with issue types and issue fields
- Customize issue types: You can customize issue types from your personal account settings on the Issue types page under “Planning”. The defaults are Bug, Task, and Feature. You can customize them and create up to 25 issue types.
- Customize issue fields: You can customize issue fields from your personal account settings on the Issue fields page under “Planning”. The default issue fields are Priority, Effort, Start date, and Target date. You can customize them and create up to 25 issue fields, with support for text, number, date, single-select, and multi-select fields. You can also pin fields to issue types or make them available on issues without a type.
- Apply them to issues: You can set the issue type and fields when creating an issue or viewing an existing issue. You can also use them in projects to create custom views and perform bulk updates.
- Use the API to automate: You can use the REST and GraphQL APIs and webhooks to programmatically manage issue types and fields.
Learn more about managing issue types and managing issue fields.
Create labels and milestones from an issue
You can now create labels and milestones directly from an issue, without navigating to the repository’s labels or milestones pages. If a label or milestone doesn’t match your search criteria, you’ll be prompted to create one.
Join the discussion within GitHub Community.
The post Issue types and fields are available for personal accounts appeared first on The GitHub Blog.
Original source - Nov 11, 2026
- Date parsed from source:Nov 11, 2026
- First seen by Releasebot:Nov 11, 2026
GitHub App support for Enterprise Copilot seat management
GitHub lets Enterprise Apps manage Copilot seat assignments for users and teams through APIs with a new fine-grained permission.
Enterprise GitHub Apps can now call the enterprise-level Copilot seat management APIs to control which users and enterprise teams are assigned Copilot seats.
The Copilot seat management APIs are accessible with a new enterprise fine-grained permission for Apps: Enterprise Copilot license management.
The post GitHub App support for Enterprise Copilot seat management appeared first on The GitHub Blog.
Original source All of your release notes in one feed
Join Releasebot and get updates from GitHub and hundreds of other software products.
- Nov 10, 2026
- Date parsed from source:Nov 10, 2026
- First seen by Releasebot:Nov 11, 2026
Gemini 4 Carbon in GitHub Copilot
GitHub brings Google’s Gemini 4 Carbon to Copilot, now generally available for complex coding, agentic, and reasoning tasks with a focus on secure code generation. Eligible users can select it across supported Copilot experiences, with access managed by plan administrators.
Gemini 4 Carbon, Google’s latest model, is now generally available in GitHub Copilot. It is designed for complex coding, agentic, and reasoning tasks, with a focus on secure code generation and security-focused work.
This model is billed at provider list pricing under usage-based billing. See Models and pricing for GitHub Copilot for details.
Availability in GitHub Copilot
Gemini 4 Carbon is available to Copilot Pro+, Max, Business, and Enterprise users. You can select the model in the model picker in:
- Visual Studio Code
- Visual Studio
- Copilot CLI
- GitHub Copilot coding agent
- GitHub Copilot app
- github.com
- GitHub Mobile on iOS and Android
- JetBrains IDEs
- Xcode
- Eclipse
Rollout will be gradual. Check back soon if you don’t see it yet.
Enabling access
Copilot Enterprise and Copilot Business plan administrators can manage access to Gemini 4 Carbon through the model policy in Copilot settings. Under default model enablement, new models are automatically enabled unless an administrator has turned off the global default or explicitly disables this model.
Learn more
To explore all models available in GitHub Copilot, see our documentation on models and get started with Copilot.
Share your feedback
Join the GitHub Community to share your feedback.
The post Gemini 4 Carbon in GitHub Copilot appeared first on The GitHub Blog.
Original source - Nov 10, 2026
- Date parsed from source:Nov 10, 2026
- First seen by Releasebot:Nov 11, 2026
C++ language server now auto-configures MSBuild builds
GitHub’s Microsoft C++ Language Server for Copilot CLI now bundles and automatically runs an MSBuild compile commands extractor when a project opens. This removes manual setup skills and enables code intelligence with less setup.
The Microsoft C++ Language Server for GitHub Copilot CLI now bundles its MSBuild compile commands extractor and invokes it automatically. An agent no longer needs to discover and run a separate configuration skill before it can get precise code intelligence for your project. For more information, including the installation instructions, see the main repository page.
What changed
Previously, setting up go-to-definition, find references, and other language server features for an MSBuild-based C++ project required you to either provide your own compile_commands.json file or Copilot to locate and run a configuration skill before it could generate a compilation database. That extra discovery step added setup time and consumed tokens before Copilot could start working with your code.
Now:
- The compile commands extractor is bundled directly with the C++ language server, so it’s always available.
- Copilot invokes the extractor when starting the language server on project open, with no manual or agent-driven setup skill required.
- Compilation database generation for MSBuild projects is deterministic, reducing setup token usage.
Configure other build systems
For other build systems, you can provide your own compile_commands.json or use a skill to generate one:
- For CMake projects, use the generate compile commands skill introduced in the earlier C++ language server release by asking Copilot CLI to “load project.”
- For custom build systems, follow the guide to create a custom build extractor skill.
Get started
Follow the Microsoft C++ Language Server quick start to install the plugin and accept the EULA. If your repository contains an MSBuild-based C++ project, Copilot will automatically generate the compilation database it needs for accurate code intelligence.
An active GitHub Copilot subscription is required.
Help improve the Microsoft C++ Language Server by completing the C++ language server survey. To report a problem or suggest an improvement, open an issue in the Microsoft C++ Language Server repository.
The post C++ language server now auto-configures MSBuild builds appeared first on The GitHub Blog.
Original source - Nov 10, 2026
- Date parsed from source:Nov 10, 2026
- First seen by Releasebot:Nov 11, 2026
Dependabot alerts will pause on inactive repositories
GitHub will pause Dependabot alerts on repositories inactive for a year starting December 8, 2026, while archiving alerts for restoration. Repository activity or settings can reactivate alerts, and enforced security policies protect them from being turned off.
Starting December 8, 2026, GitHub will turn off Dependabot alerts on most repositories with no activity in the past year. Their existing alerts are archived, not deleted, and you can restore them at any time. With vulnerability discovery and alert volume growing quickly, this keeps Dependabot fast and reliable for the repositories you’re actively developing.
What counts as activity
GitHub counts any of these as activity:
- Pushing to any branch or tag
- Creating the repository
- Turning on Dependabot alerts
Turn alerts back on
Any push to the repository automatically turns Dependabot alerts back on. You can also turn them on in the repository’s settings. Either way, GitHub restores the archived alerts, and the one-year clock starts over.
Keep alerts on regardless of activity
GitHub won’t turn off alerts on repositories with an enforced security configuration that enables Dependabot alerts. It also skips repositories in enterprises whose Dependabot alerts policy doesn’t allow repository administrators to enable or disable alerts.
This change applies to all plans on github.com and to GitHub Enterprise Cloud with data residency. For data residency customers, archived alerts are stored in the same region as the rest of your enterprise’s data. It doesn’t apply to GitHub Enterprise Server.
The post Dependabot alerts will pause on inactive repositories appeared first on The GitHub Blog.
Original source - Nov 10, 2026
- Date parsed from source:Nov 10, 2026
- First seen by Releasebot:Nov 11, 2026
A more informative GitHub dashboard
GitHub makes its dashboard more compact and easier to scan, with customizable default tabs, more pull requests and issues visible at once, streamlined titles, and agent sessions hidden when none are available.
Since the new dashboard experience became the default, we’ve heard from developers that it used too much space to show too little. Generous padding, wrapped titles, and a low default item count meant extra navigation just to see what needed attention. In addition, “Agent sessions” remained visible even if users didn’t have any agent sessions available.
This update makes the dashboard more compact and easier to scan:
- Pin the Feed or Home tab as your default view.
- Reduced padding across pull request, issue, and agent session lists so you can see more at a glance.
- Long titles now stay on one line, with the full text available if you need it.
- Pull requests and issues now show six items by default instead of three, all while preserving any custom selections you’ve already made.
- The agent sessions section is hidden if no agent sessions exist on the user’s account.
Share your feedback in the Community discussion.
The post A more informative GitHub dashboard appeared first on The GitHub Blog.
Original source - Nov 10, 2026
- Date parsed from source:Nov 10, 2026
- First seen by Releasebot:Nov 11, 2026
GitLab Critical Patch Release: 19.5.4, 19.4.6, 19.3.8
GitLab releases patch updates for versions 19.5, 19.4, and 19.3, fixing a critical Git vulnerability that could enable command execution in Gitaly, alongside other bug fixes. Self-managed installations are urged to upgrade promptly.
On November 10, 2026, we released versions 19.5.4, 19.4.6, 19.3.8 for GitLab Community Edition and Enterprise Edition.
These versions contain important bug and security fixes, and we strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately.
GitLab.com and GitLab Dedicated are already running a patched version. GitLab.com and GitLab Dedicated customers do not need to take action.
GitLab releases fixes for vulnerabilities in patch releases. There are two types of patch releases: scheduled releases and ad-hoc critical patches for high-severity vulnerabilities. Scheduled releases are released twice a month on the second and fourth Wednesdays.
For more information, please visit our releases handbook and security FAQ.
You can see all of GitLab release blog posts here.
We are committed to ensuring that all aspects of GitLab that are exposed to customers or that host customer data are held to the highest security standards. To maintain good security hygiene, it is highly recommended that all customers upgrade to the latest patch release for their supported version. You can read more best practices in securing your GitLab instance in our blog post.
Recommended Action
We strongly recommend that all installations running a version affected by the issues described below are upgraded to the latest version as soon as possible.
When no specific deployment type (omnibus, source code, helm chart, etc.) of a product is mentioned, it means all types are affected.
Important guidance for self-compiled GitLab installations: The fix for CVE-2026-105437 is a patch to Git. Official GitLab Linux packages and container images already include the patched Git. For self-compiled installations, follow the Update Gitaly steps, which rebuild the Git binaries embedded in Gitaly. You must also rebuild the Git installation referenced by git.bin_path in config/gitlab.yml from the matching Gitaly stable branch, as described in Git. If that Git comes from your distribution’s package instead, upgrade it to 2.56.1 or later, or to a version your distribution has patched for CVE-2026-105437.
Security fixes
Table of security fixes
Title Severity CVE-2026-105437 (vulnerability in git) CriticalCVE-2026-105437 (vulnerability in git)
This release addresses the security issue CVE-2026-105437, a heap-based buffer overflow in git, by updating the version of git bundled with GitLab. This issue has been remediated on GitLab.com and GitLab Dedicated, and in GitLab CE/EE versions 19.3.8, 19.4.6, and 19.5.4.
In GitLab, under certain conditions, this vulnerability in git can result in out-of-bounds heap writes, which could be used to execute arbitrary commands within GitLab’s Gitaly environment.
Impacted Versions: GitLab CE/EE: all versions from 16.2 before 19.3.8, 19.4 before 19.4.6, and 19.5 before 19.5.4
Thanks taise for reporting this vulnerability through our HackerOne bug bounty program.
Detecting CVE-2026-105437 Exploitation Attempts
GitLab security has released a threat detection to support customers with self-managed instances, listed below. GitLab-managed infrastructure, including GitLab.com and GitLab Dedicated, is already running a patched version.
- Git merge-tree child process crash
Bug fixes
19.5.4
- [19.5] Update danger-review component to 2.2.0
- backup: Bump gocloud.dev to v0.47.0 for S3-compatible backup sink (19-5-stable backport)
- ci: Package on the omnibus branch matching the MR target (19-5-stable backport)
- ci: Use MR target branch directly for omnibus package trigger (19-5-stable)
- Backport of ‘Back off StoreScansWorker retries on lease contention’ to 19.5
- Backport of ‘Stop event purges from moving the stale scan cursor’ to 19.5
- Backport of ‘Fail closed when OpenBao login returns a non-JSON body’
- [19.5] Use the system CA bundle for gRPC default roots
- Restore the full coding environment for recommend_reviewers
- Backport of ‘Add 19.5 release note for GitLab Orbit GA’
- Backport of ‘Fail early when an API-only flow’s image has no curl’
- Backport of ‘Stop failing on stale browser console allowlist specs’ into 19.5
- Backport of ‘Read top-level dependency ancestors from direct graph edges’ into 19.5
- Backport of ‘Stop traversing full dependency graph on ingestion’ into 19.5
- Backport of “Fix use_legacy_view? for organization resource parent”
- Backport of ‘Drop stuck pages:deploy statuses when PagesWorker is exhausted’
- Backport of ‘Fence the affected package lookup with a LATERAL join’ to 19.5
- Backport of ‘Keep the relative URL root in streamed Rapid Diffs paths’
19.4.6
- [19.4] Update danger-review component to 2.2.0
- build: Build 19-4-stable on Go 1.26
- backup: Bump gocloud.dev to v0.47.0 for S3-compatible backup sink (19-4-stable backport)
- ci: Package on the omnibus branch matching the MR target (19-4-stable backport)
- ci: Use MR target branch directly for omnibus package trigger (19-4-stable)
- [19.4] Use the system CA bundle for gRPC default roots
- Backport of ‘Fix state leak from language ID constraint migration specs’ to 19.4
- Backport of ‘Batch vulnerability identifier upserts during ingestion’ to 19.4
- Backport of ‘Add concurrency limit to Security::Scans::PurgeByJobIdWorker’ to 19.4
- Backport of ‘Index SBOM occurrences for parent lookup in graph build’ into 19.4
- Backport of ‘Drop stuck pages:deploy statuses when PagesWorker is exhausted’
- Backport of ‘Fence the affected package lookup with a LATERAL join’ to 19.4
- Backport of ‘Keep the relative URL root in streamed Rapid Diffs paths’
- Backport of ‘Read top-level dependency ancestors from direct graph edges’ into 19.4
- Backport of ‘Stop traversing full dependency graph on ingestion’ into 19.4
19.3.8
- [19.3] Backport Ruby ISEQ and imemo_env Copy-on-Write GC fixes for 3.3
- [19.3] Update danger-review component to 2.2.0
- build: Build 19-3-stable on Go 1.26
- ci: Package on the omnibus branch matching the MR target (19-3-stable backport)
- ci: Use MR target branch directly for omnibus package trigger (19-3-stable)
- backup: Bump gocloud.dev to v0.47.0 for S3-compatible backup sink (19-3-stable backport)
- Backport of ‘Skip rewriting unchanged vulnerability identifiers’ to 19.3
- Backport of ‘Fix state leak from language ID constraint migration specs’ to 19.3
- [19.3] Use the system CA bundle for gRPC default roots
- Backport of ‘Skip conflicting inserts for finding identifiers’ to 19.3
- Backport of ‘Batch vulnerability identifier upserts during ingestion’ to 19.3
- Backport of the audit event fix from ‘Count CI job tokens sent as basic auth or bearer against the job user’ to 19.3
- Backport of ‘Remove unnecessary committer batch-load from mergeability fields’ to 19.3
- [19.3] Backport Ruby ISEQ and imemo_env Copy-on-Write GC fixes for 3.3
Important notes on upgrading
These versions do not include any new migrations, and for multi-node deployments, should not require any downtime.
Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-reconfigure file, which is only used for upgrades.
Updating
To update, check out our update page.
GitLab subscriptions
Access to GitLab Premium and Ultimate features is granted by a paid subscription.
Alternatively, sign up for GitLab.com to use GitLab’s own infrastructure.
Original source - Nov 10, 2026
- Date parsed from source:Nov 10, 2026
- First seen by Releasebot:Nov 11, 2026
[Added] New Bitbucket Custom Deployment check module
Bitbucket adds the bitbucket:deploymentCheck module, enabling developers to build custom deployment checks for Bitbucket Cloud.
Registering the new bitbucket:deploymentCheck module. You can use this module to build custom deployment checks for Bitbucket Cloud. The motivation for this change is laid out here, with the aim to create a centralised checks platform. Some more details on future strategy and vision is mentioned in this doc.
Original source - Nov 10, 2026
- Date parsed from source:Nov 10, 2026
- First seen by Releasebot:Nov 11, 2026
Git security vulnerabilities announced
GitHub highlights critical Git security updates that fix six vulnerabilities affecting clones, references, merges, patches, and imports. Patched GitHub services and Enterprise Server releases are available, with users urged to upgrade promptly.
Git is releasing updates addressing six security vulnerabilities affecting recursive clones, reference handling, merges, binary patches, and imports. Here is what users need to know.
Today, the Git project is releasing new versions to address six security vulnerabilities. These include arbitrary code execution when recursively cloning a malicious repository, writes to unintended files, and memory corruption when processing merges or binary patches.
The fixes are included in Git 2.56.1, with backports to Git 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3, and 2.50.2. We recommend updating to Git 2.56.1 or the patched release for your maintenance series, and updating any applications that bundle Git.
Vulnerabilities in Git
CVE-2026-111760: Code execution during recursive clones
Git checks paths before writing files into a working tree, including rejecting paths that would overwrite its own repository metadata. However, an integer truncation in Git’s index handling can cause an extremely long path to pass validation under one name and then be written using a shorter name.
An attacker can use this discrepancy to replace a submodule’s .git file with a symbolic link pointing to a directory containing malicious configuration or hooks. When Git subsequently uses that directory, it can execute attacker-controlled code during a recursive clone.
The fix rejects extremely long index entry paths before their lengths can be truncated.
CVE-2026-113408: Path traversal through a server’s advertised HEAD
When cloning an empty repository using Git protocol v2, the server can advertise a HEAD symref pointing to an unborn branch (one that has no commits yet). Git did not validate the symref’s target before storing it locally.
A malicious server can supply a name containing path-traversal components. With the files reference backend, a later operation that updates the branch can write outside the intended reference directory.
Git now validates the advertised target before accepting it. The release also validates other reference names and symbolic-reference targets received through protocol v2.
CVE-2026-114467: Stack corruption when removing signatures
When stripping GPG signatures from a message, Git assumed there would be at most two signatures. A specially crafted message containing more than two signatures can cause Git to write past the end of a fixed-size stack array.
This can be triggered by merging a tag containing more than two signatures, causing memory corruption and a potential denial of service. Hosting services that perform these merges on behalf of users can also be affected.
The fix removes the fixed-size array and handles messages with any number of signatures.
CVE-2026-114469: Out-of-bounds reads when applying binary patches
Git rejects patches larger than approximately 1 GiB because its patch application code cannot safely handle larger inputs. However, this check only considered the size of the patch as supplied.
Binary patches are compressed and encoded, so a relatively small patch can expand beyond that limit. A crafted patch can bypass the input-size check and cause an out-of-bounds read, crashing Git.
Git now also checks the declared uncompressed size before processing a binary patch.
CVE-2026-105437: Heap corruption during large merges
Git’s merge machinery calculates how much memory it needs for a merge result before writing the output. That calculation can overflow when the result is very large, including when many conflicts are combined with a large conflict-marker-size attribute.
The overflow can cause Git to allocate a buffer that is too small, then write outside it, corrupting heap memory. This affects applications and hosting services that use Git to merge untrusted content, as well as local merges.
The fix uses size-appropriate types and checked arithmetic, rejecting merges whose output size cannot be represented safely.
CVE-2026-114466: Filesystem access through fast-import streams
git fast-import reads a stream of commands to build a repository. Some commands can access files outside the repository, so Git already restricts them when they appear in an untrusted input stream.
Three additional features lacked that protection. The rewrite-submodules-from and rewrite-submodules-to features can read arbitrary files, potentially exposing their contents through error messages. The export-pack-edges option can create files or append data to existing files.
These features are now rejected when supplied through the input stream unless the caller explicitly enables --allow-unsafe-features. Only enable that option when you trust the program generating the stream.
Additional hardening
Alongside these fixes, the release adds overflow checks to related index entry allocations during checkout and tree processing. These checks complement the path-length limits above, preventing allocation sizes from being truncated or overflowing before Git copies a path into memory.
Protecting GitHub users
- We have deployed fixes for these vulnerabilities across github.com, GitHub Enterprise Cloud, and GitHub Enterprise Cloud with data residency.
- Updates for GitHub Enterprise Server are available in versions 3.19.15, 3.20.11, 3.21.9, and 3.22.4. We recommend that administrators upgrade as soon as possible.
- We are coordinating releases of GitHub Desktop and the GitHub Copilot app that include patched versions of Git.
- GitHub Codespaces and GitHub Actions will also receive patched versions of Git.
Update Git
Updating is the most effective way to protect against these vulnerabilities. Install a patched version from your operating system or Git distributor, and update applications that include their own copy of Git. Administrators should also update Git installations used by automation and services that process repositories on behalf of users.
If you cannot update immediately, clone only from trusted servers and avoid recursive clones of untrusted repositories. Avoid merging untrusted content or tags, or processing binary patches or fast-import streams from untrusted sources. These precautions do not replace installing the fixes.
Original source - Nov 9, 2026
- Date parsed from source:Nov 9, 2026
- First seen by Releasebot:Nov 10, 2026
Claude Fable 5.2 in GitHub Copilot
GitHub releases Claude Fable 5.2 in Copilot for complex, multistep coding tasks across large codebases. The model is available across Copilot plans and supported apps, with gradual rollout and data-retention requirements for most users.
Claude Fable 5.2, Anthropic’s newest Fable model, is now generally available in GitHub Copilot. You can use it for complex, multistep coding tasks across large codebases. In early testing, Fable 5.2 solved more tasks than Claude Fable 5.1 while using fewer steps and tool calls. It also completed hard tasks that earlier models missed.
Claude Fable 5.2 requires data retention by default to operate Anthropic’s safety classifiers. Zero data retention access is available for certain eligible enterprise customers. Continue reading for more details.
This model is billed at provider list pricing under usage-based billing. See Models and pricing for GitHub Copilot for details.
Availability in GitHub Copilot
Claude Fable 5.2 is available to Copilot Pro+, Max, Business, and Enterprise users. You can select the model in the model picker in:
- Visual Studio Code
- Visual Studio
- Copilot CLI
- GitHub Copilot coding agent
- GitHub Copilot app
- github.com
- GitHub Mobile on iOS and Android
- JetBrains IDEs
- Xcode
- Eclipse
Rollout will be gradual. Check back soon if you don’t see it yet.
Enabling access
Copilot Enterprise and Copilot Business plan administrators must enable the Claude Fable 5.2 policy in Copilot settings. The policy is off by default.
Claude Fable 5.2 requires data retention by default. When Claude Fable 5.2 is used, Anthropic retains data, including prompts and outputs, to operate safety classifiers that detect harmful use. Retained data is not used to train Anthropic’s models. Other Claude models, except for Fable 5, Fable 5.1, and Fable 5.2, continue to operate under zero data retention (ZDR).
To learn more, see Anthropic’s data retention practices for Mythos-class models. Enabling the Claude Fable 5.2 policy constitutes acknowledgment of this requirement. Leaving it off keeps Claude Fable 5.2 unavailable to your organization.
Zero data retention access for eligible enterprises
Eligible customers can use Claude Fable 5.2, Claude Fable 5.1, and Claude Fable 5 with zero data retention through the end of the calendar year under a time-bound exemption while Anthropic rolls out Enterprise Frontier Safeguards (EFS). After that point, continued use of the models will require EFS, which will enable automated safety monitoring while also giving eligible customers more options for how their data is retained. This includes the option to use storage and encryption keys under their own control. Between now and then we will be working with Anthropic to provide feedback on EFS.
If your enterprise is approved for access, Claude Fable 5.2, Fable 5.1, and Fable 5 requests will be routed to zero data retention endpoints when the model is enabled. To learn whether your organization qualifies, contact your GitHub account team. GitHub Support cannot determine eligibility or enable access.
Approval will not automatically enable the models. After approval, a Copilot Enterprise or Copilot Business administrator must still enable the Claude Fable 5.2 policy in Copilot settings.
Learn more
To explore all models available in GitHub Copilot, see our documentation on models and get started with Copilot.
Share your feedback
Join the GitHub Community to share your feedback.
The post Claude Fable 5.2 in GitHub Copilot appeared first on The GitHub Blog.
Original source