Jeez wait, but what would that be? Is it to eat?

Fast-foward is possible when there are no conflicts between the branches involved and when the development branch is ahead of the main branch.

Our scenario

When we follow Git Flow correctly, there is a rule that we call the "Golden Rule of Rebirth." Basically, this rule says that recovery should not be used in public agencies either, as it has high catastrophic and destructive potential or commission history, whenever there is disagreement between local agencies and remote agencies. However, there is a very nice workflow that can be used by combining both commands.

Let's imagine that you need to start working on a task within a Git-controlled project. If you follow Git Flow correctly, you will need to create a branch so that you can work on your task

You will probably generate a new branch to develop your task from master. We can then have the command below:

git checkout –b feature #creating the branch of work

Then we can generate our commits, saving our work gradually while other people can mix their commits with the master.

Now is the time to integrate our commits with the master. We need to do this in two ways, basically:

• Bring the changes that were later entered into the master into our branch. We need this step to ensure that subsequent changes will not "break" the changes we made to our branch;
• Bring changes from our branch to the master, updating it with our work and making it available to other developers.

Let's deal with the first step at this time. If we stop to analyze the situation, it makes more sense to bring the master commits to feature in a “transparent” manner, ie without the need for an additional commit.

This will keep our history completely linear and will ensure that new master commits will be applied to our branch at the “right time”, preserving the order in which they were generated. So for this first step, the rebase makes a lot more sense. Therefore, assuming we are already in the feature branch, we can execute the command below:

git rebase master

This will produce the following illustration:

The first step has been completed! We have our feature branch properly synchronized.

However, our master branch, which is the main branch, is still outdated as it does not have our commits yet. We need to pull our commits from the feature branch to the master branch. As we are talking about the main branch, it is important to maintain the traceability of the code management process, making it clear even when local branch commits were pulled into the master branch.

So for this second stage, merge is much more interesting than rebase.
In this situation, all possible problems of “blending” the two branches (such as conflicts) were resolved during the rebase process.

In this second step, we can simply change the pointer of our master branch, pointing it to the last commit of our feature branch. When this process happens, we call this fast-foward merge strategy. Fast-foward is possible when there are no conflicts between the branches involved and when the development branch is ahead of the main branch.

From the previous illustration, this is exactly the situation.

git checkout master # going to the master branch
git merge feature    # merge between master and feature

Therefore, our master branch is now as follows:

Note that this way we have the best of both worlds: we don't have the commit history polluted by secondary commits in the feature branch (thanks to rebase) and we have the traceability of when the master branch was modified by an integration (because of merge).

for today that's it