Hello, dear students, in this lesson, we'll learn what a great rebellion is and what for some day
it is.
I will show you how and when you can apply.
Get your base command.
I will explain what rebase actually means.
Also, I will explain the difference between good marriage and get to base after.
We will understand Ceri.
We'll take a look at real example and we'll learn how we can use our base command on a daily basis.
You're going to see how to keep your military clean during the lesson.
You're going to learn how to solve conflicts that could appear during the invasion.
On the other branch, on real examples, I will show you what gets replaced with option continue means
and how to complete the remaining process.
After we change the local comment history, I will show you what force of date is and how force with
lease option may help us.
And at the end of the lesson I'm going to share with you four Rules of Happy Perquisite by Peter.
Just jokin is always.
And to start with, let's discuss the problem which we faced during the previous lesson, if we resolved
conflicts with Bookham and you saw that one more comment was created and you also saw that I can't merge
with the best strategy to M. I can only merge with new command.
So our problem is how to get his territory clean, the presidential and union commands.
Let's understand first what our base is and how it works.
In general, there are two main ways to integrate changes from one branch into another.
Zaya Yes, merge and military base.
We already learned in previous lessons more about Gaete merging branches.
Now let's understand on the high level what is a rebase let's recall an example.
When we had the branches, the easiest way to synchronize the branches is to merge them.
So to merge C3 and C4 snapshots, we have to create one more snapshot.
Thus one more comment.
C five.
This option works just fine and we saw how it works.
But do we have another option that will not create additional senseless commit?
Yes, we do.
Based on the awesome branch, what does that mean?
We can take changes that we have in C four commit and put them on top of C three.
That mean you can take changes that were done on one branch and apply those changes on the other branch.
In our example, I can execute Command Guitry Bassmaster while being on the experiment branch.
This will lead us to the good history that you can see on this slide.
You can see that C snapshot is going right after C three.
This will allow the great pull request and merge branches and help with the and strategy.
In this particular scenario, we can switch back to the Master Branch and do fastforward much like it
has shown on the slide.
And in this case, you can see that there are no any other comments from Najin branches and we have
Coingate history.
We're also going to have lessons about interactive freebase a bit later in this course, where I will
show you how you can use reverse command to combine commands or to change commit messages.
But in this lesson, we'll run the rebels command only from the point of margin changes from different
branches.
On the previous slide, you saw base command to replace changes from another branch.
But in real life example, later today we are going to use a bit another variation of this command,
get ball with a base option.
So what is the difference between a military base and pool with a base option?
Using base command replaces the branch which we want get bored with.
The base option can be treated as shorthand for git fetch and then get through base command.
You will be able to fetch all the latest changes from the remote repository prior to revising our code
on top of it.
Because if I would just use Guitry Bassmaster Command, it would only take into account what local repository
is already aware of, but not the changes from the remote repository.
This is very important, practical tip.
That's why this video, of course, is so valuable to all my students, because even if you would read
documentation and use it to base, you wouldn't read the expected goal.
And it is not clear that Boogerman has a base option.
If only you read all your documentation.
Probably by this very moment of our lesson, you are wondering what is better get much or get base?
Which one should I use to give you the full answer?
I'd like you to understand one more time what repositories history means from different point of use.
Repository history is the records of what actually happened.
From this point of view, it might seem like not a good idea to change history from this angle.
Using the base is similar to lying about what actually happened in your repository.
But is this valid comment all the times or there are some exceptions?
What if there are a series of large companies that brings us almost zero information about conversion
improvements?
That brings us information that branches remerged OK?
And what that is logical is that branches should be merged at some point.
But I am more interested in the functionality of the specific version of code rather than the fact that
there was not much.
That is the point of view on what repositories history means.
My personal opinion is that we should treat our history as a story of how our project was made.
If we are writing a story, there is no harm in doing side notes and tracking each step.
But when times come to release the story and show it to the world, I want to tell more coherent story
without all my drafts.
And that didn't pass.
But despite my personal opinion, I believe you understood that there is no right answer which approach
is better.
And just keep in mind that all projects are different and there is no silver bullet for each project.
There is no one size fits all approach.
But being a true professional, you have to be aware about different points of view.
That's why I believe it is important for me to share this with you.
OK, now, when you understood the theory of revision, I suggest looking at our practical example.
Keen to understand the damage in this lesson, you have to understand the drama from previous lesson
because we have the same context as in previous lesson will proceed from the point where we finished
previous time.
Let me call Gitlow command of last's recommits gridlock.
Dash three here.
You can see that I have not commit one result together.
Much conflict.
You can see here that this much coming of this Ansar's Kummetz, you can check, check, checksum here.
And here's a reference to Logan pop up.
You're in Logan Command.
That is command that emerged from a three zero four branch.
And we see in parentheses that it is from a region master branch and we have our own command, which
we did, and scope of this branch gursel on the home page and then Miyu another option of handling much
conflict.
And to them or a base to you, I suggest we said in our state to the state of this comit carrousel on
the home page before we even did a good pull origin master command.
Right now you are going to get reset command, which we are going to learn in the separate lesson.
I have to use it in this lesson so that you would keep track of all my changes in the git repository.
I believe that showing all my actions and to you is the best way to learn such a powerful tool as good.
I will perform the next command and I will explain in short what it does get reset.
This command can reset state of your file system to the specific revision option.
Hard reset command has different modes will learn all possible modes in the separate lesson.
Heart means that files from the other region will be restored and all changes from other revisions will
be removed.
Had had is appointed as a current place.
And yet that is our last comment to the one.
This means reset state of our file system to the state that was one commit ago.
That is right before we pulled changes from the original Master Branch.
Let's press enter and here we are on the castle on the home page.
Commit, let's check.
Commit history now.
Get locked command.
Awesome.
We can even check our file system.
Let me show you that we don't have Logan says says file from another branch, said Stiles.
And residential, and you can see that we only have Gursel to file and we don't have any logins, he
says file here.
Cool.
Let's get back to the SASE directory, Siggie double dot.
And now, instead of doing it, pull origin master.
Let me execute another commands that we have learned today.
Get was optional base a region master.
This was expected in case we wouldn't have any major conflicts, rebates would be very smooth, but
that is way too easy for you.
Let me show you how to resolve NAHJ conflicts during the invasion.
I believe you remember that we expect much conflict in home, not HTML file, but this time we have
a bit different message.
We see that error happened during the invasion and commit could not be applied here.
It leaves a hint for you what to do in this case.
We have to resolve all conflicts manually.
After that, we have to either add or remove files to the staging area and execute rebels continued
command.
I don't recommend this keep this coming like it is shown here, because our goal is to resolve conflicts
and finish freebasing.
In case you understand that it is a mistake and something is going wrong, you can execute Guitry base
with abort option.
By the way, here in parentheses, you can see indications that we are in the process of revision right
now, but let us resolve conflicts.
Nano web content slash home, not HDMI.
Let me quickly resolve these conflicts.
After conflicts are resolved, I close and save this file.
Now, as it was said before, I have to add files to the staging area yet at DOD and now we can proceed
our amazing database, continue to get offers me to adjust my message.
But I want to keep it the same cursor on the homepage.
That sounds just perfect.
So I just closed the file and I see a message that I was successfully based on the other branch.
Now let me update my branch in remote repository to update my poll request.
Get Bush.
Oh, I see error here.
Those were rejected.
Why?
Because I already had a ranch in the remote repository, my region, a three zero five home carousel
branch, has different comment history rather than my local branch.
Now, because the base command changes get history and it is not smart enough to understand this.
Forget it is just looks like a mess.
Now, our local branch and their branch has a different history of comments.
Let's take a look one more time at the history of Cummins of the remote branch.
Can you see these two comments?
And you can see comments, checksum.
Now let's return to get Bush and check Commissaire git log.
Deshotel, can I see this?
We put our cursor on the homepage comit right on top of the massive branch.
That is actually what we base does and pay attention to check some here.
Can I see that?
It was the same message has different checks.
OK, well understood that our committee history is different on different branches.
But what to do now?
I need to tell you which version is correct.
I know that my current branch is the most relevant branch, so I have to update my original branch so
that it would have the same comment history as my local branch.
To do this, I need to perform the next command, get Bush with option F.
F stands for Force Update.
Be extra careful when you do this, because force update will erase changes that are currently present
in the remote repository in this branch if you are going to use from base command.
That means sometimes you would need to use force update option.
But one more time.
Be extra careful.
Use this option only with your branches, only with branches that only you are aware of, because in
case somebody created the branch from your branch and you change history and your branch was merged,
that will cause extra efforts for the engineer who created the branch from your branch.
Real life example, KYAY automation engineer who is going to help you with writing your tests for your
home.
Carasso created his own branch from your branch, your updated comment history and merge it to the master
key engineer can't match.
Mostly his branch needs that your branch needs to master right now without freebasing and solving conflicts
one more time.
Or imagine that key engineer merged his or her changes into your branch.
And by applying for update, he overrides those changes and the documents were lost.
This even sounds complicated, so please try to avoid this.
Today, we're going to create a few rules that will save you a ton of time and your nerves in the future.
I call this rules for rules of happy workwise.
Get by and repeat the rule.
Number one, always create branches from the master branch, but not from the other development branches.
Rule number two, force update only your own branches that you can be sure nobody using because of the
risk of losing data force is very risky mode.
What is less risky is the rule of thumb is using force with less option.
What is this about force, which is a safer option that will not override any work on the remote branch
if more comments were added to the remote branch by another team member.
Based on this, let's make rule number three.
When you need to use force update, always use force with less option.
I can't even count how much time this simple rule saves me tons of time.
So we use force with this option.
Let's press enter button.
Take into account no update in my branch, I successfully updated my branch in the remote repository
and my request let's check my power now.
Can you see this?
I have one comment instead of two and also check some of the comment, carrousel on the home page is
changed.
Now I can use Rebase and my strategy.
That is awesome.
We did this together and now it is time for the rule number four.
Rule number four always are based on a region.
Must have brunch before creating a comet.
Now you know how to replace and M..
I would even say that this is a best practice to rule based on the region master as often as you can
to fix conflicts gradually and to test your implementation on the latest version of the code during
the development to not spend a lot of time.
When you worked one week on your task and after solving all conflicts, you realized that feature doesn't
work as expected.
OK, which is really a lot today.
Let's recap what we have learned today.
In this lesson.
We learned what the basis we understood the difference between merge and rebase.
We tried to answer the question, what is better to use it, merge or get rebates from different points
of view?
One real example, you saw how a command works.
You know, when you need to execute, get from base, continued command.
Also Villon, when we need to use force update mode.
And how fast was this option can help us to not override other comments.
And at the end of the lesson we reviewed for roles, have happy work with it.
We learned a lot today.
I'm really happy you saw this lesson.
Thanks a lot for your attention.
The students have agreed the rest of the day and see you in the next lesson.