If you still need help, visit Application Lifecycle Management and book in a consultant.
Source control is the backup of your code, as well as your tool for tracking changes over time.
With source control, we can share project code and collaborate with other team members. Using it allows us to track changes, compare code, and even roll-back if required. Moreover, it keeps our code safe and that is the most important part.
Learn the Git commands every developer should know to keep your history clean, your team in sync and your pull requests stress free.
The .gitignore file tells Git which files to ignore and not track in your repository. Every Git project should have a .gitignore file to keep unnecessary files out of the repo. For example, cache files should not be included in the main repository.
Do you know the best way to manage NuGet packages with Git? You can get into all sorts of trouble by including your packages in source control.
Using the Azure DevOps API you can programmatically get a list of commits from your repository with only a HTTP request.
Figure: HTTPS GET commits from your repository
Using HTTPS with basic authentication, make a GET request to a URL as below, substituting in your project details. A JSON object will be returned. To quickly create classes from a JSON response, see the rule Do you know how to easily get classes from a JSON response?
Figure: Using the Chrome extension Postman to execute our request with Basic Authentication
For a C# implementation, see this blog post Getting Git Commits with the VSO REST API.
Like most skills, it can take a little while to get your head around Git. We rate our devs and the devs that we mentor on the following scale.
Where are you?
Branch protection is a feature in version control software that allows teams to define rules and restrictions around who can make changes to specific branches, what types of changes are allowed, and if there are conditions that have to be met.
When you merge a branch you end up with messy merge commits.
Rebasing might take a bit to get your head around, but you get a much cleaner project history.
Rebasing is great for ensuring a clean project history... but it can be dangerous in inexperienced hands.
Do you know that remote branches on your machines are not automatically removed in most of Git clients?
Git has become the defacto standard for version control systems. It's distributed and decentralized and promotes working disconnected as default. It also takes away the pain of branching and merging and has a built in code review system with pull requests. Everybody should be using Git, and if you're not, you should be migrating the Git using one of the below tools.
- VisualStudio.com - Import Repository
- Git-Tf
- Git-Tfs (recommended)
When you create a new git repository and need to push it to VSTS you need to provide login credentials.
It isn't always clear how to do this.
After you use the right tool to migrate from TFVC to Git, there's a few more things you need to do to clean things up for a new user joining the project. By default, if there is a TFVC repository, that will become the default in the UI.
Unfortunately, you can't kill the TFVC repository and make Git the default one, so there's a few steps you need to follow.
When starting to work on a project, it's common to wonder whether to fork an existing repository or create a new branch for it. Before making this decision, it's important to consider the key differences between the two options.
Maintaining a clean git history is important for readability and understanding the changes that have been made to a codebase. This is especially important when working in a team, as it allows you to see the changes that have been made to a file over time, and who made them. This can be useful for debugging, and for understanding why a particular change was made.
Things that create a good git history include:
Updating commit information can be essential for maintaining accurate project history or correcting errors. Whether you need to change a commit date for clarity, compliance, or other reasons, you have a couple of methods at your disposal.
This rule outlines how to change the date of an existing commit using both a manual CLI approach and an automated script.
In today’s development world, teams often consist of developers working on different operating systems (OS), such as Windows, macOS, and Linux. While each OS has its own strengths, managing a cross-platform development environment can introduce challenges.
Issues like inconsistent line endings, platform-specific setup scripts, and configuration mismatches can lead to headaches for both individual developers and the team as a whole.