Detailed Notes
This is an overview from one of our free, introductory classes (https://school.develpreneur.com/p/free_courses).
You can find out more through our online classes at https://school.develpreneur.com and register for free. Registration will add you to our email list and you will periodically receive coupons for courses as well as notifications of the latest releases.
Transcript Text
thank you [Music] we are going to talk about in this lesson something is very common it's called git git and it is for Version Control and the key to good version control though is that you have a version and branching strategy if all you're doing is using Version Control to effectively save backups of your your files of your source code that's not a bad thing it's good to have those it's good to be able to return to a point in time however once you have anything beyond one developer working on your code then things like and once you deploy your code it's very valuable to have a way to get to that version that you deployed because usually things will carry on and you'll do maintenance and things like that and then also how do I branch which is even more important because if you've got more than one developer how do you which is basically what branching solves how do you have multiple developers working in different areas of the application and not have them step on each other's toes while they're doing the coding that is where your branching strategy is going to come in now with your versioning and your branching the key is to be intentional this is something that again you know if it's just one developer in their own little repository it doesn't matter but once you get to three 10 developers more it is crucial that you have a strategy and that is documented so that people can know what that strategy is and actually you also need to have buy-in from your developers however that is it doesn't mean they have to be part of the design of it but when you push that forward when you document it and say this is our programming standard This Is How We Do Version Control there should be something that is a you know holding keep people accountable so that they do that so that they follow those processes now the goal with our versioning and our branching really is to easily merge and reproduce a path of changes so those are two things we want to be able to easily merge changes but we also want to be able to if we need to go back and reproduce how did we get to a certain point in time of of a release or a you know a maybe not a released version but maybe a tag or a label or something like that that is a a milestone of some sort and now we I mentioned just now we you have tags also that are available what you can do is you can use a tag to essentially be like a bookmark for a place in time or a milestone or key features it is not uncommon for tagging strategy to be part of branching inversioning so when you create a version instead of it being some you know uuid or not very human friendly name it has a tag that's something like you know version 1.0 beta what version 1.0 Beta release to something like that so that when somebody's looking at the tags they can fairly quickly map that back to whatever that release is or Milestone was that they wanted a good example would be spreads you may if you're using agile approach and you're essentially deploying or close enough to it deploying at each Sprint then maybe each tag is going to be you know Sprint one Sprint two Sprint three and it may be more you know have a little more information to it for that but you may not need it sometimes people are going to use dates things like that but some way to point back and say if I'm looking at all of the code changes and commits where do I go to reproduce this thing that we had at this time now branching typically is going to be based on some sort of a release and really and and people can change this up but it's by that I mean is by release a stable version of code so when you've got you know version 1.0 so you've got code that works that means that it's you're comfortable with it it's gone through its tests it's been you know blessed by QA or whoever it is so you know you have at that point something that quote works that is a great basis for a branch because then what happens is you've got these branches that are based on usually adding functionality so you have release 1.0 and let's say you have a branch that is adding security and you have another branch that is adding back-end integration those two things are separate enough but they need to have that stable Foundation to work with and now you're going to come back later once the work is done on those and merge those things back in typically what's going to happen is you will branch and then you will mer and if you think of it from a like a tree branch is that you've got your main I say trunk and you have a branch that comes off of that and then you have another branch that comes off of that and we'll call that Branch two and then you have another branch that comes off a branch two that's Branch three but when you merge what you want to do is you want to basically push the code from Branch three all the way out on that little thing into Branch two and then into Branch one and then back into the trunk so that you basically merge your way back into where the branches came from it's sort of like how do you find your way back home if you go out and you know you start going in a direction and you turn left and then you turn right and you turn left to right or whatever you every time you make a decision then in order to get back you have to come back to those decision points to walk your way back to your home may seem a little bit confusing but basically what you do is you branch and you say okay I'm on a stable section of code I'm branching off of that I'm going to do stuff based on that stable section and then I'm going to come back when I'm done and I'm going to merge back into that stable because it should be if I do it right my stable changes with that stable Foundation equals stable foundation with the new feature now that can be a challenge because if I'm working on something that's stable for me and another developer is working on something and it's stable for them but our things have some sort of conflict then when we merge there's going to be a conflict with the merge but that's okay in a sense I mean yes it's going to require work but what it does is it means that we know where the conflicts are we know that we both had this Foundation that worked and so we can actually track our changes and figure out where do we make our changes and then really if we need to can almost line by line walk through those to figure out how to merge those things back and then once you merge and you have those things now back into a solid working Foundation Branch or actually not even Brent like trunk or Maine you know Main Branch if you want to call it that or release branch then you can tag it and now I talk about release branches is sometimes what happens is you have something that would be production and then off of that you're going to Branch you say okay we're going to go do some development well at some point that development maybe that's going to have a branch and you're going to or a tag or something along those lines where it's like okay we're going to release this to QA but then we're going to specifically be changing those things in the QA Branch as opposed to our development branch and we'll eventually merge those and then we want to merge to production we'll have to merge our way back down to production so it's it's not the easiest thing to see sometimes but if you just think about it as the branches are going to get bigger and bigger and wider and wider and there'll be more branches but as you merge then you're coming you're essentially in a way traveling back down those branches to get yourself down to that single master or trunk now branching I've talked about a couple different ways to do it but I want to talk about the one way that I found that is very common is it is a branch per ticket or per bug so if there's a feature if there's a bug that needs to be fixed and you create a branch you know what the branch is the developer working on it does or changes and then they merge it back so you what you do and this is for your Pros is that when you do when you handle this approach the changes tend to be small there's not a lot of changes usually that are made which means that when you merge it back merging is going to be more likely to be successful and less of a headache now once you do that it's the con is it now every time you're get a bug or a ticket or task you've got to split off you've got to create your branch you've got to make sure the developers you know knows what branch they're on and then there's got to be a merge back and then eventually merge that back and you can end up having a lot of branches but you can merge and prune so you can go to a point where you say hey once we get to this point once we get to this bug being fixed when we're going to merge it back we know we're not going to need that Branch anymore so we're going to merge back and then that Branch just appears and so in this case you maybe have a lot of branches but they end up disappearing because you're cleaning them up as you go and now it's the same thing you may want to do that and have branches so that you can go into you know version 2.0 or 3.0 so that you would go you know release version 2.0 but if there were bugs to be fixed that were in 1.0 you could always work off of that branch and then have a you know 1.1 release even after 2.0 was even released maybe even way after it was released but if you do this per ticket bug it tends to keep it pretty essentially pretty close to the branch that you're working on you know saying assuming it's like a you know a version Branch or development versus maybe staging or production the nice thing about this is it's it's very it's gonna be very focused and so it's easy to just you know pop out do a branch make your fix test it specifically a lot of times because and then the merge you can test very specifically because you're not having to you didn't touch a lot of stuff the tests that you used on the on the merging or you know as you branched and fixed it those tests should be effectively be able to be added to your overall testing strategy verify it and move on so there's some there's quite a few Pros to taking this approach the cons are really usually more about people just not being as comfortable creating branches and merging and things like that and it's it's really more of a technical skill type of issue than it is the actual you know the utility of taking this approach do this this goes back to you know documentation and buying and you need to ensure that the team agrees and adheres to your approach because if they don't if you've got developers that start doing their own thing it can get out of hand and really tough to maintain quickly I recommend that you make your your committing and branching and versioning tagging all of that stuff is part of your code review and in retrospective if you're using a uh if you're in and you know using scrum or agile or something like that because those are going to be the kinds of things that you want to catch just like you would want to catch a misspelling of retro septicus or whatever that happens to be but if you make sure that you have everybody you know check that out that means as in check that as in review where is the branch what happened to the branch how did it get merged where is it merged did we tag it things like that those should be part of your code review then that's going to ensure that the team feels like they are accountable to using the process properly so the bottom line is it may seem like you're branching and tagging and merging strategy is just part of the tool but if you really want to get the power of get or any especially distributed Version Control System like git or Mercury or some of those other things out there then utilizing these features are where you're going to find that these tools really work for you and really can save your butt in a pinch if some you know some issue comes up some bug comes up or also just to avoid bugs reappearing and code getting lost because people just don't follow the processes all that being said it is more than worth it to invest a little time make sure that you have a good strategy and that you communicate it and everybody buys in hope this helps you out thank you a lot for your time hello this is Rob with developmentor also known as building better developers wanted to announce that we have school.developmentor.com feel free to check it out if you like any of this information any of the content that we've sent and you would like to see more you can come out you can enroll for free we have free courses we've got places for you to get better at just learning a technology our how to's you can work on your business skills we can help you with becoming a better developer as encoding and things like that a lot of the stuff you've seen on YouTube we also have out at school.develop anywhere we just have it a little more of a educational format and a way for you to track your progress as you move forward becoming a better developer thank you
Transcript Segments
thank you
[Music]
we are going to talk about in this
lesson something is very common it's
called git git and it is for Version
Control and
the key to good version control though
is that you have a version and branching
strategy if all you're doing is using
Version Control to effectively save
backups of your your files of your
source code that's not a bad thing it's
good to have those it's good to be able
to return to a point in time however
once you have anything beyond one
developer working on your code
then things like and once you deploy
your code it's very valuable to have a
way to get to that version that you
deployed
because usually things will carry on and
you'll do maintenance and things like
that and then also how do I branch which
is even more important because if you've
got more than one developer how do you
which is basically what branching solves
how do you have multiple developers
working in different areas of the
application and not have them step on
each other's toes while they're doing
the coding
that is where your branching strategy is
going to come in
now with your versioning and your
branching the key is to be intentional
this is something that again you know if
it's just one developer in their own
little repository it doesn't matter but
once you get to three 10 developers more
it is crucial that you have a strategy
and that is documented so that people
can know what that strategy is and
actually you also need to have buy-in
from your developers however that is it
doesn't mean they have to be part of the
design of it but when you push that
forward when you document it and say
this is our programming standard This Is
How We Do Version Control there should
be something that is a you know holding
keep people accountable so that they do
that so that they follow those processes
now the goal with our versioning and our
branching really is to easily merge and
reproduce a path of changes so those are
two things we want to be able to easily
merge changes
but we also want to be able to if we
need to go back and reproduce how did we
get to a certain point in time of of a
release or a you know a maybe not a
released version but maybe a tag or a
label or something like that that is a a
milestone of some sort
and now we I mentioned just now we you
have tags also that are available what
you can do is you can use a tag to
essentially be like a bookmark for a
place in time or a milestone or key
features it is not uncommon for tagging
strategy to be part of branching
inversioning so when you create a
version
instead of it being some
you know uuid or not very human friendly
name it has a tag that's something like
you know version 1.0 beta what version
1.0 Beta release to something like that
so that when somebody's looking at the
tags they can fairly quickly map that
back to whatever that release is or
Milestone was that they wanted
a good example would be spreads
you may if you're using agile approach
and you're essentially deploying or
close enough to it deploying at each
Sprint then maybe each tag is going to
be you know Sprint one Sprint two Sprint
three and it may be more you know have a
little more information to it for that
but you may not need it sometimes people
are going to use dates things like that
but some way to point back and say if
I'm looking at all of the code changes
and commits where do I go to reproduce
this thing that we had at this time
now
branching typically
is going to be based on some sort of a
release
and really and and people can change
this up but it's by that I mean is by
release a stable version of code
so when you've got you know version 1.0
so you've got code that works that means
that it's you're comfortable with it
it's gone through its tests it's been
you know blessed by QA or whoever it is
so you know you have at that point
something that quote works
that is a great basis for a branch
because then what happens is you've got
these branches that are based on usually
adding functionality so you have release
1.0 and let's say you have a branch that
is adding security and you have another
branch that is adding back-end
integration
those two things are separate enough
but they need to have that stable
Foundation to work with
and now you're going to come back later
once the work is done on those and merge
those things back in
typically what's going to happen is you
will branch and then you will mer and if
you think of it from a like a tree
branch
is that you've got your main I say trunk
and you have a branch that comes off of
that
and then you have another branch that
comes off of that and we'll call that
Branch two and then you have another
branch that comes off a branch two
that's Branch three but when you merge
what you want to do is you want to
basically push the code from Branch
three all the way out on that little
thing into Branch two and then into
Branch one and then back into the trunk
so that you basically merge your way
back into where the branches came from
it's sort of like how do you find your
way back home if you go out and you know
you start going in a direction and you
turn left and then you turn right and
you turn left to right or whatever you
every time you make a decision
then in order to get back you have to
come back to those decision points to
walk your way back to your home
may seem a little bit confusing but
basically what you do is you branch
and you say okay I'm on a stable
section of code I'm branching off of
that I'm going to do stuff based on that
stable section and then I'm going to
come back when I'm done and I'm going to
merge back into that stable because it
should be if I do it right my stable
changes with that stable Foundation
equals stable foundation with the new
feature now
that can be a challenge because if I'm
working on something that's stable for
me and another developer is working on
something and it's stable for them but
our things have some sort of conflict
then when we merge there's going to be a
conflict with the merge but that's okay
in a sense I mean yes it's going to
require work but what it does is it
means that we know where the conflicts
are we know that we both had this
Foundation that worked and so we can
actually track our changes and figure
out where do we make our changes
and then really if we need to can almost
line by line walk through those to
figure out how to merge those things
back and then once you merge and you
have those things now back into a solid
working Foundation Branch or actually
not even Brent like trunk or Maine
you know Main Branch if you want to call
it that or release branch
then you can tag it
and now I talk about release branches is
sometimes what happens is you have
something that would be production
and then off of that you're going to
Branch you say okay we're going to go do
some development well
at some point that development
maybe that's going to have a branch and
you're going to or a tag or something
along those lines where it's like okay
we're going to release this to QA but
then we're going to specifically be
changing those things in the QA Branch
as opposed to our development branch and
we'll eventually merge those and then we
want to merge to production we'll have
to merge our way back down to production
so it's
it's not the easiest thing to see
sometimes but if you just think about it
as the branches are going to get bigger
and bigger and wider and wider and
there'll be more branches but as you
merge then you're coming you're
essentially in a way traveling back down
those branches to get yourself down to
that single master or trunk
now branching I've talked about a couple
different ways to do it but I want to
talk about the one way that I found that
is very common is it is a branch per
ticket or per bug so if there's a
feature if there's a bug that needs to
be fixed and you create a branch
you know what the branch is the
developer working on it does or changes
and then they merge it back so you what
you do and this is for your Pros is that
when you do when you handle this
approach the changes tend to be small
there's not a lot of changes usually
that are made which means that when you
merge it back merging is going to be
more likely to be successful and less of
a headache
now once you do that it's the con is it
now every time you're get a bug or a
ticket or task you've got to split off
you've got to create your branch you've
got to make sure the developers you know
knows what branch they're on and then
there's got to be a merge back and then
eventually merge that back and you can
end up having a lot of branches but you
can merge and prune so you can go to a
point where you say hey once we get to
this point once we get to this bug being
fixed when we're going to merge it back
we know we're not going to need that
Branch anymore so we're going to merge
back and then that Branch just appears
and so in this case you maybe have a lot
of branches but they end up disappearing
because you're cleaning them up as you
go
and now it's the same thing
you may want to do that and have
branches so that you can go into you
know version 2.0 or 3.0 so that you
would go you know release version 2.0
but if there were bugs to be fixed that
were in 1.0 you could always work off of
that branch and then have a you know 1.1
release even after 2.0 was even released
maybe even way after it was released
but if you do this per ticket bug it
tends to keep it pretty
essentially pretty close to the branch
that you're working on you know saying
assuming it's like a you know a version
Branch or development versus maybe
staging or production the nice thing
about this is it's it's very it's gonna
be very focused and so it's easy to just
you know pop out do a branch make your
fix
test it specifically a lot of times
because and then the merge you can test
very specifically because you're not
having to you didn't touch a lot of
stuff
the tests that you used on the on the
merging or you know as you branched and
fixed it
those tests should be effectively be
able to be added to your overall testing
strategy verify it and move on
so there's some there's quite a few Pros
to taking this approach the cons are
really usually more about people just
not being as comfortable creating
branches and merging and things like
that and it's it's really more of a
technical skill type of issue than it is
the actual you know the utility of
taking this approach
do this this goes back to you know
documentation and buying and you need to
ensure that the team agrees and adheres
to your approach
because if they don't if you've got
developers that start doing their own
thing it can get out of hand and really
tough to maintain quickly
I recommend that you make your your
committing and branching and versioning
tagging all of that stuff is part of
your code review and in retrospective if
you're using a uh if you're in and you
know using scrum or agile or something
like that
because those are going to be the kinds
of things that you want to catch just
like you would want to catch a
misspelling of retro septicus or
whatever that happens to be but if you
make sure that you have everybody you
know check that out that means as in
check that as in review
where is the branch what happened to the
branch how did it get merged where is it
merged did we tag it things like that
those should be part of your code review
then that's going to ensure that the
team feels like they are accountable to
using the process properly
so the bottom line is
it may seem like you're branching and
tagging and merging strategy is just
part of the tool
but if you really want to get the power
of get or any especially distributed
Version Control System like git or
Mercury or some of those other things
out there then utilizing these features
are where you're going to find that
these tools really work for you
and really can save your butt in a pinch
if some you know some issue comes up
some bug comes up or also just to avoid
bugs reappearing and code getting lost
because people just don't follow the
processes
all that being said it is more than
worth it to invest a little time make
sure that you have a good strategy and
that you communicate it and everybody
buys in
hope this helps you out thank you a lot
for your time hello this is Rob with
developmentor also known as building
better developers wanted to announce
that we have
school.developmentor.com feel free to
check it out if you like any of this
information any of the content that
we've sent and you would like to see
more you can come out you can enroll for
free we have free courses we've got
places for you to get better at just
learning a technology our how to's you
can work on your business skills we can
help you with becoming a better
developer as encoding and things like
that a lot of the stuff you've seen on
YouTube we also have out at
school.develop anywhere we just have it
a little more of a educational format
and a way for you to track your progress
as you move forward becoming a better
developer
thank you