Replaces the previous contents of this branch, which added editor/OS and
shared-library rules that belong in Global/ per the contributing guidelines.
Two changes remain, both scoped to Julia.gitignore:
* `*.jl.*.mem` — `--track-allocation` writes `<file>.jl.<pid>.mem`, so the
existing `*.jl.mem` rule never matches the files Julia actually produces.
This mirrors the `--code-coverage` section, which already carries both
`*.jl.cov` and `*.jl.*.cov`.
* `.CondaPkg/` — CondaPkg creates this directory inside the active project
and populates it with a machine-specific Conda environment.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- The “Builds” folder pattern would match source code files starting
with “Builds”. Corrected to only match directories with Xojo’s
Builds folder naming convention.
- Removed blank line between comment heading and patterns
Keep only documented local/high-churn agent artifacts active by default, preserving common shared instruction/config files as commented opt-in examples
### Description
Improved grammar and clarity in the README file.
### Changes made
- Fixed pluralization ("project" → "projects")
- Improved sentence structure for better readability
- Added missing article ("a") in pull request sentence
### Why this is useful
- Improves readability and professionalism of documentation
- Helps maintain consistency across the repository
Removes the root version since I can't properly gauge the impact
and widespread use of AL easily. I also did this because the community
version is simpler and more complete in my opinion.
Removed the checklist item for ensuring CI is passing. We don't really have CI as of yet and it's confusing to list that requirement. If we do add CI, we'll make it required instead of adding it to the template checklist.
Adds clarification around our expectations for contributions and
how contributions will be handled when they don't meet our requirements.
Updates template to lean into our contribution guidelines.
Cleans up duplicate wording around our contribution guidelines.
ConTeXt generates .tua and .tuc files (utility cache) during each run. These files store document metadata between compilations and are not part of the source, so they should be ignored.
As of Godot 4.2 the editor has a Windows-specific workaround for loading extension libraries.
Before the extension library is loaded the Godot editor creates a temp copy of the extension library `.dll` file with a `~` prefix (e.g. `example.dll` => `~example.dll`).
When the extension library is unloaded the Godot editor deletes the temp copy.
These copied `~*.dll` files are temporary and should be ignored.
References:
Godot 4.2 changelog
https://godotengine.org/article/godot-4-2-arrives-in-style/#gdextension
Godot PR #80188 GDExtension: Copy DLL to a temp file before opening
https://github.com/godotengine/godot/pull/80188
oh-my-opencode excludes the sisyphus working directory in their own repo, so it seems to be best practice. Also, the directory captures agent/runtime state, so it should not be shared.
As announced in the devlog https://ziglang.org/devlog/2026/#2026-02-06 all dependencies will now be fetched in the `zig-pgk` directory.
Unless you have a specific reason to include them in your source code, they should be ignored.
Cribbed directly from the Element Flatpak's .gitignore file at
https://github.com/flathub/im.riot.Riot/blob/master/.gitignore, simply
because Element is a pretty popular application.
Note in particular that this covers all directories that will be
created by the Flatpak tutorial's suggested `flatpak-builder` command:
https://docs.flatpak.org/en/latest/first-build.html#build-and-install
`repo` is the OSTree repository that the built Flatpak will be
"published" to for testing, `.flatpak-builder` is an internal build
directory, and `builddir` is another, user-specified build directory.
The current `coverage.*` pattern includes `*.go` files as well. If you use `go vendor`, this causes the following files to be excluded:
- `vendor/golang.org/x/text/internal/language/coverage.go`
- `vendor/golang.org/x/text/language/coverage.go`
This becomes a nightmare to troubleshoot why the local build works, yet a CI fails (as the files were not committed).
Adding `!coverage.go` ensure that `*.go` files do not get accidentally excluded.
Historically R users have used the .Renviron file for storing environmental variables such as secrets, credentials, API keys etc. However, I believe there are several compelling reasons for adding .env to the .gitignore too:
1. The dotenv R package was created to allow users to use .env instead of .Renviron. The package has a significant number of downloads. https://github.com/gaborcsardi/dotenv
2. .env files are standard in many other programming languages. It wouldn't be that out of the unexpected to think R users might end up with an .env file because a python user on their team contributed files to the repo, the R user started programming in nodejs and is used to working with .env file, or a repo is in the process of being translated from a language that uses .env to R.
3. LLMs are making programming accessible to people who may not have much previous experience handling credentials and security. One of the first steps many of these users have to do is store LLM provider API keys somewhere. I worry about a new R user adapting a python workflow or an R workflow that recommends using an .env file and then accidentally committing their LLM API keys to a public repo.
4. I can't think of why an R user would create an .env file for any other reason other than storing credentials and environmental variables. If, for whatever reason, they need to commit an .env file, they can remove that part from the template, but I think the risk of accidentally exposing sensitive credentials justifies adding .env files to the template and not commenting it out by default.
Remove Boss dependency manager vendor folder from ignore. This is interfering with projects that contains a "modules" folder regardless of Boss dependency being present.
/UIElementsSchema is an auto-generated folder created by Unity. It is used in the UI Toolkit.
In Unity discussions, staff have confirmed that this folder can be safely ignored.
https://discussions.unity.com/t/uielementsschema/805120
This pull request adds a .gitignore file specifically designed for projects using Bun as a package manager. The bun.gitignore file includes rules to ignore common files and directories generated during development with Bun, as well as other tools and frameworks frequently used in conjunction with Bun.
We are planning to add a [new output path format](https://github.com/dotnet/designs/pull/281) to .NET projects which will by default put output in an `.artifacts` folder. So this PR adds that folder to the Visual Studio .gitignore file.
The first support for this will be in .NET 8 Preview 3. We will be looking for feedback through the preview process, so it's possible that the folder name or other aspects of the design could change as a result.
@@ -8,16 +15,18 @@ Please provide some background for this change.
### Links to documentation supporting these rule changes
_TODO_
<!---
Link to the project docs, any existing .gitignore files that project may have in it's own repo, etc
Link to the project docs, any existing .gitignore files that project may have in its own repo, etc
--->
### If this is a new template
Link to application or project’s homepage: TODO
### Merge and Approval Steps
- [ ] Confirm that you've read the [contribution guidelines](https://github.com/github/gitignore/tree/main?tab=readme-ov-file#contributing-guidelines) and ensured your PR aligns
- [ ] Ensure CI is passing
- [ ] Get a review and Approval from one of the maintainers
<!---
Please ensure you accomplish these tasks in order to get your contribution accepted
--->
- [ ] I have read the [contribution guidelines](https://github.com/github/gitignore/tree/main?tab=readme-ov-file#contributing-guidelines) and understand my PR will be closed if it doesn't meet these guidelines
<!---
Once done, please wait for a GitHub maintainer to review your PR and if necessary,
@@ -24,16 +24,21 @@ We support a collection of templates, organized in this way:
with popular programming languages and technologies. These define a meaningful
set of rules to help get started, and ensure you are not committing
unimportant files into your repository.
- [`Global`](./Global) contains templates for various editors, tools, and
operating systems that can be used in different situations. We recommend
adding these to your [global template](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer) or merging these rules into your project-specific templates if you want to use them permanently.
- [`Global`](./Global) contains templates for various editors, tools and
operating systems that can be used in different situations. It is recommended
that you either [add these to your global template](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer)
or merge these rules into your project-specific templates if you want to use
them permanently.
- [`community`](./community) contains specialized templates for other popular
languages, tools and project, which don't currently belong in the mainstream
languages, tools, and projects that don't currently belong in the mainstream
templates. These should be added to your project-specific templates when you
decide to adopt the framework or tool.
## What makes a good template?
First and foremost, a template contribution must adhere to our
[Contributing Guidelines](CONTRIBUTING.md).
A template should contain a set of rules to help Git repositories work with a
specific programming language, framework, tool or environment.
@@ -48,7 +53,7 @@ If you have a small set of rules, or want to support a technology that is not
widely in use, and still believe this will be helpful to others, please read the
section about [specialized templates](#specialized-templates) for more details.
Include details when opening pull request if the template is important and visible. We
Include details when opening a pull request if the template is important and visible. We
may not accept it immediately, but we can promote it to the root at a later date
based on interest.
@@ -59,33 +64,7 @@ include your language, tool, or project, it’s not because it’s not awesome.
## Contributing guidelines
We’d love for you to help us improve this project. To help us keep this collection
high quality, we request that contributions adhere to the following guidelines.
- **Provide a link to the application or project’s homepage**. Unless it’s
extremely popular, there’s a chance the maintainers don’t know about or use
the language, framework, editor, app, or project your change applies to.
- **Provide links to documentation** supporting the change you’re making.
Current, canonical documentation mentioning the files being ignored is best.
If documentation isn’t available to support your change, do the best you can
to explain what the files being ignored are for.
- **Explain why you’re making a change**. Even if it seems self-evident, please
take a sentence or two to tell us why your change or addition should happen.
It’s especially helpful to articulate why this change applies to _everyone_
who works with the applicable technology, rather than just you or your team.
- **Please consider the scope of your change**. If your change is specific to a
certain language or framework, then make sure the change is made to the
template for that language or framework, rather than to the template for an
editor, tool, or operating system.
- **Please only modify _one template_ per pull request**. This helps keep pull
requests and feedback focused on a specific project or technology.
In general, the more you can do to help us understand the change you’re making,
the more likely we’ll be to accept your contribution quickly.
Please see our [Contributing Guidelines](CONTRIBUTING.md).
## Versioned templates
@@ -116,7 +95,7 @@ For example, this template might live at `community/DotNet/InforCRM.gitignore`:
```gitignore
# gitignore template for InforCRM (formerly SalesLogix)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.