To fit more workflows, there are several options you can configure. From the new Issues view, you can do exactly that. Working on issuesĪ common workflow is to look at your issues, pick one to work on, create a branch to work in, make some commits, then merge your changes back into main with a pull request. Finally, if there is failure information in the terminal, you can just copy the output to the clipboard and create an issue using GitHub Issues: Create Issue from Clipboard.
If you just need a pointer to some code, you can also use the GitHub Issues: Copy GitHub command. To reduce the barrier and context loss when creating an issue while you're deep in the source, there are a few new ways to create issues:įrom a //TODO comment (configurable with githubIssues.createIssueTriggers), you can create and assign an issue without leaving VS Code.Īnd from a selection, you can quickly create an issue with a back to the source code where it originated, using the GitHub Issues: Create Issue from Selection command. Having //TODOs scattered throughout the codebase is hard to keep track of when you have many contributors (though it's safe to say that we've all done it), but creating an issue and referencing it in the //TODO is trackable. Or, if the finder of the bug is also the owner, we'll often leave a //TODO comment as a reminder to come back to it. When we find a bug in VS Code while working on some source code, we create an issue and assign it to whoever owns that area.
The list of users includes the collaborators in the currently open repository. The queries use the GitHub search syntax. The list of possible issues is configurable with the setting githubIssues.queries, so if you work across multiple repositories, you can include queries for those issues. In Markdown files, issues complete as a Markdown link, and in other files, issues complete as a simple issue number ( #1234). In the Git commit textbox, you can format your issue completion with the githubIssues.issueCompletionFormatScm setting. To easily add this context, we have added completion suggestions for issues and users. Issue context is typically needed in commit messages to reference an issue the commit resolves, within source code files, and in Markdown (such as a changelog). The VS Code proposed API has many developer references to make it obvious who's responsible for the proposals. We also often reference users in our codebase.
Sublime merge git failed with exit code 128 full#
Issue hovers work on full issue URLs, issue comment URLs, issues referenced by number ( #1234), and issues referenced by owner/repository#1234 (for example Microsoft/vscode#1234). Now, by gaining this issue context through hovers, you don't need to break your flow to learn more. While linking gives a pointer to more information, to actually learn more you need to leave the editor. If you do a search for issue references in the VS Code repo, you'll see plenty of issues mentioned. Linking to issues in source code is a normal part of our workflow, especially when there's some logic that's difficult to understand or when there's a //TODO comment that needs action. We do want to make connections that aren't already there. We don't want to reinvent UI that GitHub already does well. For example, giving more context for an issue in a code comment is part of that goal, but adding full issue management into VS Code doesn't fit as well. Instead, our goal was to bring issues into the inner development loop in a flexible way. It was important that we not prescribe overly specific workflows. By working with our own extension API, we ensure the API has the features that extension authors need, and other repository providers can implement similar integration. Instead, we will recommend the extension when we detect that a user's open repository uses GitHub.
We did not want to add GitHub functionality directly to the core VS Code editor because there are many source control options. Issues and pull requests often go hand in hand, so including them in the same GitHub Pull Requests and Issues extension was a logical step as much of the same GitHub API is needed for both issues and pull requests.
Starting with VS Code version 1.45, this new support to move the issues and source code closer together will be available in the GitHub Pull Requests and Issues extension (formerly named GitHub Pull Requests). This addition complemented the GitHub Pull Request work we announced over a year ago. Given how important issues are to our team and other GitHub projects, we wanted to add GitHub issues integration to VS Code. From our detailed iteration plans to individual bugs, we track everything as GitHub issues. Node.js Development with Visual Studio Code and Azureīy Alex Ross, the Visual Studio Code team, we use GitHub issues to track all of our work.
0 kommentar(er)
