Git branches allow me to isolate my changes from other work being done in the project. Best practice dictates that you create a new branch for every feature or fix you are working on. Once you have made the changes in your branch, you can commit your changes to your local repo to save the changes on that branch, and then ultimately share them with the team.
Creating a Local Branch
In Team Explorer, from the Home page, click the Branches button.
Click the New Branch link at the top. A branch name is required. You want to make sure this is a descriptive branch name.
Yes, I realize “Feature 01” is not that descriptive, but hey, it’s a demo.
Now what I expect to happen is that, once I click the Create Branch button, this is going to create a local branch off the master branch.
Click the Create Branch button.
Well, it looks like you can’t have spaces in the name. Kinda would have been nice to have the interface warn me of that before I click the button. I changed the name to Feature01 and clicked the Create Branch again.
I now have Feature01 listed as a branch. And I can tell (I think) that it is the active branch, because it appears in parenthesis beside the repo name. And I can prove this to myself using the Git CLI to navigate to the local repo:
Time to make some changes. In this case, I’m going to create a new folder and add a PowerShell file to it.
So I’ve added a folder and a PS Script. I’m done making my changes in the branch, so I should commit them locally. Click the Home button in Team Explorer to go to the Home page, then click the Changes button.
From here, I can enter a message describing the commit and click Commit All. This will stage and commit the changes to the local repo. I could, if I wanted, cherry pick files and put them into staging, and then commit just the staged files as well. I’m going to click Commit All.
My changes have been committed locally (I can see the commit information in the Output window). The next step will be to share these changes back into the online repo in VSTS.