Should I use rebase?

4

I'm working on a redesign of our web application, in a separate branch, say new_interface . Meanwhile, other developers are still in the master branch, mostly resolving bugs. While some files may differ considerably, I need to recover the fixes that were made by other developers.

Until then I have given merge of master to my branch (using TortoiseGit), but for the last time this did not work. Several files went wrong, even some that did not accuse conflict. It looks like merge chose the master version instead of the reshaped version.

As an alternative to solving this situation, I am trying to study rebase , but I still do not know if this would solve my problem.

Will rebase resolve my situation or will the result be the same as merge ?

Edit: I confirmed that although the conflict editing system is a bit different, the final result is very similar, even with the same problems. For example, in some files the changes belonging to new_interface are gone in the final log in both methods.

Will I have to manually change all the changes from one branch to another or is there still another alternative?

Edit 2: I ended up doing a merge (squash, recursive - patience), however I had to go file by file (including those that did not accuse conflict) choosing which changes I wanted to incorporate and which ones to discard.

One mistake I had made the first time I tried the merge was to click on "resolve conflicts using mine" in the files I wanted to keep intact. Actually the right thing would be to mark "revert", discarding the version of master and keeping the file as before the merge.

    
asked by anonymous 25.05.2015 / 17:14

2 answers

3

The result will be the same. In both rebase and merge, if the same line is changed in both branches, it creates a conflict for you to resolve manually. If any modification of master passed without saying anything is because the git algorithm did not consider it a conflict.

Choosing between rebase and merge is more a matter of taste. The main reason for rebase is to edit the commits history to be linear. Depending on your workflow and what modification you are making in history this may be what you want or not.

Returning to your specific problem, it is usually a good idea to keep the branches "short" and not to do several master branch merges for your development branch. If you can not merge your branch back to main quickly, it might be worth trying to override your branch to the top of the master, to pretend you started working on it today (from the point of view of the commits history)

    
25.05.2015 / 18:51
0

No. If you override master - > new_interface , commits in master will be re-created in your branch. That is, there will be commits with the same name, content, and different hashes.

    
25.05.2015 / 18:51