{"id":5688,"date":"2021-01-19T12:34:25","date_gmt":"2021-01-19T13:04:25","guid":{"rendered":"https:\/\/ultering.com\/it4us\/?p=5688"},"modified":"2023-08-02T03:28:42","modified_gmt":"2023-08-02T03:58:42","slug":"git-rebase-when-and-where-not-to-do","status":"publish","type":"post","link":"https:\/\/ultering.com\/it4us\/?p=5688","title":{"rendered":"Git: Rebase – When and Where Not To Do"},"content":{"rendered":"

There are many good posts about the differences between pulling with and without rebase, merge and etc.
\nIf you desire to refresh memory about this, try these:<\/p>\n

git: the difference between git pull and git pull \u2013rebase<\/a><\/p>\n

Git Branching and Merge vs Rebase- <\/a><\/p>\n

\n
\n

<\/h3>\n

This post intends to supply information on when and where not to do a rebase.
\nThrough an example of our typical day life when things go wrong and the documentation let interrogation marks on your mind: and what does it happen then?<\/h3>\n


\nScenario<\/strong><\/p>\n<\/div>\n

Suppose that the master branch is very difficult to understand, having so many threads tangled among them that you start thinking about if “rebasing” wouldn’t help.
\nPlease, for the sake of your own happiness and dignity, don’t.<\/p>\n

Why?<\/strong>
\nThe short answer is this:<\/p>\n

First, you’ll change the original information and your team may not approve it.
\nSo, ask them first.<\/p>\n

Second, all operations involve risk and things may not happen as expected.
\nMurphy is elsewhere, unfortunately \u2014 or not, looking the other way around, you may concern that makes our life more exciting and challenging, after all, if everything always works well, life would lose that feeling of risk that turns life so exciting.<\/p>\n<\/div>\n

So, better to get prepared to handle “Murphy”! \ud83d\ude42<\/p>\n

<\/h2>\n

<\/span>ONE USE CASE AS AN EXAMPLE<\/span><\/h2>\n

Performing the master’s rebasing:<\/p>\n

git checkout master
\ngit pull –rebase<\/p>\n

Usually, you may get a conflict to solve.
\nBasing on GitHub’s documentation<\/a>, you perform the fix.<\/p>\n

As supposed, any documentation must concern about the usual procedure supposing an optimist scenario and sometimes adding extra direction to some issues.
\nIssues are part of our IT daily life, always challenging us with unexpected ones.
\nBelow, I transcribe parts of its documentation to make things easier (italic).<\/p>\n

 <\/p>\n

\n
\n
\n
\n

<\/span>#Resolving merge conflicts after a Git rebase<\/em><\/a><\/span><\/h3>\n
When you perform a git rebase<\/code> operation, you’re typically moving commits around. Because of this, you might get into a situation where a merge conflict is introduced. That means that two of your commits modified the same line in the same file, and Git doesn’t know which change to apply.<\/em><\/div>\n<\/div>\n<\/div>\n
\n
<\/div>\n<\/div>\n
\n

After you reorder and manipulate commits using git rebase<\/code>, should a merge conflict occur, Git will tell you so with the following message printed to the terminal:<\/em><\/p>\n

error: could not apply fa39187... something to add to patch A\n\nWhen you have resolved this problem, run \"git rebase --continue\".\nIf you prefer to skip this patch, run \"git rebase --skip\" instead.\nTo check out the original branch and stop rebasing, run \"git rebase --abort\".\nCould not apply fa39187f3c3dfd2ab5faa38ac01cf3de7ce2e841... Change fake file<\/code><\/pre>\n
Here, Git is telling you which commit is causing the conflict (fa39187<\/code>). You’re given three choices:<\/em><\/p>\n