Should I wear rebase?

Asked

Viewed 330 times

4

I’m working on a redesign of our web application, in a separate branch, say new_interface. Meanwhile, other developers remain in the branch master, mainly solving bugs. While some files may differ considerably, I need to recover the fixes that were by the other developers.

Till then I’ve given merge of master in my branch (using Tortoisegit), but last time it didn’t work. Several files got wrong, even some that did not accuse conflict. It seems that the merge chose the version of masterinstead of the reworked version.

As an alternative to solving this situation, I’m trying to study the rebase, but I still don’t know if it would solve my problem.

The rebase will resolve my situation or the outcome will be the same as the merge?

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

I’ll have to manually move all modifications from one branch to another or there’s another alternative?

Edit 2: I ended up merging (squash, recursive - Patience), but I had to go file by file (including those who did not accuse conflict) choosing which changes I wanted to incorporate and which 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 completely untouched. In fact the right would be to mark "revert", discarding the version of master and keeping the file as before the merge.

git tortoisegit

  • Who has permission to create tags, could please put the tag tortoisegit?

  • You should always use rebase so put your commits at the end of the line of changes. However, if the changes are on the same lines, this may give error that needs to be solved manually. The ideal is to always commit frequently even with little code and update with everyone who is working on the code.

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 the master went without saying anything is because the git algorithm did not consider it a conflict.

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

Getting back to your specific problem, it’s usually a good idea to keep branches "short" and not keep making multiple merges from the master branch to your development branch. If you can’t merge your branch back to main quickly, it might be worth trying to rebase your branch to the top of master to pretend you started working on it today (from the point of view of the commit history)

  • In fact, I tested it here (in copies of both branches) and although the conflicts were resolved one by one instead of all at the end, the result was practically the same. That is, the problem remains.

0

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

Browser other questions tagged git tortoisegit

You are not signed in. Login or sign up in order to post.