5 ms·

> I've tried the "rebase into a feature branch" workflow, which I think you are alluding to. Unfortunately, it always results in scary conflicts. You never reb

> I've tried the "rebase into a feature branch" workflow, which I think you are alluding to. Unfortunately, it always results in scary conflicts. You never rebase something into something else, you rebase onto something. I suppose you meant you want to rebase feature branch onto master. If you have conflicts, you'll have them anyway, regardless if you're merging feature branch into master, merging master into feature branch or rebasing feature branch onto master. Conflicts are not a consequence of rebasing.

mixmastamyk 5y ago
I'm working in a feature branch, and after a day or three changes have landed in the main branch. Which I need to incorporate or my merge request will be behind. When I pull from main (git pull origin develop) there are rarely conflicts. When there are they are easy to understand and fix. Clicking squash on my request hides all intermediate commits so history stays clear in any case. When I try to rebase from main (git pull --rebase origin develop) often almost every file in the project is in conflict, and the conflicts themselves are incomprehensible. I then run rebase --abort and go back to the merge strategy. I've tried this about four times in the last few years; no one is able to explain what went wrong. If I had to guess it may have something to do with me pushing the branch when creating it.
- schlupa 5y ago
  That's not how you do it. git checkout master git pull => fetch and merge the new things on master git checkout develop => go back to your work branch git rebase master => simple rebase, no squash, no nothing. The conflicts are the same as you'd get with git merge do not forget to force push the changes of your branch git push origin --force develop => to update your branch on the server
  - Shacklz 5y ago
    You can skip the "checkout master + pull" part by using "git fetch origin master:master", or by using just "git fetch origin" and then "git rebase origin/master". Other than that, that's pretty much my workflow too :)
    - schlupa 5y ago
      Yes, I know. I just wanted to keep it at the simplest form.
      - mixmastamyk 5y ago
        Ok, thanks. Although making a one step process into five, doesn’t sound like a big win. Perhaps the shorter version is workable.

mixmastamyk 5y ago

I'm working in a feature branch, and after a day or three changes have landed in the main branch. Which I need to incorporate or my merge request will be behind. When I pull from main (git pull origin develop) there are rarely conflicts. When there are they are easy to understand and fix. Clicking squash on my request hides all intermediate commits so history stays clear in any case. When I try to rebase from main (git pull --rebase origin develop) often almost every file in the project is in conflict, and the conflicts themselves are incomprehensible. I then run rebase --abort and go back to the merge strategy. I've tried this about four times in the last few years; no one is able to explain what went wrong. If I had to guess it may have something to do with me pushing the branch when creating it.

schlupa 5y ago
That's not how you do it. git checkout master git pull => fetch and merge the new things on master git checkout develop => go back to your work branch git rebase master => simple rebase, no squash, no nothing. The conflicts are the same as you'd get with git merge do not forget to force push the changes of your branch git push origin --force develop => to update your branch on the server
- Shacklz 5y ago
  You can skip the "checkout master + pull" part by using "git fetch origin master:master", or by using just "git fetch origin" and then "git rebase origin/master". Other than that, that's pretty much my workflow too :)
  - schlupa 5y ago
    Yes, I know. I just wanted to keep it at the simplest form.
    - mixmastamyk 5y ago
      Ok, thanks. Although making a one step process into five, doesn’t sound like a big win. Perhaps the shorter version is workable.