back to home

EndBug / add-and-commit

:octocat: Automatically commit changes made in your workflow run directly to your repo

1,270 stars
123 forks
15 issues
TypeScriptJavaScript

AI Architecture Analysis

This repository is indexed by RepoMind. By analyzing EndBug/add-and-commit in our AI interface, you can instantly generate complete architecture diagrams, visualize control flows, and perform automated security audits across the entire codebase.

Our Agentic Context Augmented Generation (Agentic CAG) engine loads full source files into context on-demand, avoiding the fragmentation of traditional RAG systems. Ask questions about the architecture, dependencies, or specific features to see it in action.

Source files are only loaded when you start an analysis to optimize performance.

Embed this Badge

Showcase RepoMind's analysis directly in your repository's README.

[![Analyzed by RepoMind](https://img.shields.io/badge/Analyzed%20by-RepoMind-4F46E5?style=for-the-badge)](https://repomind.in/repo/EndBug/add-and-commit)
Preview:Analyzed by RepoMind

Repository Overview (README excerpt)

Crawler view

Add & Commit You can use this GitHub Action to commit changes made in your workflow run directly to your repo: for example, you use it to lint your code, update documentation, commit updated builds, etc... Table of contents • Inputs • Outputs • FAQs • Examples • Contributors • Articles Inputs Add a step like this to your workflow: Git arguments Multiple options let you provide the arguments that you want the action to use. It's important to note that these arguments **are not actually used with a CLI command**, but they are parsed by a package called , and then used with . What does this mean for you? It means that strings that contain a lot of nested quotes may be parsed incorrectly, and that specific ways of declaring arguments may not be supported by these libraries. If you're having issues with your argument strings you can check whether they're being parsed correctly either by enabling debug logging for your workflow runs or by testing it directly with (RunKit demo): if each argument and option is parsed correctly you'll see an array where every string is an option or value. Adding files The action adds files using a regular command, so you can put every kind of argument in the option. For example, if you want to force-add a file: . The script will not stop if one of the git commands doesn't match any file. E.g.: if your command shows a "fatal: pathspec 'yourFile' did not match any files" error the action will go on, unless specified otherwise with . You can also use JSON or YAML arrays (e.g. , ) to make the action run multiple commands: the action will log how your input has been parsed. Please mind that your input still needs to be a string because of how GitHub Actions works with inputs: just write your array inside the string, the action will parse it later. Deleting files The option can be used if a predetermined list of files needs to be removed. It runs the command, so you can pass every kind of argument with it. As if with the input, you can also use JSON or YAML arrays to make the action run multiple commands. If you want deleted files to be auto-detected and committed, you can use the / git arguments. Pushing By default the action runs the following command: . You can use the input to modify this behavior, here's what you can set it to: • : this is the default value, it will behave as usual. • : this prevents the action from pushing at all, no command is run. • any other string: The action will use your string as the arguments for the command. Please note that nothing is used other than your arguments, and the command will result in (no remote, no branch, no , you have to include them yourself). One way to use this is if you want to force push to a branch of your repo: you'll need to set the input to, for example, . Creating a new branch If you want the action to commit in a new branch, you can use the input. Please note that if the branch exists, the action will still try push to it, but it's possible that the push will be rejected by the remote as non-straightforward. If that's the case, you need to make sure that the branch you want to commit to is already checked out before you run the action. If you're **really** sure that you want to commit to that branch, you can also force-push by setting the input to something like . If you want to commit files "across different branches", here are two ways to do it: • You can check them out in two different directories, generate your files, move them to your destination and then run in the destination directory using the input. • You can manually commit those files with commands as you would on your machine. There are several ways to do this depending on the scenario. One of them if to stash your changes, checkout the destination branch, and popping the stash. You can then use the action as usual. Please note that this is just an example and may not work for you, since your use case may be different. Tagging You can use the option to enter the arguments for a command. In order for the action to isolate the tag name from the rest of the arguments, it should be the first word not preceded by an hyphen (e.g. is ok). You can also change the arguments of the push command for tags: every argument in the input will be appended to the command. For more info on how git arguments are parsed, see the "Git arguments" section. Outputs The action provides these outputs: • : whether the action has created a commit ( or ) • : the full SHA of the commit that has just been created • : the short 7-character SHA of the commit that has just been created • : whether the action has pushed to the remote ( or ) • : whether the action has created a tag ( or ) • : whether the action has pushed a tag ( or ) For more info on how to use outputs, see "Context and expression syntax". FAQs Working with PRs By default, when you use on a PR, it will checkout the head commit in a detached head state. If you want to make some changes, you have to checkout the branch the PR is coming from in the head repo. You can set it up like this: You can find the full docs for payloads of events here. If you're planning on running this only on "internal" PRs (where head and base are in the same repo) then you can omit the input. If you're planning to use this with PRs coming from other forks, please keep in mind that you might not have write access to those repos. You can try setting up the repo with your PAT, as explained in the "About tokens" paragraph of this section. Keep in mind that this "custom checkout" is meant only for PRs: if your workflow runs on multiple events (like or ), you could try having this step run only for events, while other ones will trigger the usual checkout. If you wish to do so, you can use the property, here's the docs. About tokens When pushing, the action uses the token that the local git repository has been configured with: that means that if you want to change it you'll need to do it in the steps that run before…