# GitHub Projects bulk edit: status and labels Author: Sahil Dave Canonical: https://gitsu.app/guides/github-projects-bulk-edit Published: 2026-10-11 Updated: 2026-10-11 Last checked: 2026-10-11 > **TL;DR** GitHub Projects supports bulk editing in table layout: copy a field cell, select destination cells and paste, or drag its handle to fill neighbouring cells. For a visible selection toolbar, open the project in Gitsu, select the intended rows and choose Status, Priority, Assignee, Labels or Milestone. Gitsu keeps this workflow on your existing GitHub records and reports refused item writes. GitHub Projects bulk editing already exists in its native table layout. Copy a field value into several cells or use the fill handle to apply it to neighbouring rows. Gitsu offers a different entry point for routine triage: select issues and use a visible toolbar for Status, Priority, Assignee, Labels and Milestone. The important choice is which record each action changes. A project Status and an issue's open or closed state are separate decisions, even when the same row displays both. ## How do I bulk edit fields in GitHub Projects? Use GitHub's table layout to copy one field cell into several destination cells. 1. Open a project table and select the source cell. 2. Copy with Command+C on Mac or Ctrl+C on Windows. 3. Select destination cells in the same field. Use modifier-click or a Shift selection for a range. 4. Paste with Command+V or Ctrl+V. GitHub also provides a handle at a copyable cell's lower-right edge. Drag it to fill neighbouring cells. Select cells and press Delete or Backspace to clear them. After a bulk table change, the notice offers **Undo**. These are native capabilities documented in [editing project items](https://docs.github.com/en/issues/planning-and-tracking-with-projects/managing-items-in-your-project/editing-items-in-your-project). A team comfortable with the table may already have the workflow it needs. Gitsu's advantage here is the selection toolbar and its specific handling of issue metadata, rather than inventing bulk editing where GitHub has none. ## Which changes belong to the project and which belong to the issue? Status and other project fields describe the project card; labels, assignees, milestones and issue state describe the underlying GitHub issue. That difference matters when you plan a cleanup. Moving work to a Done status expresses a planning decision. Closing the issue expresses an issue lifecycle decision. Decide whether you mean one or both before selecting a batch. A label such as `needs-review` answers another question again, and should have a meaning the team understands. Gitsu's mutation mapping makes this boundary explicit. A project-field change targets the project item ID. Native issue changes target the underlying content ID. Draft items without an underlying issue can take a project field but cannot take native issue metadata through that path. A mixed selection therefore needs attention even when all the rows look similar. For a hypothetical backlog review, select the confirmed release candidates to set project Priority. Select only actual repository issues when adding a repository label. Review a smaller set individually before closing them. These are workflow recommendations; they do not require the team to adopt a new status vocabulary. ## How do I bulk edit in Gitsu? Select the intended visible items in Gitsu's list, then choose the field and value in the bulk toolbar. 1. Open the GitHub Project and switch to its list view. 2. Filter to the work you intend to change and check the loading notice. 3. Select the rows. In the list keyboard flow, focus an item and press `X` to toggle its selection; Shift+X selects a range. 4. Check the selection count, then choose **Status**, **Priority**, **Assignee**, **Labels** or **Milestone**. 5. Check any reported failures and inspect the resulting GitHub records when the change matters. The current toolbar also offers closing as completed, closing as not planned and reopening. Pick those actions for a lifecycle decision rather than using them as a shortcut for a project-field change. ![Gitsu bulk toolbar showing 3 selected items and Status, Priority, Assignee and Labels controls](/bulk.webp) This existing product crop shows the selection count and several toolbar controls. The source check also covers Milestone and lifecycle actions outside the crop. The image is not a live test of your project or evidence that a particular GitHub write succeeded. ## Does bulk adding labels overwrite the labels already there? Gitsu adds the labels you name while preserving the other labels on each selected issue. The same principle applies to assignees. The bulk picker can add or remove named people; clearing the full set is a separate gesture. That distinction is useful when selected issues have different owners or categories. Adding `needs-review` should not silently erase `bug`, and adding one reviewer as an assignee should not imply that every other assignee is unwanted. Suppose two selected issues already carry different component labels. You want to mark both for review without rewriting their component classification. Use an additive label action. If the goal is to remove an obsolete label, use removal. If the goal really is to leave no labels, use clear after confirming that broader intent. This is a concrete trade-off in Gitsu's bulk editing implementation. It treats a named addition as a change to part of a set. Status and Priority are different because choosing a single value replaces that field's previous value. The toolbar should be read in terms of the change you intend, not as a form claiming every selected issue already has identical metadata. ## What happens if only some bulk writes succeed? Gitsu reports failed items separately, and a refused item's optimistic change rolls back without undoing a successful sibling's change. The implementation dispatches each selected item's update before awaiting the batch results. That makes the initial screen response immediate, but it does not establish that GitHub accepted every change. The result collector records failures, including rejected requests and rows that cannot take the operation. The toolbar names a bounded set of failed titles and counts any additional failures. Treat that report as the starting point for the next action. Review the named rows and the intended metadata before retrying. Repeating an entire batch without checking what succeeded makes the session harder to reason about. A draft item failing a native label operation needs a different decision from an issue whose request was refused. Do not describe the batch as an atomic transaction. Its useful property is that one failed item does not erase a sibling's successful change. For a consequential cleanup, verify a sample of accepted changes on GitHub and inspect every reported failure. Fast feedback is helpful; it is not a receipt for the whole selection. ## What should I check before selecting a whole backlog? Check the filter, the visible selection and the project's loading notice before applying a broad edit. Gitsu's bulk toolbar receives selected items from the currently filtered list. Hidden selected rows do not enter that visible batch. This makes the active view part of the action's scope, so changing the filter can change which selected rows the toolbar acts on. Read the count again after narrowing the view. The [current capability guide](/features/current-capabilities) records one active project and up to 2,000 loaded items per project. A local filtered list cannot certify the state of an incomplete larger project. Keep a broad cleanup in GitHub's native interface if you need records beyond Gitsu's loaded set. ## How do I use Gitsu for my next bulk update? Open your project in Gitsu, filter to the intended work and use the selection toolbar to apply one clear change without opening each issue separately. Start with a small batch whose expected result you can inspect. The web board is free, and the [getting-started guide](/docs/getting-started) connects your project. Paid Seats add the macOS app, agents and MCP; [pricing](/pricing) keeps those choices separate from the board task taught here. ## How we checked A source check of Gitsu's bulk toolbar and mutation mapping: additive labels and assignees, project-card versus issue-node writes, visible-selection scope and per-item failure reporting. No live GitHub edits were performed for this guide. Public references: - https://docs.github.com/en/issues/planning-and-tracking-with-projects/managing-items-in-your-project/editing-items-in-your-project ## Frequently asked questions ### Can I bulk edit GitHub Projects? Yes. GitHub Projects tables support copying and pasting a field value into multiple cells, dragging to fill cells and clearing selected cells. GitHub also offers Undo after a table bulk change. ### How do I change the status of several issues in Gitsu? Open the project in list view, select the intended visible rows, then choose a Status value in the bulk toolbar. Status is a project field; closing an issue is a separate action. ### Does adding a label in Gitsu remove existing labels? No. Adding a label uses an additive change. Remove and clear are separate operations. The assignee picker likewise supports adding or removing the named people without replacing everybody else. ### Can draft issues receive labels and assignees in bulk? Gitsu can update a draft item's project field, but a draft without an underlying issue node cannot receive native issue changes such as labels, assignees or milestones. Those rows are reported as failures for that change. ### Is Gitsu bulk editing free? The Gitsu web board is free. The macOS app, agents and MCP require a paid Seat. Bulk editing here is a board workflow, with one selected project and up to 2,000 loaded items. ## Related resources - [GitHub Projects filter syntax: tested examples](https://gitsu.app/guides/github-projects-filter-syntax) - [Gitsu features for daily GitHub board work](https://gitsu.app/features/current-capabilities) - [Getting started with the Gitsu Web App](https://gitsu.app/docs/getting-started)