00:00:00.640
hello ruby galaxy i'm really excited to be able to talk to you about git rebase
00:00:05.920
especially the git rebase workflow and how you can use that in order to make high quality git commits but also
00:00:12.960
um construct a well reasoned implementation a ruby implementation
00:00:18.560
in which to share with your team for code review or just basically have that history for your
00:00:24.000
past self to to empower your future self so there are several benefits to the git
00:00:31.760
rebase workflow uh the first is that it's linear the commits happen one after another
00:00:36.960
which makes them very readable so you can understand how the implementation was put together and
00:00:42.079
it kind of tells a compelling story of how you got to where you are and then on top of that it makes it very
00:00:48.320
debuggable uh because you can break out the big tools like get
00:00:53.440
bisect and other tooling to understand if something went wrong where that where that happened and how
00:01:00.000
to address it really quickly before we kind of jump into this though
00:01:05.280
and we dive a little bit further i i need to do a bit of a review here on
00:01:10.640
the history between merge and rebase so if you look at
00:01:15.840
the difference here where we have merge on the left and rebase on the right and if each one of the circles is a
00:01:22.479
commit and each color is an author we can kind of walk through this together where we have a commit
00:01:28.799
happening uh here in time on on the merge and the rebates we have another commit from a a well i should say a
00:01:35.600
series of commits from another author and then two more commits from another offer author
00:01:41.119
and what's nice about this is you can see very clearly on the right that the rebase workflow is a little easier to
00:01:47.439
understand than the merge workflow both are doing the same thing
00:01:52.720
it's just that it's a lot easier to understand what's happening in a nice rebase linear kind of flowing
00:01:59.439
structure versus a merge structure that has everything preserved in time as it occurred
00:02:06.640
so what is merge well merge is exactly joining two histories together
00:02:11.840
and they're just preserving it in time indefinitely um so if you have if you take a look at this and you have
00:02:18.000
the master branch on the left hand side and you have three different authors committing code and then you have this
00:02:24.160
feature branch on the right hand side where mariana is trying to make three commits off of aussies commit
00:02:29.680
and then eventually merge it back into master after vivian that's preserved in time date times
00:02:35.920
everything is preserved as it is which is useful um but it starts to get
00:02:42.239
out of hand if you have a whole lot of merging going on across your team not just with one author in this case but multiple authors
00:02:49.360
so let's take a look at what i mean by that if we kind of look through a couple
00:02:54.959
examples here showing emerge history and how that can kind of get out of hand so if we
00:03:00.319
if we look at a semi-linear merge history right where it's fairly linear we have like little
00:03:05.680
merge bubbles uh popping out here and there but for the most part it's it's fairly
00:03:10.720
readable not not too bad but let me show you another example where
00:03:16.720
here's here's a here's a team that i once worked on that had a heavy heavy merge workflow
00:03:23.120
and as we go through time here you can see that this is getting out of hand really quickly like at this point i
00:03:29.519
can't even tell you who's doing what in the history we could potentially plot this out
00:03:34.879
print it out put it on the floor map it out and figure out who did what when but that's a whole lot of work
00:03:41.440
that we really shouldn't have to do if we were to switch to a rebase workflow versus a merge workflow
00:03:47.760
another way to look at this is basically merge like the definition says is joining two
00:03:53.680
uh histories together right well it's a big big mess and a total
00:03:59.519
nightmare to unravel debug and figure out who did what when so i want to kind of emphasize moving
00:04:05.599
away from the merge workflow and focusing on our rebase workflow uh by the way before we continue i just
00:04:11.680
want to point out those graphs that i was showing you there with the git log and the shaws and printing out those merge bubbles
00:04:18.079
that was done by using this command so here i use git log and then i pass graph the dash dash
00:04:24.479
graph option to graph out those merge bubbles and then i pretty print it so using a format of yellow for the shaw
00:04:31.840
and then and then resetting that color and then starting a green color for the committed date and then resetting that color
00:04:38.000
is how i was printing those out these slides by the way will be available online so don't worry if you're trying to capture all this um
00:04:44.479
it'll totally be available for you later but that's how that command that's how i was able to generate those
00:04:49.759
um uh get log histories for you
00:04:54.800
so now that we've talked about merge let's talk about rebase which is basically replaying commits on top of
00:05:01.919
the the master branch or whatever branch that you created your feature branch off of
00:05:07.280
in this case we still have the same authors right we still have mariana who's doing her work but she's put her
00:05:14.240
feature brands or sorry her commits ahead of everyone else and when she finally merged that into
00:05:19.840
master they just show up as the last three commits again different
00:05:24.880
authors same amount of commits but a much easier to read uh history
00:05:30.720
another way to look at this is uh and i'm i'm borrowing these uh gifts from atlassian but another way to
00:05:37.199
look at this is if the master branch is in blue you have the commits happening there and then you have a feature branch that branches off
00:05:43.280
of that and then eventually gets replayed on top of master that's essentially what's happening here
00:05:48.560
when you're doing a rebase if it helps to look at it in a different way you can just basically pretend
00:05:55.680
that the feature branch that you're working on when you finally merge it into master you're just sliding those uh commits in front of
00:06:03.039
master when you finally commit those changes so if that helps that's another way to visualize that
00:06:10.319
so let's look at a git rebase example uh over the course of many years in this case here's a repository
00:06:17.680
in which many commits been made over the series of months series of years and as we speed this up
00:06:23.199
and we go and we fly through the years here you'll see that this history using a rebase history stays linear the entire
00:06:29.280
time you know in that other slide where i was showing you the merge conflict we couldn't even get this far
00:06:34.960
that far back in time because uh the the merge bubble would be completely off the screen so here's a
00:06:41.600
good contrast to show you the difference between the two and how powerful rebase history really is for
00:06:46.960
readability debuggability and um understandability in general for
00:06:52.160
that matter so what does a merge workflow kind of look like right like let's kind of walk
00:06:58.240
through this together talk this through and then kind of contrast that with a rebase workflow
00:07:03.840
so for starters you know when you start your work at the beginning of the day you might do a git poll which is really
00:07:09.280
two commands in one by the way if you didn't know this it's get fetch and get merged that's what getpoll is doing
00:07:14.639
then you'll start your workflow right you'll do a git switch here you'll you'll create an example branch
00:07:20.319
and then you'll do tracking tracking by the way sets up uh metadata in your uh get local config for
00:07:26.240
your for your um repository that you're working in and just ensures that the example branch
00:07:31.360
that you're creating here gets tracked so that when you push to that remote branch in the future you don't have to keep typing example
00:07:37.520
each time by creating your branch and turning on tracking git will remember that and then
00:07:43.440
you don't have to type that anymore so i highly recommend turning this on if or or using this option i should say um
00:07:49.520
when you're creating new branches then you know in a typical get work workflow you'll go ahead and make some
00:07:55.599
commits you'll make a series of commits you'll keep doing that until you're satisfied with the work and you're ready to put that up to uh up for code review
00:08:03.360
basically then you'll go ahead and maybe you'll switch back to master right you'll switch back to master
00:08:09.199
you'll pull down the latest changes because you want to make sure maybe you've been working on your feature branch for an hour and you want to pull in the changes from the rest of the team
00:08:15.280
make sure you don't have any merge conflicts then you'll switch back over to your example branch you'll pull from master
00:08:21.440
to make sure that your example branch is also up to date with changes from your team and then you'll push those changes up
00:08:27.039
and get them up for code review right now during the course of this if there's been any changes from the team you would
00:08:32.240
have merge bubbles at this point in time because every time you pulled you pulled in those changes
00:08:38.320
and that created a merge bubble so let's uh now that we've looked at merge
00:08:43.839
let's actually talk about the rebrakes workflow so if we contrast what we were just
00:08:49.120
doing in the merge workflow but highlight the differences this is what changes when you do a rebase workflow so instead of doing a
00:08:55.360
good pull what we'll do is we'll do a fetch and a poll i point out the fetch because
00:09:00.480
what we can do with the fetch is we can prune it at the same time which will delete all feature branches that you have locally
00:09:06.720
that got deleted on the remote highly highly recommend doing this and i'll show you how to configure this even
00:09:11.760
further so you don't have to type this out each time then the second thing we'll do is we'll do a poll but this time we'll teach it
00:09:17.600
to rebase that's it that is how you switch from a merge workflow to a rebase workflow is all through this one simple
00:09:24.240
uh option next we'll do some work right we'll go ahead and create our feature branch make
00:09:30.000
some commits and then we'll get ready to actually push that work up like we're doing before what we'll do in this case though is
00:09:36.480
we'll switch pull to a rebase and also the pull when we switch over to our example branch will do
00:09:42.240
a rebase there as well so we'll do a rebase origin master pull in those changes but we'll we'll
00:09:48.000
basically replay our commits on top of the um on top of whatever changes came down
00:09:54.959
from master when we did the poll and then the last thing we'll do is we'll go ahead and push these changes up
00:10:01.120
but because rebase is changes the shaw's that means that we have to do a force push
00:10:06.480
um which i highly highly recommend never never doing because it can be very dangerous right you can accidentally
00:10:11.600
override work on your feature branch or maybe if you're collaborating with somebody else you might overwrite their work
00:10:18.240
what these two options here do is force with lease will ensure that uh if
00:10:25.200
changes are happening on the remote that you aren't aware of the in some case this situation can happen when you're
00:10:30.720
pairing with somebody and you didn't communicate properly and they pushed up changes to your future branch
00:10:36.000
the same branch that you're working on and you do a force push if you turn on force with lease at least
00:10:41.279
would detect that and halt that process so you could be like oh wait maybe i should go talk to my
00:10:46.480
colleague the force if includes is a new feature and we'll talk about this a little bit
00:10:52.320
more in a few slides uh in the latest version of of git
00:10:57.519
which basically just does a double check to put it very simply uh that the shaw at the tip of the
00:11:04.320
remote branch is actually in in your history currently and if not um it'll halt that i won't spend a lot
00:11:11.920
of time on this uh but i do want to emphasize turn these on or using these when you do a push with a rebase workflow it'll save
00:11:18.959
you a lot of pain and hurt in case you're collaborating with others or forgot to communicate properly
00:11:27.040
so moving on from there let's talk about a few get configuration quick tips
00:11:33.760
the first is like i was saying when we were typing this out together there's a few things you could turn on so you don't have to type so much
00:11:39.200
one of the first things to do is edit your global git configuration and set rebase to true what this does is
00:11:45.680
this prevents you so you don't have to type git pull dash respace every time you can just do a get poll like you normally do
00:11:51.600
but now it'll rebase properly which is awesome so that's how you turn that on for every
00:11:57.120
every time you pull you'll always be rebasing by the way the command line for this is down below in case you want to turn this
00:12:03.600
on through your global git configuration the other thing you could do is you can
00:12:09.200
also update your rebases to be merges the reason i point this out
00:12:14.639
is you'll need git 22.22 or higher but this helps you if you're in a hybrid
00:12:21.040
situation where you're half your team's rebasing half your team is merging and you want to do a rebase workflow because
00:12:27.519
you understand the value of that but not all your team is there yet this would allow you to rebase but also
00:12:33.440
handle those merge bubbles when they get kind of complicated hopefully you're not in a situation like
00:12:38.800
that but it doesn't hurt to have this turned on and i highly recommend doing that you can also read up on the get
00:12:44.000
documentation on how this is used as well and and i recommend spending some time there looking at it
00:12:51.440
the other thing you could do is the fetch prune right when we were doing the fetch earlier i was showing you how to do dash dash
00:12:57.120
pruned uh to prune those feature branches that you don't need locally because they've been merged into the remote branch
00:13:02.639
or the remote repository right well if you set this to true you don't have to type get fetch dash
00:13:09.200
prune each time you can just type get fetch and it'll do the printing for you because you've configured it globally
00:13:14.720
so highly recommend turning this on as well and again this is the command line that you would run in order to
00:13:21.760
set that flag to true within your global gate configuration
00:13:27.279
lastly is a git configuration the push configuration for global configuration
00:13:32.720
so uh use force includes is what i was telling you about earlier if you don't want to type that out each
00:13:38.639
time so this requires by the way sorry this requires get 2.30
00:13:44.079
and higher to actually enable but when you enable that you don't have to type this long command line out
00:13:50.320
anymore it's still kind of long but you don't have to type out the force if includes anymore because you've turned it on
00:13:56.240
so i highly recommend turning this on too it's just a nice way for git to do that detection for you and save you some time if it determines
00:14:03.760
that things are not properly synchronized up or changes have happened on the remote
00:14:09.279
branch and you're about to force push you won't override any work
00:14:14.399
and by the way this is the command line to turn that on globally if you need it
00:14:19.680
so we've talked about uh the difference between merge and rebase at this point and we've also talked about some good
00:14:25.440
configurations that you can put applied to your global configuration to help your rebase workflow
00:14:31.519
now what i want to do is actually go through interactive rebase itself and actually talk through the various commands
00:14:38.240
so the basic way to do this is just get rebase interactive master and you're off to the races that's the
00:14:44.720
beginning of rebasing your feature branch on on master in this case assuming that you created your
00:14:50.240
feature branch off a master to begin with by the way if you don't want to type in
00:14:55.839
interactive all the time you can always do dash i and that's that's the same thing just shorter
00:15:03.839
when you do that what's going to happen is with that interactive rebase you're going to see this in your editor for the first time
00:15:09.839
you're going to see interactive rebase pop up and it's going to say hey look i have three commits here i don't know what you
00:15:16.800
want me to do with those but but here's all the i'm going to show you that i'm rebasing this shaw onto
00:15:22.160
this other shaw and by the way here's all the commands you can give me in which i can do something with
00:15:28.079
we're going to walk through all those except for those last three the label reset and merge are more
00:15:34.320
specific to kind of a rebase merge hybrid and i'm not going to spend time on that today because i want
00:15:39.519
to stay highly focused on the rebase workflow but before we get into those commands i
00:15:45.360
want to pause for a moment and just talk about the various ways in which you can interactive rebase the first is you can integrate active
00:15:52.160
rebase back by a series of numbers or a series of commits i should say sorry
00:15:57.519
so in this case with the at tilde number you can go back like three commits you could go back five commits
00:16:04.160
ten commits you name it however many commits on your feature branch you want to go back you put in that number and it will
00:16:09.519
rebase to that point the one thing that you want to do though is make sure that the number is never
00:16:16.240
higher than the number of commits on your future branch what i mean by that is if you go back uh
00:16:21.519
if you have five commits on your feature branch and you go back to six commits that means the sixth commit is actually
00:16:26.560
a commit that was on master um and you'd be changing the shot at that point which means that you can't
00:16:31.920
merge your feature work into uh the master branch once uh it's been code approve or
00:16:37.440
sorry through the code review it's been approved by you by the team so just make just be aware of that when
00:16:44.800
you're rebasing just don't go back uh past uh the commit in which you actually created the branch off of
00:16:51.040
if that helps by the way you can use the at symbol um but you can also type out head if you want to i'm showing you the
00:16:57.199
shorthand but you can also type out head if you want to uh they're just synonymous and that's another way in which to go back a
00:17:02.959
certain number of commits the other thing you can do when you're interactive rebasing is go
00:17:08.640
interactive rebase by a particular branch name this is super handy when you're in a
00:17:14.079
situation where you're rebasing you've pushed up a feature branch for code review
00:17:19.120
but now you need to continue on additional feature work which is based off the stuff that you already have in code review
00:17:24.720
so you might branch off of that feature branch so you'd have a master branch a feature branch and then another feature branch
00:17:30.880
that branches off that feature branch in that case what you want to do is you don't want to rebase all the way
00:17:36.640
back to master you want to rebase off of your current feature branch off the feature branch you just created and this
00:17:42.720
is a way to do that which is super super handy the other thing you can do is like let's
00:17:48.320
say that you've released a tag and you want to actually create a feature branch off that tag and then rebase off that tag until you can get
00:17:55.280
that hotfix or patch release out this is a nice way to do that
00:18:00.640
you can also rebase by a particular shaw so in the very first slide i was showing you where you could rebase by a
00:18:06.640
particular number and go back in time well if you don't want to do the counting in your head
00:18:12.160
you could just uh select the shaw that you want to rebase back to and the interactive rebase will go to
00:18:17.520
that sha let you rebase from that point and then complete the rebase workflow so that's a really handy technique to
00:18:23.919
have you can also rebase by upstream so this special syntax here allows you to rebase by
00:18:30.400
changes that are happen upstream i personally don't use this much myself in fact i can't think of a time that i
00:18:36.559
have had to use this but it is there for you if you ever needed to do something like that and so i just
00:18:42.400
want to point that out to you the last one here is being able to rebase by root
00:18:48.000
and this is one of my favorites it is super powerful and really awesome but it does come with a
00:18:54.640
big big caveat when you rebase by root you're basically going back to the very first commit of
00:19:00.000
the entire repository and you might be thinking hey why am i even telling you this that sounds
00:19:05.120
extremely dangerous well it is on an existing code base that you've shared with your team
00:19:10.160
or you're collaborating on with others that would be disastrous you don't want to rebase to root
00:19:15.280
but in the scenario where you're creating a repository the first time maybe you're going to open source it and share it with the world
00:19:21.280
maybe you've got an internal project that you're doing some work to get into the right state before you release it for others to
00:19:26.960
collaborate within your company this is a wonderful wonderful way in which to rebase
00:19:32.240
clean up your code clean up your commits tell a compelling story and show everyone how you built up your
00:19:38.240
implementation before you share it with them i do this all the time when i'm releasing new projects or open source
00:19:44.480
work highly highly recommend but only when the repository has not been shared
00:19:50.480
with anybody would you want to use this there's also an advanced technique when
00:19:56.240
you're rebasing to basically disable the editor from popping up every time and the way to do that is basically put
00:20:02.880
git editor true in front of your rebase command and that'll i know it sounds kind of counter productive or
00:20:09.120
counterintuitive right because you're saying true you maybe want to say something like false but if you set
00:20:15.360
it to true that'll disable the editor from popping up and this comes in really handy when you're doing a lot of fix up
00:20:21.200
commits because when you're rebasing and you have fix up commits you can just let get figure out where
00:20:26.880
those fix-ups should go and don't prompt you because there's nothing for you to do as an author
00:20:32.400
so this is a really really handy technique and great to have in your arsenal when you're rebasing heavily and
00:20:37.440
really quickly so let's talk about the get rebase
00:20:42.559
editor um let's jump into these commands and kind of walk you through each one of those
00:20:47.919
and i want to focus on all of these right here today and kind of give a brief overview and show you how to use them if you've
00:20:53.679
never seen them before i also want to point out that you can write these out every time or you can
00:20:59.280
use the shorthand and just not type out pick every time you can just use p or r or e depending on whatever command you
00:21:06.240
want to feed the rebase editor so let's start with pick and actually
00:21:11.919
explain how that works it's a it it kind of it's the default thing that you'll see when you're first rebasing
00:21:17.120
it seems kind of boring but it actually has kind of a superpower uh and what i want to point out is when
00:21:23.679
you look at let's let's say that we have three commits on our feature branch and uh we want to reorder those uh
00:21:30.159
normally with pick it's kind of a no-op in the rebase editor if you just pop up those commits in your rebase
00:21:36.720
editor and you don't do anything with them you just leave them as picks that it's kind of a no op there's really no rebase happening
00:21:42.960
but the nice thing is you could actually reorder these if you want to tell a more compelling story so in this case we have an initial
00:21:48.799
implementation we added documentation and we fixed the json schema well if we want to make a a good
00:21:55.440
compelling story here kind of read like a you know turning a page in a book uh we could reorder these uh two commits here
00:22:02.559
the last and the first um just like this and now the fix happens before we added the
00:22:07.760
implementation and added the documentation so now we're telling kind of a a different story here on how the
00:22:13.760
evolution of this implementation came to be the next thing we could do is we can
00:22:19.919
also reword commits so when we reword a commit what we do is we
00:22:25.120
change pick in this case we'll pick this middle commit uh we'll change it to reword and then
00:22:30.159
what's going to happen is this going to pop up in our editor and allow us to not only reword the subject but also the
00:22:35.840
body and this is a nice way to fix like a typo
00:22:41.200
explain ourselves better in the commit message all those things before we commit the code to our master branch or
00:22:48.640
go through code review whatever this is a nice way to clean all that up so in this case we can fix the subject
00:22:56.960
we can rewrite it this way so it's a little bit more descriptive in this case we're saying exactly that we added the table of contents to the
00:23:03.120
readme which is way more descriptive than what it was and then we can also fix our subject or
00:23:08.400
our body if we wanted to too what's really nice about this is when you have a subject and a body
00:23:14.159
the subject is the what it explains what it is that you're committing and then the why explains uh why you did
00:23:20.559
what you did right it supports the subject to explain
00:23:26.400
what your thought process was at this point in time in committing this code very very very powerful
00:23:32.960
so if we use a git log here we do a pretty format of what we just reworded here's what those commit looks
00:23:38.320
like commit messages look like and you can see the middle commit is where we reworded that
00:23:43.600
commit and it has the new subject which is exactly what we want
00:23:50.000
so if we move on here and we get into a little bit more of the advanced tools
00:23:55.520
edit is one of those and i won't be able to show all of this to you today but if you
00:24:01.440
haven't noticed so far and i i apologize for not pointing this out earlier is in the footer of these slides i have
00:24:07.440
links to screencast tutorials in which you can actually dive into each one of these commands a little bit
00:24:12.799
deeper and understand them even fuller because i just don't have enough time in this slide today to actually explain
00:24:18.960
everything but i just want you to know that you can look at those screencast tutorials for additional work and this would be
00:24:24.559
one of them that you'd want to dive into a little further so i'll explain kind of at a high level
00:24:29.600
what edit is doing in this case we can change like one of these picks to an edit
00:24:34.960
and all we would do is just reword pick to edit and we're off to the races what will happen in this case though is
00:24:41.120
during the rebase git will halt at that edit shaw that you wanted to edit
00:24:47.200
and you can do a multitude of things you can fix up your implementation you can rerun your specs if you wanted
00:24:52.880
to you could edit your subject your body of the commit message you name it when you're finally happy
00:24:59.679
with those changes and you commit those then you can do a get rebase continue and continue on with the rebase and
00:25:05.440
and um you're done at that point so edit's a nice way to go back in time
00:25:11.440
in one of the commits on your future branch and just basically correct them both in terms of
00:25:16.480
commit message and implementation really really powerful tool
00:25:21.520
the other thing you could do is you can squash a commit and what squash does is in these three
00:25:26.720
commits that we've been looking at so far we could take two of those and we could actually squash those into the previous commit so
00:25:33.120
in this case we would change those two commits to squashes and then they would just squash themselves into the previous commit
00:25:39.360
now what squash does though in that case is it takes all three of those commits the subjects and the bodies from all three and
00:25:45.600
smashes them together and it wants to make one big commit message by default
00:25:50.720
you don't want to do this because as you're reading this here this is kind of a mess to read through it's it's a lot to decipher there's a
00:25:57.520
three different ideas going on because we're squashing three commits into one so what we can do is get rebase will
00:26:03.679
halt in the editor with those three commit messages all squashed together and now we can fix them up
00:26:09.600
and the way to do that is we can go ahead and kind of look at our subjects we can look at our bodies and be like
00:26:15.360
hey you know what we can actually write this a little bit better first of all we can throw out that we fix the json schema
00:26:22.000
because we're squashing them all three commits down into one commit so the fact that we had a screw-up we
00:26:28.159
could just make that magically disappear as if we hatched it perfectly the first time uh which is a nice little uh a trick
00:26:35.919
the next thing we can do is we can get rid of this middle subject um it's not really helping us in this case
00:26:41.600
we can kind of just sort of reword that a little bit so what we can do is um collapse that
00:26:47.840
down have our two subjects now and then this last body now we're starting to get kind of to the meat of things here this is
00:26:53.679
starting to tell a more compelling story so we like the subject but these two uh met these two
00:27:00.960
paragraphs here are not really working for us so let's just tear out this first line and reword this
00:27:07.039
so that it actually reads better as a paragraph and that tells a more compelling story now we have a clear subject
00:27:13.360
and we have a clear body and a nice commit message that summarizes those three commits that we just squashed down
00:27:18.880
into one commit this is a really nice way to use squash
00:27:24.000
the other thing we do is we can do a fix up now fix up is like squash but it's a little lighter weight
00:27:29.360
it's actually one of my favorite commands i use it all the time and to show you it works the same way as
00:27:36.559
squash so in this case we'll take pick well sorry we'll we'll pick a couple of these commits right
00:27:42.159
we'll make a fix up and we're going to fix up this commit into one of the other commits right so we'll move that fix up
00:27:48.799
here to the first commit and that's going to take that middle fix up commit and just fix
00:27:54.559
it into the previous command what's going to happen though is the subject and the body of the fix-up
00:28:00.960
commit is going to be thrown out in favor of taking the first commits subject and body
00:28:07.120
what we're fixing is really the implementation not the commit message in this case that's the big difference between squash and fix up
00:28:13.360
but super super handy when half the time you are just wanting to fix up your implementation
00:28:18.960
this is a great way to do that quickly without having to re-edit your commit messages each time
00:28:24.320
so now if we run a git log on the git commits after we've done our
00:28:30.000
rebase we'll see that we only have two commits instead of three commits now because we fixed the first one into the previous
00:28:35.919
command which is really really nice
00:28:40.960
so we can also execute code when we're rebasing believe it or not
00:28:46.399
execution is a nice way to run additional tests scripts maybe some diagnostic tools in
00:28:52.240
between our commits when we're doing a rebase it's a really really powerful tool
00:28:57.360
but i'll just touch on it briefly today and let you kind of experiment and go wild with it after so the way this works is exec
00:29:06.320
works a little differently than all the other commands where we've been renaming pic to whatever command we want
00:29:11.440
with exec we actually have to slip it in after the commit that we want to do something with so that middle commit that we were just
00:29:18.080
looking at we'll put the exact script after that commit and then run that script so in this case i'm doing a kind
00:29:24.559
of a very simple contrived example where i'm just going to print a string which is called this is an
00:29:29.679
example script in this case and that's going to run in the middle of the rebase right after that second commit but
00:29:36.559
before we actually finish our rebase with the fixed json schema that last command and what it'll do is it'll just spit out
00:29:43.200
that text in the command line it's just a simple print command i know this is very
00:29:48.640
simple but imagine if you wanted to run like your r-spec test suite or maybe r-spec
00:29:56.720
on that particular uh implementation or files that were changed in the previous commit or any other kind of diagnostics that
00:30:03.279
you might want to run the sky's the limit on what you can do here and also in this case i've only
00:30:08.640
shown you running a little simple script within the the get rebase editor there's nothing
00:30:15.360
stopping you from actually having a bash script and just executing the bash script here too so sky's the limit on what you could do
00:30:21.520
with this uh with this command moving on actually is another command
00:30:28.159
called break and this is recent i forget which version of git this was added in but it's a nice way to actually kind of
00:30:34.320
put a debug statement in the middle of your rebase it works a lot like exec but it doesn't actually execute anything it just
00:30:41.520
halts your rebase in the middle so again if we take this middle commit right
00:30:46.799
and we put a break after that what will happen during the course of the rebase is uh it'll start rebasing those first
00:30:53.279
two commits and then it'll halt at the break and then just kind of hang out waiting for you to continue the rebates you'd
00:30:59.679
have to do a git rebase dash dash continue at that point to continue the rebase
00:31:04.960
but break by the way is a it's just like i've been saying it's just a great way in which to kind of do a break point in
00:31:11.279
the middle of middle of your rebase maybe you want to add more commits maybe you just want to look at your implementation at the commit that it
00:31:17.679
broke broke at um you know sky's the limit on what you want to do but it's a it's a nice technique for for
00:31:24.000
debugging rebase finally the very last command is drop
00:31:29.919
and it's really simple almost as simple as pick except the only difference is is that when you
00:31:35.039
change something to a drop it's actually going to delete that commit entirely the commit message the implementation
00:31:41.679
everything with that commit is going to be deleted technically it's not uh
00:31:46.720
completely gone if you screwed up it would actually be in your ref log but i don't have enough time today to actually dive into the ref log for you
00:31:53.600
but that is what's happening is it's deleting that commit if you don't like to type a lot like i
00:32:00.559
do um you don't actually even have to type out drop in this case the other way to drop a commit is
00:32:06.720
basically just delete the line that you don't want and when you save and let rebase finish
00:32:12.080
it'll delete that command just as if you physically typed up drop which is another cool way to drop
00:32:19.279
commits that you don't want so if we look at the git log again and
00:32:24.559
after our rebase you'll see that we only have two commits left right we dropped the middle commit and that's exactly what we wanted in this case
00:32:33.120
okay so we've gone through all the commands now i want to talk about get rebased resolution this is
00:32:38.960
basically what you have to go through when you are doing a rebase and you have a merge conflict and what
00:32:45.120
do you do in that situation so the very first command is being able
00:32:50.320
to abort any point in time when you're rebasing if you get scared uh you're nervous um you're not familiar
00:32:57.039
with get rebase or maybe things are just the merge conflict is so gnarly that you don't know what to do with it
00:33:02.880
you can just abort at any time and it just uh prevents it just rolls back the commit or sorry the rebates it's as if you
00:33:09.360
didn't do the rebase to begin with so this is your escape patch a really cool command if you
00:33:14.880
in the middle of a rebase and you just want to start all over if you're also in the middle of rebase
00:33:19.919
and you hit a merge conflict and you resolve it when you want to continue the rebase this is how you continue it
00:33:26.399
same thing like i was saying before if you were doing a break or you were doing a rebase with an execution
00:33:31.600
or an edit and you needed it somehow halted the get rebase this is how you would
00:33:36.880
continue in certain circumstances when you're rebasing sometimes rebase will just stop
00:33:42.960
but it actually doesn't have anything to do it just kind of halted at a place where it resolved something but there's
00:33:48.080
nothing for you to do with the get rebase so in that case you can just happily skip and continue on with the rebase
00:33:55.760
basically just telling rebase to continue on its merry way the other thing you could do too is
00:34:01.840
maybe you're in the middle of a pretty complicated rebase like maybe there's like 10 commits on your feature branch
00:34:07.039
you had a couple merge conflicts and at a certain point you just kind of forgot where you were in the rebase uh flow well in the middle of rebase you
00:34:14.399
can always do git rebase show current patch and that'll give you the diagnostics of where you're at it'll show you what shaw
00:34:19.599
you're on it'll show you a diff of the of the current
00:34:24.720
shaw that you're on and you can kind of get a sense of where you're at which is
00:34:30.000
really nice you can always use git status as well but i kind of like git show current patch because it's a
00:34:35.359
nice way to give you a little bit more insight into the actual rebase that you're doing both will work i just kind of like this
00:34:42.079
one a lot better now we've gone through all the commands for rebasing
00:34:48.720
but there are a couple special ways that you can do rebasing a little bit differently using commands
00:34:54.000
that you're probably a little bit more familiar with which is git commit if you didn't know you can also pass
00:35:00.079
a dash fix up into git commit with the shaw of the commit you want to fix
00:35:05.280
so let me show you what that looks like so if we look at our git log and we have these three commits that
00:35:11.119
we've been talking about let's say that we want to fix up one of those like let's say that the initial implementation isn't quite
00:35:17.200
the way that we wanted it and we wanted to make a few changes to the files in that initial implementation
00:35:22.720
well we could edit those files make those changes commit them but this time
00:35:27.839
commit them not making a new commit message but instead making a fix up commit message for that particular shaw
00:35:33.760
so all we have to do is just pass the shot to fix up of the commit that we want to fix and
00:35:39.200
then we can pick the second commit and say that we want to fix it too um and update the implementation there as
00:35:45.760
well so what that looks like in your rebase editor if you do a git interactive rebase and you rebase off a
00:35:51.760
master uh you'll see this in your editor and if you've never seen this before it's just
00:35:58.079
you've got five commits here instead of the three because we did the commit with the dash
00:36:03.359
dash fix up command and what git does is it creates a fix up bang command or sorry a fix up bang commit
00:36:11.280
with the same subject as the um as the as the commit that you want to
00:36:17.040
fix up so in this case the way the git does this um is it associates the subjects
00:36:22.720
together um and makes it so that you can easily fix things that you've told it to fix up in
00:36:28.960
the previous slide that i was showing you where we were doing a git commit with a fix up so uh
00:36:36.400
the way the git does this is it's very simple it just makes a fix-up bang and it uses the subject of the commit that
00:36:41.839
you're trying to fix up the reason i highlight this is because you don't want to rewear it at the same time you're fixing
00:36:48.000
because if you rename the commit that you're trying to fix the fix up won't actually know where to
00:36:54.560
associate itself so try not to do that when you're doing a fix up the other thing too here is normally these fix up bank
00:37:03.119
commits will show at the very bottom of your commit history so instead of having them intermixed
00:37:08.720
like you see here because i have some advanced features turned on git wouldn't normally do that by default
00:37:14.160
you'd have to physically move those fix ups to where you want them to be i'll show you how i have this turned on
00:37:19.440
and how git did this automatically in a few more slides but just be aware that that's what i
00:37:24.560
have turned on here and then again in the second commit the reason git was able to associate
00:37:30.400
uh where the fix up needed to go with the original fix up or sorry the original commit is through the subjects both those
00:37:37.599
subjects have to match that's how git is basically doing that calculation now when we save this and we rebase and
00:37:45.040
we do a git log here we'll see that those fix ups magically got merged into the previous commits and our
00:37:51.839
fixes are in place and it looks like we just have those three commit messages from before except this time they're fixed properly
00:37:57.839
the way that we wanted to which is exactly what we wanted and a nice way to kind of
00:38:03.599
sort of massage and make those fixes and screw ups that we caught while we
00:38:08.800
were doing our feature branch work before we actually get it up for code review
00:38:14.640
so just like fix up you can also use squash it works the same way as fix up except
00:38:21.599
when you do a git rebase right it's going to halt and allow you to edit your git commit messages that's the only difference but the flow
00:38:28.400
is still the same so if we look at our git log we look at these three commits and let's say that we want to squash one
00:38:33.839
of them we just put in the shawl like we do with the fix up and then what that's going to do in your
00:38:39.440
editor is it's going to halt and it's going to say hey look uh these two commits here
00:38:46.480
uh they're gonna be squashed by the subject and in this case you can you can uh the rebase editor will halt
00:38:54.240
and then allow you to edit the commit message at the same time that it's squashing it same thing as the fix up bang except
00:39:01.359
that you get to edit the commit message in this case that's the big difference
00:39:07.119
so now that we've gone through those two techniques which are really handy for the command line the other thing i want to mention is
00:39:13.200
amend you might actually be pretty familiar with this especially if you've done a decent amount of get work
00:39:18.720
this is a pretty common tool to be aware of but i want to highlight a few things for you a man by the way always amends the
00:39:24.560
last commit and it's a great way to edit that last commit really quickly
00:39:29.680
without having to launch the entire rebase editor because that would be too much work
00:39:35.040
what you can do though is you can pass in no edit to amend your previous commit but don't
00:39:41.040
pop up the editor the reason i point this out is this is really nice for situations where you've made a change to your
00:39:47.520
implementation but you really don't need to pop up the editor you don't need to change the commit message so this is a fast way to do that
00:39:53.520
the other thing you could do is you could also push in pass in dash dash all and that'll allow you to kind of slurp
00:39:58.960
up everything you're working on and throw it into that last command granted you still want to keep your commits atomic right just implementation
00:40:05.680
plus spec if you can keep it really tight very clean but if there's a lot of changes because you're doing a refactoring or
00:40:12.240
there's a bunch of things all related this is a great way to kind of grab all that throw it into the last commit
00:40:18.640
without even popping up the editor which is a really fast workflow
00:40:24.240
uh so let's talk about a few more rebase tips a few things to actually power up and make your workflow and get
00:40:32.079
rebase workflow a lot more easier and pleasant
00:40:37.119
there's three commands that i highly highly recommend that you turn on in your global git configuration and let's walk through each one of them
00:40:43.680
the first one is abbreviate commands if you turn this on to true that'll change the get rebase editor
00:40:48.800
from typing out the long form of pick and reword and drop it'll just change them to their single
00:40:54.400
letter equivalents so instead of p i c k for
00:40:59.599
pick you just have p d for drop and r for reword i highly recommend turning this on once
00:41:05.200
you get familiar with the rebase workflow and you don't want to do all that typing auto squash by the way is how the squash
00:41:11.920
bang and the fix up bang were showing and aligned next to each other in the commit editor
00:41:18.800
git rebase editor when i was showing you in the slides previously by turning this on git will figure that
00:41:23.839
out and align those subjects together so that they're nicely they're put where you want them to be if
00:41:29.599
you leave this off as false that means you have to manually do that movement yourself
00:41:34.720
so highly recommend turning this on and the last one is auto stash auto
00:41:40.160
stash is is wonderful because normally when you rebase if you have anything dirty in your working
00:41:45.680
directory the rebase won't will halt will actually not start because it wants you
00:41:52.160
to do something with those files either commit them or delete them or stash them
00:41:57.440
so normally you would just stash them manually yourself
00:42:02.480
but what auto stash true does is before the rebase kicks off it'll detect those
00:42:07.520
changes immediately throw them into stash without even prompting you allow you to do the rebase and then when
00:42:12.800
the rebase is complete it'll pop the stash and put you back to where you're working it's a really awesome
00:42:18.480
workflow and highly recommend turning on just to let git figure all that out for you so you don't have to
00:42:23.839
manually do it yourself and by the way these are the command line arguments or the
00:42:30.400
the commands that you would type through your c your shell if you wanted to enable this globally
00:42:37.440
okay one last thing that's really powerful to configure for git rebase which is get re re-re or re-rear i i
00:42:45.440
can never pronounce it properly but it's really nice to have turned on as well so first of all you want to enable it
00:42:51.359
and what that'll do is that'll basically doing a rebase it'll any
00:42:56.640
conflicts that you resolve it'll record and stash those conflicts into like a small patch set
00:43:03.440
and um replay those anytime you do a rebase in the future so that you don't once you've resolved
00:43:09.040
the conflict resolution especially if you're rebasing heavily constantly um you're working on your feature branch
00:43:14.079
for a long time a lot of changes are coming from your your team down upstream uh as you resolve those merge
00:43:19.680
conflicts you don't want to keep having to resolve those every time you rebase it's pretty much it's kind of a pain
00:43:24.960
in those cases you can teach freebase to remember those merge conflicts and
00:43:30.880
attempt to replay those when it sees that it can actually do that automatically for you so highly highly recommend enabling that
00:43:37.680
the the last thing here is auto update if you turn this on it's off by default but if you turn
00:43:43.520
it on when you resolve those merge conflicts and you make any additional modifications to them
00:43:50.079
git will also remember that as well and try to replay that information as well so as you get better
00:43:56.000
at your rebasing and uh merge conflicts and and resolving those basically riri is a nice way in which to teach git
00:44:03.839
to also remember those changes and try to do that work for you if it detects it
00:44:09.200
and again these are the command line uh this is the command line that you want to run if you want to enable this
00:44:14.319
globally highly highly recommend turning this on it'll it'll save you some work
00:44:19.760
okay so now that we've gone through the rebase workflow we've talked about the difference between merge and rebase
00:44:25.520
how to use rebase how to configure rebase wouldn't it be awesome if you had a
00:44:31.359
coding buddy an automated little bot that could hang out with you and help ensure that your git commit messages
00:44:37.119
are well really well written and well-formed well gitland is a ruby gem that i've
00:44:42.960
developed that actually makes that possible uh what it does and we won't go into all
00:44:48.480
the details here but i'll just kind of go gloss over it briefly is it'll help you make sure that you have property
00:44:53.520
capitalized prefixes to your subjects it'll make sure that you have correct
00:44:59.280
punctuation make sure that you have a space between your subject and your body so that they're not smashed together and
00:45:04.480
they're easy to read and also make sure that you have like a nice 72 character limit so that you don't have horizontal
00:45:10.800
scrolling uh in code reviews so that they're easy to read and they're nice nicely word wrapped
00:45:16.880
and it does a ton of other things and i won't go into that all today but to install it it's very simple just
00:45:23.119
do a gem install you can check out your project switch to your feature branch and then you can
00:45:28.720
analyze it and by default get lint will analyze a feature branch it won't do anything on
00:45:34.640
your master branch because um once the code is on your master branches you can't really re rebase that or you
00:45:42.160
wouldn't want to anyway uh your team would be very upset with you if you did
00:45:47.920
but you can analyze it that way and that will tell you whether your git commits are of sound quality
00:45:53.599
there's also plenty of ability to wire it up as a get hook so that get lint is always running
00:45:59.440
every time you make a commit you can even wire up ci support on my team we actually use it as a github
00:46:05.200
action so tons of ways that you can configure get lit to actually work for both you locally
00:46:11.760
through get hooks or via your team in a ci environment
00:46:17.200
so what are the next steps right we've gone through git rebase we've talked about the flow
00:46:22.720
the configuration options and even using gitlint as a tool to help make your commits better well
00:46:28.960
the first thing you can do is uh start your workflow and just focus on it every day just take a little bit take some of the
00:46:34.880
commands i was telling you today work on them bit by bit keep getting better and better and
00:46:40.079
exercising that mental muscle until it just becomes second hand and then this will become easier
00:46:45.599
and just a natural part of your workflow without causing you any grief or pain the other thing you could
00:46:52.560
do is a lot of those commands that i was typing out and showing you it's a little bit to type right so if
00:46:57.920
you can make an alias or a function to automate that even further i highly recommend doing that and i have a link here to my dot files
00:47:03.839
project in case you want to see additional examples of how i alias things how i write functions and just make this workflow
00:47:10.640
really hum along so i don't have to do a whole lot of typing and then lastly consider adding gitland
00:47:17.280
to your projects right let it be a coding body to you but also to your team in order to make those git commit
00:47:22.960
messages tell a good compelling story so that your history is linear
00:47:28.240
debuggable and easier to read not only for your future self but also for your fellow colleagues
00:47:33.520
in case you're traveling on vacation or not even with the company anymore they'll have the joy of being able to understand what it was that you're doing
00:47:40.400
at that point in time when you're implementing that code and that's a really good feeling to leave behind as a legacy of your work
00:47:47.040
for others to enjoy and that's it that's uh my get rebased
00:47:52.720
talk kind of in a nutshell i know that's a lot to go through um there's plenty of screencast tutorials long form articles
00:47:58.960
on the alchemist collective website there highly recommend uh checking this out i'll have my slides up there as well
00:48:05.520
and all the links and everything that was in this presentation will be there for you to enjoy and dive as far as you
00:48:11.359
want to into this rabbit hole thanks so much for everyone allowing me to speak at ruby galaxy i hope you
00:48:17.839
enjoyed this and i will see you online
