>> Hi, I'm Donovan Brown
with another episode of Azure Friday,
right here at Build 2018.
My best of friend Ed with me,
tell us what you do here at Microsoft Ed?
>> Thanks Donovan. I am a Special Program Manager
for Visual Studio Team Services
and my focus is on Git in version control.
>> All right. So, Git's critical and it's also very,
very popular right now.
Tell me one of the reasons that Git has just,
seems like it's taking over the world right now?
>> It does.
The last Stack Overflow survey I saw showed that
90 percent of software engineers
were using Git in some fashion.
So, it really has taken
over in a lot of ways. Isn't that incredible?
>> Yes it is, because I've been
around long enough before Git even existed.
>> Sure.
>> So, for a source control system
just to jump on the scenes and take over.
Tell me why has Git become so popular?
>> Yeah. So, I mean it really allows you
to enable some lightweight branching strategy
and that's really cool.
So, what I can do is
something like trunk-based development.
So I can keep my code in the master branch,
in the main integration branch as quickly as possible.
>> Okay.
>> So, I'll spin up a new branch,
we call it a topic branch,
fix a bug or add a new feature
and get it merged into master,
share with my co-workers as quickly as possible,
and get it into production as quickly as possible.
>> So, branching is cheap it sounds like?
>> Branching is super cheap.
>> But for every branch there has to be a merge.
>> There has to be a merge.
>> The cost is the merge normally,
not necessarily the branch.
So, talk to me this Git do anything
special when it comes to resolving merge conflicts.
>> It doesn't really do anything special but what it
does is since branching is so cheap,
it encourages you to do it and merge
that code quickly instead of leaving it around,
because it's really the long integration cycles
that are really costly and you
get into that. We call them merge error.
>> Right.
>> When you got just a bunch of
people trying to merge a bunch of
code and feature branches that have been long
running for a long time all at once.
>> Yeah, and I have also I've heard the term, merge bomb.
>> Yeah.
>> Right. Because you have basically this explosion
and it takes you forever to integrate that stuff.
>> It is the worst.
>> Right. There has to be
other techniques because just branching quickly,
emerging back in the master,
what if my code is not completely finished?
I mean, how do I protect my peers
from the fact that I'm trying to
stay close to the branch,
so that I don't have this merge bomb, yet,
some of that code that I'm writing isn't even finished.
>> Right. Well, I mean finish your code.
But, if you want to avoid bringing code that
isn't quite ready for consumers into production,
feature flags, of course, you have a great strategy.
So, what we do is we start merging quickly.
Obviously, it's got to compile. The test after pass.
>> Okay.
>> But it doesn't have to be feature complete,
it doesn't have to be ready to light up in production.
We just hide with feature flags.
>> Perfect. So, that also helps
some of the agile teams that
struggle to get something in
their product backlog that's going
to take two or three spreads.
Because historically, they would have
a branch that lived for two or three spreads,
and never got merged back in the master.
>> Right.
>> All the while, master is
changing for two to three spreads worth of work.
Then all of a sudden,
there's explosion happens at the end.
>> Merge bomb.
>> Got you. So, now having feature flags,
allow me to continuously merge, and report,
and reverse integrate both my branches,
such that when I'm finally done,
I'm just flipping a switch
not worrying about this merge collision.
>> That's exactly right.
>> Got it. Okay. So, what are the things about Git
besides the branching make it
more advantageous or attractive to me.
>> So, one of the big things
that sort of comes up
when you start talking about Git, is pull requests.
>> Okay.
>> So, the pull request workflow's incredibly powerful.
It's a great way to do code reviews,
you can see it all just on the website,
on diGital studios team services,
and you can comment in line,
you get this rich collaborative experience
that you didn't really have.
And it's not that we couldn't have done that with
a team foundation version control
or some centralized merge control system,
but it just happened that it came
about at the same time that Git became popular.
>> Great. So, even though branches are
cheap and we have to merge often,
it's not just this willy-nilly,
everyone merging into it.
We actually have a pull request that
can actually still protect our master branch,
and allow us to review the code and
check it before it actually gets merged into master.
>> That's exactly right. And spinoffs
and continuous integration builds?
>> Okay.
>> We can have branch policies,
so that I can open a pull request against your project,
and you can enforce that,
you have to code review it
before I complete that pull request.
>> Okay.
>> So, I can't just merge my code right in.
>> Got you.
>> So, you need to do the code review.
You need to set up a build policy and tests,
so that you can enforce my code builds and
all your tests pass before you accept my code.
You could go crazy,
you can do static code analysis at that point.
You can do all sorts of great-
>> Credit scans.
>> - credit scans, yes.
>> Got you. The reason I said that is
because the vSGS team uses vSGS,
>> Yes.
>> Which uses Git as our primary source control.
And we have a pull request scenario
that sounds very similar
to one that you're describing as well.
>>That's exactly right.
>> Right.
>> The vSGS team, uses vSGS to build vSGS.
>> We're choosing Git as
our primary version control system.
>> Yeah.
>> Not allows though I think it's 40 or 50 feature teams
that work together to bring us the vSGS, right?
>> Yeah.
>> They're all merging in the master every single day?
>> Yeah, all the time.
>> Right. That would almost be impossible with
a centralized version control system
like TFBC, yes or no or?
>> It was challenging.
Of course, we used to use TFBC.
We moved to Git and that did increase our agility.
We did have these nightmare merges.
>> Got you. Understood. Well, this is
really good information for people.
Now, the one thing that I've also heard
and will be the last thing I ask you about.
The learning curve can be expensive.
>> Yeah.
>> So, what are
some advice that we can give to people who are moving
from a centralized version control
to a Git version control,
to help them get over that learning curve?
>> Yeah, I think you're right.
I think that Git is a little bit different as far
as the way it works and that can be really difficult.
So, there's a couple of things. One, there's nothing
wrong with using a Gooey around Git.
>> Okay.
>> A lot of people think that,
are purists maybe, and think
that Git needs to run on the command line.
I don't think that's true. I think that there are
some good Gooey's out there.
There's one built in the Visual Studio for instance.
>> True.
>> Others one built in a Visual Studio Code.
I don't think there's anything wrong with that.
The other thing is that there's a lot of
good resources available
on visualstudio.com for instance,
to teach you how to get started using Git.
So, I think you should avail yourself of that knowledge.
But, yeah, just go with a Gooey.
>> Awesome. Thank you so much.
We're learning all about using Git here on Azure Friday.