Source control - knowlesy/AZ400 GitHub Wiki
There are different types of project boards:
User-owned project boards: Can contain issues and pull requests from any personal repository. Organization-wide project boards: Can contain issues and pull requests from any repository that belongs to an organization. Repository project boards: Are scoped to issues and pull requests within a single repository.
Azure Boards is a customizable tool to manage software projects supporting Agile, Scrum, and Kanban processes by default
You can track your work using the default work item types such as user stories, bugs, features, and epics. It's possible to customize these types or create your own.
Delivery plans are fully interactive, supporting the following tasks:
View up to 15 team backlogs, including a mix of backlogs and teams from different projects. View custom portfolio backlogs and epics. View work that spans several iterations. Add backlog items from a plan. View rollup progress of features, epics, and other portfolio items. View dependencies that exist between work items
• From GitHub:
• Support integration for all repositories for a GitHub account or organization or select repositories.
• Add or remove GitHub repositories participating in the integration and configure the project they connect to.
• Suspend Azure Boards-GitHub integration or uninstall the app.
• From Azure Boards:
• Connect one or more GitHub repositories to an Azure Boards project.
• Add or remove GitHub repositories from a GitHub connection within an Azure Boards project.
• Completely remove a GitHub connection for a project.
• Allow a GitHub repository to connect to one or more Azure Boards projects within the same Azure DevOps organization or collection.
Azure Boards-GitHub integration supports the following operational tasks: • Create links between work items and GitHub commits, pull requests, and issues based on GitHub mentions. • Support state transition of work items to a Done or Completed state when using GitHub mention by using fix, fixes, or fixed. • Support full traceability by posting a discussion comment to GitHub when linking from a work item to a GitHub commit, pull request, or issue. • Show linked to GitHub code artifacts within the work item Development section. • Show linked to GitHub artifacts as annotations on Kanban board cards. • Support status badges of Kanban board columns added to GitHub repositories. The following tasks aren't supported at this time: • Query for work items with links to GitHub artifacts. However, you can query for work items with an External Link Count greater than 0.
A Source control system (or version control system) allows developers to collaborate on code and track changes. Use version control to save your work and coordinate code changes across your team. Source control is an essential tool for multi-developer projects.
Without version control, you're tempted to keep multiple copies of code on your computer. It could be dangerous. Easy to change or delete a file in the wrong code copy, potentially losing work.
Maintains history of changes. Version control keeps a record of changes as your team saves new versions of your code. This history can be reviewed to find out who, why, and when changes were made. The history gives you the confidence to experiment since you can roll back to a previous good version at any time. The history lets your base work from any code version, such as fixing a bug in an earlier release. Automate tasks. Version control automation features save your team time and generate consistent results. Automate testing, code analysis, and deployment when new versions are saved to version control.
- Make small changes. In other words, commit early and commit often. Be careful not to commit any unfinished work that could break the build.
- Do not commit personal files. It could include application settings or SSH keys. Often personal files are committed accidentally but cause problems later when other team members work on the same code.
- Update often and right before pushing to avoid merge conflicts.
- Verify your code change before pushing it to a repository; ensure it compiles and tests are passing.
- Pay close attention to commit messages, as it will tell you why a change was made. Consider committing messages as a mini form of documentation for the change.
- Link code changes to work items. It will concretely link what was created to why it was created—or modified by providing traceability across requirements and code changes.
- No matter your background or preferences, be a team player and follow agreed conventions and workflows. Consistency is essential and helps ensure quality, making it easier for team members to pick up where you left off, review your code, debug, and so on. From https://learn.microsoft.com/en-gb/training/modules/introduction-to-source-control/5-explore-best-practices-for
A typical centralized source control workflow If working with a centralized source control system, your workflow for adding a new feature or fixing a bug in your project will usually look something like this: • Get the latest changes other people have made from the central server. • Make your changes, and make sure they work correctly. • Check in your changes to the main server so that other programmers can see them.
Advantages over centralized source control The act of cloning an entire repository gives distributed source control tools several advantages over centralized systems:
Doing actions other than pushing and pulling changesets is fast because the tool only needs to access the local storage, not a remote server. Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once. Everything but pushing and pulling can be done without an internet connection. So, you can work on a plane, and you won't be forced to commit several bug fixes as one large changeset. Since each programmer has a full copy of the project repository, they can share changes with one, or two other people to get feedback before showing the changes to everyone. Disadvantages compared to centralized source control There are almost no disadvantages to using a distributed source control system over a centralized one.
Distributed systems don't prevent you from having a single "central" repository; they provide more options.
There are only two major inherent disadvantages to using a distributed system:
If your project contains many large, binary files that can't be efficiently compressed, the space needed to store all versions of these files can accumulate quickly. If your project has a long history (50,000 changesets or more), downloading the entire history can take an impractical amount of time and disk space.
Also, if you are used to storing compiled binaries in your source repos, stop!
Use Azure Artifacts or some other package management tool to store binaries for which you have source code.