6 ms·

Git Tricks: Avoiding merge when dealing with remote conflicts

59 points by danzanzini 7y ago

gouggoug 7y ago
And git config --global branch.autoSetupRebase always will ensure that all your future branches are automatically setup to `rebase` instead of `merge` on pull.
- anon9001 7y ago
  You should want those merges so that you can later bisect where a problem was introduced. If you start/end each day with a merge and leave the merge commits in, and you notice something goes wrong later, it's much easier to trace where the problem is. Rebase definitely satisfies my OCD and makes everything look pretty, but it's actually worse.
  - Benjammer 7y ago
    >you notice something goes wrong later, What, specifically, do you mean by "something goes wrong later"? Like a full outage of some kind? A production bug? A mistake according to the design spec? A failed test in CI? A failed human QA validation? What are we talking about here? >it's much easier to trace where the problem is. Furthermore, why would the git commit structure have anything to do with debugging any type of issue, regardless? Isn't debugging mostly comprised of combing through logs, adding random print statements to console output, and using an IDE debugger? Or some kind of more advanced tracing/profiling tools? Are you debugging by hunting in commit histories and Jira tickets or something? Or are you talking about blaming, not "tracing where the problem is", but "tracing who the problem is"?
    - anon9001 7y ago
      This post explains it better than I can in a comment: https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1 https://medium.com/@fredrikmorken/why-you-should-stop-using-...
      - kazinator 7y ago
        That article is some FUD about a real bug in a feature branch being masked due to other bugs that were introduced by the rebase itself. That is not realistic because, firstly, a very specific test can (and should) be used for git bisect. You're not just testing for "software fails", but "very specific case fails in a specific way". If some intermediate issues prevent you from testing the specific test case (you're not able to call "good" or "bad"), you can tell git bisect to skip that commit. Shit happens! Bug was introduced a month ago, but two weeks ago, a range of commits happened that don't even build in your environment. git bisect will hit that. The article also glosses over the possibility that git bisect goes back farther than the bad commit. Commits that are not testable can occur earlier or later than the one we are looking for. Basically the article is just a new version of the old meme "merging is dangerous". except that it doesn't make any sense, since both "git merge" and "git rebase" textually merge code.
      - sixstringtheory 7y ago
        I think the best point of this article is accidentally introducing breakages into history that later defeat the purpose of git-bisect. However, in practice I haven't run into this problem, at least not in an insurmountable way. One solution is, if you can run your tests with e.g. `make test`, you can run `git rebase --exec "make test"` which will run your test suite against every commit being rebased. I've only done it a handful of times, and because of how long it takes I'd only run it after finishing a rebase that wound up needing resolutions, instead of doing it up front and having to wait for the tests to finish at each commit before potentially resolving another upcoming conflict. If you are very paranoid about breaking commits being pushed, disallowing rebase isn't enough: any dev could simply write a commit with a breakage. You'd have to set up pre-commit hooks to run your tests, or a pre-push hook to run `git rebase --exec "make test"`. TIL there is also a post-rewrite hook, which sounds like it solves exactly your worry with rebase, but as I mentioned, introduces long delays between rebase commits/resolutions–I'd probably forget what I was doing during each test run, haha.
        anon9001 7y ago
        It can definitely be made workable, but why do so much in pursuit of a slightly neater git log? I place a much higher value on the hashes of my commits not changing than having extra merge commits.
  - bob1029 7y ago
    We have been struggling between the merge/rebase approaches with no clear winner in our minds so far. In principle the rebase seems to be superior, but I can certainly see arguments for using merge if it satisfies downstream concerns like traceability (I am still not clear on this stated benefit). Perhaps someone has a list of criteria that can help you pick between the 2 approaches, or perhaps both merge/rebase are valid at all times, but there is a certain set of rules to evaluate when choosing which to use?
    - kazinator 7y ago
      rebase has good traceability, if you retain the original artifacts. When we rebase a public feature branch and merge it into a mainline, we nicely have two versions of that. Basically, rebase and merge could be reconciled like this: we could merge a feature branch by iterating over it, and invidiually doing a git merge for every commit. Then that would be a rebase. Except that every commit would have an additional parent pointer which cross-references it to the original branch. I.e. good rebase: B0---B1---B2 / --- A --- B ---- C --- D --- B0' --- B1' --- B2' good merge (exact same thing, just with parent pointers): ---------------B0-----B1-----B2 / \ \ \ --- A --- B ---- C --- D --- B0' --- B1' --- B2' --- typical silly git merge: --B0-----B1-----B2 / \ --- A --- B ---- C --- D --- B{0+1+2} still, that cross-referencing parent info in the second example above is not that useful. It's still making a salad out of the git graph. And is not two-way navigable, either. (Say I'm looking at B1 and want to locate B1'.) It's better to have something in the commit messages to track changes that get cherry picked in multiple places. The Gerrit review system has a Change-ID: line with a 160 bit random ID, for instance. All rebases/picks of the same change carry the same ID, which correlates them to the same review item.
  - kazinator 7y ago
    I can't make sense out of your comment. The concept of "git bisect" is inherently predicated on a simple linear history consisting of commits that were applied on top of each other. We are searching for the bad one which flips the test case from "good" to "bad". If you throw an ugly graph into it and merges, it's not even comprehensible. Say that instead of git bisect we just go backwards, commit by commit, starting at HEAD. Oops, we encounter a merge commit: which way do we go now to find the breakage? Parent[0], or parent[1]? Or [2] ...? What is the correct traversal order? Do we go down [0] first? At which commit do we backtrack and try going into [1]? There is absolutely no issue with git bisect over a repository where you have the unmodified upstream commits, and your own local ones rebased on top of them. It nicely finds the bad commit in one or the other. Now of course the rebase rewrites your code by merging it (in the real sense of the word). If you discovered the bug yesterday (and it's in your own commits), then you rebased this morning, you're now chasing that bug over different commits that have been subject to auto-merge and maybe even manual conflict resolution. Oh well; yesterday was yesterday! Repro the bug with the newly rebased repo and bisect away. Or, here is an idea: if you're chasing a bug, don't fetch anything and don't rebase! Right? If you've repro-d a bug, you don't want to start changing code, so the last thing you want is to bring in reams of changes from other developers. I've never rebased while chasing a bug with git bisect; I stopped what I was doing until I found it, in the nice linear history as it existed at that point. If external forces cause you to drop what you're doing and rebase while you have some bug, what you can always do is "git tag bug-hunt" to set a bookmark where you were. Do what you have to do, and then when you pop your stack, return to that tag and debug from there. You can find the original bad commit. If it's in your uncommitted work, you can cross-ref it to the latest rebase. (There is a chance it might not exist any more; e.g. upstream changes made some of your local code obsolete, so you threw them away in the rebase, and the problem was in those discarded changes.)
    - anon9001 7y ago
      If you have a long running branch, you're going to have conflicts. When you resolve those conflicts during a rebase, you lose your history of the conflict resolution. What you're thinking of as a "simple linear history" is actually not. Notice that when you rebase there are new hashes for each of your commits. If you're rebasing your branch with master and resolving merge conflicts along the way, you're going to get bit eventually. Even if you're somehow not dealing with merge conflicts, you're losing your ability to look at the git log and figure out when the last time you synced up with master was.
- kazinator 7y ago
  I did that until about 9 years ago. It was too annoying and error-prone (due to forgetting to set that up in new environments, or in some cases not being able to, like in some build machine account or whatever). Instead I simply learned not to use git pull. I always pick up new changes with git fetch, followed by git rebase. Just purely out of computer science principle, I want to avoid commands that bundle multiple unrelated operations and behave differently based on magic globals. If I notice upstream has been forced (shouldn't happen in any well-run public repos), I tread carefully. Instead of just a git rebase, I will do something like git rebase HEAD~3 --onto origin/master. (If 3 of the top commits are my local ones.) That tries to transplant the 3 commits onto the new material coming from the remote. Basically, reset to the remote, then cherry-pick my commits.
rinchik 7y ago
Rebase isn't really a trick though.. is it? It just a normal workflow and, sometimes, housekeeping in your small "feature" branch.
- rumanator 7y ago
  Rebase os also a good way to wreack havoc in a repository, both local and remote.
  - chopin 7y ago
    Not in remote if you disallow force-push. For local I agree. For hairy rebases I normally set a marker tag (easier than to comb through the reflog). Then it is easy to reset the branch to its initial irrespective of what you've done.
    - mcv 7y ago
      Quite the opposite, sometimes rebasing means you need to force-push, and not doing so wreaks havoc. Imagine I'm working on my own feature branch, pushing regularly to remote. I make my pull request to develop, but develop is ahead of me and my pull request can't be merged. So I pull develop, rebase my own local commits on top of that, and push the result in my feature branch to remote, which contains some of my old, un-rebased commits. The push is refused, and instead either git or intelliJ automatically pulls from the remote feature branch into my local branch, merging with no problem, so it can be pushed again. It works, but not all my commits occur two times in the history, and that's bad. I suspect it's not git doing this but IntelliJ, but it's a popular IDE, so this can easily happen to anyone if you're accidentally rebasing commits you already pushed. Force pushing prevents the problem, but you're probably better off not rebasing in the first place. Don't change history that also exists in another location.
      - deleted 7y ago
        [deleted]
kirke 7y ago
Another excellent resource on a similar vein: https://git-rebase.io/ https://git-rebase.io/ Written by Drew Devault, author/maintainer of swaywm, sourcehut and others.
sam36 7y ago
Any good git "best practices" doc will inform the user to never use rebase on a shared remote repo. The details are given, but sadly I can never really follow the logic. Rebase always sounds like a good idea (imo). And being the only one to use rebase on my team... I've had several instances where I go to rebase a remote branch onto my local work, and I'm met with tons of conflicts.. except the conflicts are all my own commits from a later time. I've never really figured out why, but I've since just stopped using rebase unless I really know there is nothing funny on the remote branch.
- danzanzini 7y ago
  The conflicts from a later time happens because rebase applies one commit at a time. If you solve a conflict from your first commit by applying changes that were made only in the later ones, you'll need to solve this same conflict again and again.
  - sixstringtheory 7y ago
    If resolving the same conflicts over and over again in many commits gets onerous enough to make it worthwhile investing a little time learning another part of git, you can check out git-rerere (Reuse recorded resolution): https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere
    - sam36 7y ago
      What the heck
- mcv 7y ago
  Rebase should not be done on a large history. Merge long histories, only rebase short ones. Long histories are probably useful to see separately in the git history anyway, and it's only for a history of one or two commits that the extra merge commits begin to dominate the real commits in your history. When in doubt, just merge. It's always safer.
lazulicurio 7y ago
Personally, I prefer to never use git pull, and instead use git fetch then manually merge or rebase as appropriate. It's one more command, but I find it helps me visualize exactly what I want to happen.
- rinchik 7y ago
  > It's one more command, but I find it helps me visualize exactly what I want to happen are you saying that git pull can produce some unwanted artifacts? (e.g. not do exactly what you want it to do?)
  - lazulicurio 7y ago
    > are you saying that git pull can produce some unwanted artifacts? (e.g. not do exactly what you want it to do?) Not in the sense that git pull has unpredictable behavior, but I like being able to view the remote history and manually diff against my local branch if there are changes that have been made.
    - jolmg 7y ago
      Though it's still better to do fetch when you want to compare first, pull outputs the ranges of commits that it's pulling for each branch, so you can just copy and paste that into a diff or log command, too. I say this because I used to just ignore the output, but then I found that it's useful, too. So, if git-pull outputs b3b2007..9bad624 master -> origin/master I can do `git diff b3b2007..9bad624` or `git log b3b2007..9bad624` to see what I just pulled.
  - juped 7y ago
    Depends on your mental model. I think people expect something similar to CVS update at first, and then git surprises them by doing other things.
    - rinchik 7y ago
      I don't think git can surprise though... git GUIs on the other hand can be a mystery.
languagehacker 7y ago
I like how straightforward this blog post is. The graphics are very helpful in getting the point across. Unfortunately, this is dangerous advice in a reasonably sized engineering team. The assumption of pushing to master is kind of a dangerous one. Don't do that unless it's a project that is yours and yours alone. If you have a change you want to get in, consider a pull request. Even if you don't need it reviewed, it generally encourages you to use a separate branch. If you find that you have a conflict with origin/master, you can then easily rebase your changes. Because of the nature of refs in git, you can also create a separate branch before rebasing so that you don't have to worry about about losing anything, or just to diff what you ended up changing after a particularly hairy rebase. So yes in short, you can use rebases to avoid merge commits. But the use case here and the workflow described is not one I would recommend for teams using a centralized origin or a stable head of master.
- harg 7y ago
  I didn't get the impression the article assumed pushing to master. It was more a case of you're working on a feature branch and another dev pushes to that same feature branch before you push your local commits. I agree that even in larger teams you shouldn't face this problem in the first place if devs work just on their own branches instead of sharing. Rebasing is also a great way way to avoid merge commits.
darepublic 7y ago
This is not a guarantee of no merge conflicts. Sometimes conflict cannot be avoided, you'll need to deal with it sooner or later
- gordaco 7y ago
  And depending on your commits, you may need to solve conflicts several times (rerere alleviates this, though). Also, isn't this very basic? I thought pull --rebase was one of the most basic commands everyone learned while getting acquainted with git.
  - ghshephard 7y ago
    I started using git two years ago, and when I first asked all our senior engineers about it (after reading an article or two on HN about best practices) - the advice I was given was, "Never rebase." Among the more Jr. Engineers there was this feeling that it was a dangerous command that should be steered clear of, and the typical approach, of branching off of remote master, making changes, pushing to your branch, testing your code in the CI/CD environment (with appropriate unit/integration tests), and then issuing a PR to be reviewed and merged into master was the appropriate use of git. I don't think I've ever seen anybody (except very advanced git users) ever use "rebase" - so, no, I don't think I would consider it a basic command. Despite using git dozens of times every day, I don't believe I've ever rebased outside of a test-environment to see how it worked.
    - cyphar 7y ago
      It's a bit frustrating that the whole "never rebase" thing has become a cargo cult -- because it's only correct in specific circumstances (thus it's completely wrong to say "never"). The reason why the Linux kernel has a no-rebase policy for maintainer trees is that thousands of developers base their work on the maintainer trees. Developers are constantly rebasing their work (either to update to the latest development branch by a maintainer, or to restructure and modify their commits with "git rebase -i"). Thus, rebasing maintainer trees would result in many developers having to deal with frustrating issues when they rebase (they have to curate which commits the maintainer has removed to keep with "git rebase -i"). It addition, maintainer trees get tested automatically and rebasing a tree invalidates all of the previous testing (so if you ask Linus to pull from you and the tree was just rebased, you're sending untested code and will get shouted at). Yes, you should never rebase master -- because there is guaranteed to be more than one user of master. But rebasing (for developers working on a feature) should be a very familiar thing to do -- unless you're working on a feature branch with someone else.
thiht 7y ago
Rebase is not a "trick", it's one of the basic features of git. If you consider it's a trick, please don't use it, it means you don't understand it yet.
- fcfl 7y ago
  By that logic there are no tricks, there are only ever features, basic or otherwise. If you consider sticking so much to literality, please don't use languages, it means you don't understand them yet.
mcv 7y ago
`git rebase` is fairly useful when differences are small. Rebase changes the history of your own commits. When that history is long (you've got a lot of commits that are not in the other branch), you'll end up resolving the same conflicts over and over and over again, and in that case, a simple merge is much less painful. The only real advantage of rebasing is that it keeps your history linear. A history with merges is harder to navigate. But at some point, merges become unavoidable, and the larger the differences are, the more important it becomes to use merge instead of rebase. And as any time traveler knows, changing history comes with risks.

59 points by danzanzini 7y ago

And git config --global branch.autoSetupRebase always will ensure that all your future branches are automatically setup to `rebase` instead of `merge` on pull.

anon9001 7y ago
You should want those merges so that you can later bisect where a problem was introduced. If you start/end each day with a merge and leave the merge commits in, and you notice something goes wrong later, it's much easier to trace where the problem is. Rebase definitely satisfies my OCD and makes everything look pretty, but it's actually worse.
- Benjammer 7y ago
  >you notice something goes wrong later, What, specifically, do you mean by "something goes wrong later"? Like a full outage of some kind? A production bug? A mistake according to the design spec? A failed test in CI? A failed human QA validation? What are we talking about here? >it's much easier to trace where the problem is. Furthermore, why would the git commit structure have anything to do with debugging any type of issue, regardless? Isn't debugging mostly comprised of combing through logs, adding random print statements to console output, and using an IDE debugger? Or some kind of more advanced tracing/profiling tools? Are you debugging by hunting in commit histories and Jira tickets or something? Or are you talking about blaming, not "tracing where the problem is", but "tracing who the problem is"?
  - anon9001 7y ago
    This post explains it better than I can in a comment: https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1 https://medium.com/@fredrikmorken/why-you-should-stop-using-...
    - kazinator 7y ago
      That article is some FUD about a real bug in a feature branch being masked due to other bugs that were introduced by the rebase itself. That is not realistic because, firstly, a very specific test can (and should) be used for git bisect. You're not just testing for "software fails", but "very specific case fails in a specific way". If some intermediate issues prevent you from testing the specific test case (you're not able to call "good" or "bad"), you can tell git bisect to skip that commit. Shit happens! Bug was introduced a month ago, but two weeks ago, a range of commits happened that don't even build in your environment. git bisect will hit that. The article also glosses over the possibility that git bisect goes back farther than the bad commit. Commits that are not testable can occur earlier or later than the one we are looking for. Basically the article is just a new version of the old meme "merging is dangerous". except that it doesn't make any sense, since both "git merge" and "git rebase" textually merge code.
    - sixstringtheory 7y ago
      I think the best point of this article is accidentally introducing breakages into history that later defeat the purpose of git-bisect. However, in practice I haven't run into this problem, at least not in an insurmountable way. One solution is, if you can run your tests with e.g. `make test`, you can run `git rebase --exec "make test"` which will run your test suite against every commit being rebased. I've only done it a handful of times, and because of how long it takes I'd only run it after finishing a rebase that wound up needing resolutions, instead of doing it up front and having to wait for the tests to finish at each commit before potentially resolving another upcoming conflict. If you are very paranoid about breaking commits being pushed, disallowing rebase isn't enough: any dev could simply write a commit with a breakage. You'd have to set up pre-commit hooks to run your tests, or a pre-push hook to run `git rebase --exec "make test"`. TIL there is also a post-rewrite hook, which sounds like it solves exactly your worry with rebase, but as I mentioned, introduces long delays between rebase commits/resolutions–I'd probably forget what I was doing during each test run, haha.
      - anon9001 7y ago
        It can definitely be made workable, but why do so much in pursuit of a slightly neater git log? I place a much higher value on the hashes of my commits not changing than having extra merge commits.
- bob1029 7y ago
  We have been struggling between the merge/rebase approaches with no clear winner in our minds so far. In principle the rebase seems to be superior, but I can certainly see arguments for using merge if it satisfies downstream concerns like traceability (I am still not clear on this stated benefit). Perhaps someone has a list of criteria that can help you pick between the 2 approaches, or perhaps both merge/rebase are valid at all times, but there is a certain set of rules to evaluate when choosing which to use?
  - kazinator 7y ago
    rebase has good traceability, if you retain the original artifacts. When we rebase a public feature branch and merge it into a mainline, we nicely have two versions of that. Basically, rebase and merge could be reconciled like this: we could merge a feature branch by iterating over it, and invidiually doing a git merge for every commit. Then that would be a rebase. Except that every commit would have an additional parent pointer which cross-references it to the original branch. I.e. good rebase: B0---B1---B2 / --- A --- B ---- C --- D --- B0' --- B1' --- B2' good merge (exact same thing, just with parent pointers): ---------------B0-----B1-----B2 / \ \ \ --- A --- B ---- C --- D --- B0' --- B1' --- B2' --- typical silly git merge: --B0-----B1-----B2 / \ --- A --- B ---- C --- D --- B{0+1+2} still, that cross-referencing parent info in the second example above is not that useful. It's still making a salad out of the git graph. And is not two-way navigable, either. (Say I'm looking at B1 and want to locate B1'.) It's better to have something in the commit messages to track changes that get cherry picked in multiple places. The Gerrit review system has a Change-ID: line with a 160 bit random ID, for instance. All rebases/picks of the same change carry the same ID, which correlates them to the same review item.
- kazinator 7y ago
  I can't make sense out of your comment. The concept of "git bisect" is inherently predicated on a simple linear history consisting of commits that were applied on top of each other. We are searching for the bad one which flips the test case from "good" to "bad". If you throw an ugly graph into it and merges, it's not even comprehensible. Say that instead of git bisect we just go backwards, commit by commit, starting at HEAD. Oops, we encounter a merge commit: which way do we go now to find the breakage? Parent[0], or parent[1]? Or [2] ...? What is the correct traversal order? Do we go down [0] first? At which commit do we backtrack and try going into [1]? There is absolutely no issue with git bisect over a repository where you have the unmodified upstream commits, and your own local ones rebased on top of them. It nicely finds the bad commit in one or the other. Now of course the rebase rewrites your code by merging it (in the real sense of the word). If you discovered the bug yesterday (and it's in your own commits), then you rebased this morning, you're now chasing that bug over different commits that have been subject to auto-merge and maybe even manual conflict resolution. Oh well; yesterday was yesterday! Repro the bug with the newly rebased repo and bisect away. Or, here is an idea: if you're chasing a bug, don't fetch anything and don't rebase! Right? If you've repro-d a bug, you don't want to start changing code, so the last thing you want is to bring in reams of changes from other developers. I've never rebased while chasing a bug with git bisect; I stopped what I was doing until I found it, in the nice linear history as it existed at that point. If external forces cause you to drop what you're doing and rebase while you have some bug, what you can always do is "git tag bug-hunt" to set a bookmark where you were. Do what you have to do, and then when you pop your stack, return to that tag and debug from there. You can find the original bad commit. If it's in your uncommitted work, you can cross-ref it to the latest rebase. (There is a chance it might not exist any more; e.g. upstream changes made some of your local code obsolete, so you threw them away in the rebase, and the problem was in those discarded changes.)
  - anon9001 7y ago
    If you have a long running branch, you're going to have conflicts. When you resolve those conflicts during a rebase, you lose your history of the conflict resolution. What you're thinking of as a "simple linear history" is actually not. Notice that when you rebase there are new hashes for each of your commits. If you're rebasing your branch with master and resolving merge conflicts along the way, you're going to get bit eventually. Even if you're somehow not dealing with merge conflicts, you're losing your ability to look at the git log and figure out when the last time you synced up with master was.
kazinator 7y ago
I did that until about 9 years ago. It was too annoying and error-prone (due to forgetting to set that up in new environments, or in some cases not being able to, like in some build machine account or whatever). Instead I simply learned not to use git pull. I always pick up new changes with git fetch, followed by git rebase. Just purely out of computer science principle, I want to avoid commands that bundle multiple unrelated operations and behave differently based on magic globals. If I notice upstream has been forced (shouldn't happen in any well-run public repos), I tread carefully. Instead of just a git rebase, I will do something like git rebase HEAD~3 --onto origin/master. (If 3 of the top commits are my local ones.) That tries to transplant the 3 commits onto the new material coming from the remote. Basically, reset to the remote, then cherry-pick my commits.

rinchik 7y ago

Rebase isn't really a trick though.. is it? It just a normal workflow and, sometimes, housekeeping in your small "feature" branch.

rumanator 7y ago
Rebase os also a good way to wreack havoc in a repository, both local and remote.
- chopin 7y ago
  Not in remote if you disallow force-push. For local I agree. For hairy rebases I normally set a marker tag (easier than to comb through the reflog). Then it is easy to reset the branch to its initial irrespective of what you've done.
  - mcv 7y ago
    Quite the opposite, sometimes rebasing means you need to force-push, and not doing so wreaks havoc. Imagine I'm working on my own feature branch, pushing regularly to remote. I make my pull request to develop, but develop is ahead of me and my pull request can't be merged. So I pull develop, rebase my own local commits on top of that, and push the result in my feature branch to remote, which contains some of my old, un-rebased commits. The push is refused, and instead either git or intelliJ automatically pulls from the remote feature branch into my local branch, merging with no problem, so it can be pushed again. It works, but not all my commits occur two times in the history, and that's bad. I suspect it's not git doing this but IntelliJ, but it's a popular IDE, so this can easily happen to anyone if you're accidentally rebasing commits you already pushed. Force pushing prevents the problem, but you're probably better off not rebasing in the first place. Don't change history that also exists in another location.
    - deleted 7y ago
      [deleted]

kirke 7y ago

Another excellent resource on a similar vein: https://git-rebase.io/ https://git-rebase.io/ Written by Drew Devault, author/maintainer of swaywm, sourcehut and others.

sam36 7y ago

Any good git "best practices" doc will inform the user to never use rebase on a shared remote repo. The details are given, but sadly I can never really follow the logic. Rebase always sounds like a good idea (imo). And being the only one to use rebase on my team... I've had several instances where I go to rebase a remote branch onto my local work, and I'm met with tons of conflicts.. except the conflicts are all my own commits from a later time. I've never really figured out why, but I've since just stopped using rebase unless I really know there is nothing funny on the remote branch.

danzanzini 7y ago
The conflicts from a later time happens because rebase applies one commit at a time. If you solve a conflict from your first commit by applying changes that were made only in the later ones, you'll need to solve this same conflict again and again.
- sixstringtheory 7y ago
  If resolving the same conflicts over and over again in many commits gets onerous enough to make it worthwhile investing a little time learning another part of git, you can check out git-rerere (Reuse recorded resolution): https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere
  - sam36 7y ago
    What the heck
mcv 7y ago
Rebase should not be done on a large history. Merge long histories, only rebase short ones. Long histories are probably useful to see separately in the git history anyway, and it's only for a history of one or two commits that the extra merge commits begin to dominate the real commits in your history. When in doubt, just merge. It's always safer.

lazulicurio 7y ago

Personally, I prefer to never use git pull, and instead use git fetch then manually merge or rebase as appropriate. It's one more command, but I find it helps me visualize exactly what I want to happen.

rinchik 7y ago
> It's one more command, but I find it helps me visualize exactly what I want to happen are you saying that git pull can produce some unwanted artifacts? (e.g. not do exactly what you want it to do?)
- lazulicurio 7y ago
  > are you saying that git pull can produce some unwanted artifacts? (e.g. not do exactly what you want it to do?) Not in the sense that git pull has unpredictable behavior, but I like being able to view the remote history and manually diff against my local branch if there are changes that have been made.
  - jolmg 7y ago
    Though it's still better to do fetch when you want to compare first, pull outputs the ranges of commits that it's pulling for each branch, so you can just copy and paste that into a diff or log command, too. I say this because I used to just ignore the output, but then I found that it's useful, too. So, if git-pull outputs b3b2007..9bad624 master -> origin/master I can do `git diff b3b2007..9bad624` or `git log b3b2007..9bad624` to see what I just pulled.
- juped 7y ago
  Depends on your mental model. I think people expect something similar to CVS update at first, and then git surprises them by doing other things.
  - rinchik 7y ago
    I don't think git can surprise though... git GUIs on the other hand can be a mystery.

languagehacker 7y ago

I like how straightforward this blog post is. The graphics are very helpful in getting the point across. Unfortunately, this is dangerous advice in a reasonably sized engineering team. The assumption of pushing to master is kind of a dangerous one. Don't do that unless it's a project that is yours and yours alone. If you have a change you want to get in, consider a pull request. Even if you don't need it reviewed, it generally encourages you to use a separate branch. If you find that you have a conflict with origin/master, you can then easily rebase your changes. Because of the nature of refs in git, you can also create a separate branch before rebasing so that you don't have to worry about about losing anything, or just to diff what you ended up changing after a particularly hairy rebase. So yes in short, you can use rebases to avoid merge commits. But the use case here and the workflow described is not one I would recommend for teams using a centralized origin or a stable head of master.

harg 7y ago
I didn't get the impression the article assumed pushing to master. It was more a case of you're working on a feature branch and another dev pushes to that same feature branch before you push your local commits. I agree that even in larger teams you shouldn't face this problem in the first place if devs work just on their own branches instead of sharing. Rebasing is also a great way way to avoid merge commits.

darepublic 7y ago

This is not a guarantee of no merge conflicts. Sometimes conflict cannot be avoided, you'll need to deal with it sooner or later

gordaco 7y ago
And depending on your commits, you may need to solve conflicts several times (rerere alleviates this, though). Also, isn't this very basic? I thought pull --rebase was one of the most basic commands everyone learned while getting acquainted with git.
- ghshephard 7y ago
  I started using git two years ago, and when I first asked all our senior engineers about it (after reading an article or two on HN about best practices) - the advice I was given was, "Never rebase." Among the more Jr. Engineers there was this feeling that it was a dangerous command that should be steered clear of, and the typical approach, of branching off of remote master, making changes, pushing to your branch, testing your code in the CI/CD environment (with appropriate unit/integration tests), and then issuing a PR to be reviewed and merged into master was the appropriate use of git. I don't think I've ever seen anybody (except very advanced git users) ever use "rebase" - so, no, I don't think I would consider it a basic command. Despite using git dozens of times every day, I don't believe I've ever rebased outside of a test-environment to see how it worked.
  - cyphar 7y ago
    It's a bit frustrating that the whole "never rebase" thing has become a cargo cult -- because it's only correct in specific circumstances (thus it's completely wrong to say "never"). The reason why the Linux kernel has a no-rebase policy for maintainer trees is that thousands of developers base their work on the maintainer trees. Developers are constantly rebasing their work (either to update to the latest development branch by a maintainer, or to restructure and modify their commits with "git rebase -i"). Thus, rebasing maintainer trees would result in many developers having to deal with frustrating issues when they rebase (they have to curate which commits the maintainer has removed to keep with "git rebase -i"). It addition, maintainer trees get tested automatically and rebasing a tree invalidates all of the previous testing (so if you ask Linus to pull from you and the tree was just rebased, you're sending untested code and will get shouted at). Yes, you should never rebase master -- because there is guaranteed to be more than one user of master. But rebasing (for developers working on a feature) should be a very familiar thing to do -- unless you're working on a feature branch with someone else.

thiht 7y ago

Rebase is not a "trick", it's one of the basic features of git. If you consider it's a trick, please don't use it, it means you don't understand it yet.

fcfl 7y ago
By that logic there are no tricks, there are only ever features, basic or otherwise. If you consider sticking so much to literality, please don't use languages, it means you don't understand them yet.

mcv 7y ago

`git rebase` is fairly useful when differences are small. Rebase changes the history of your own commits. When that history is long (you've got a lot of commits that are not in the other branch), you'll end up resolving the same conflicts over and over and over again, and in that case, a simple merge is much less painful. The only real advantage of rebasing is that it keeps your history linear. A history with merges is harder to navigate. But at some point, merges become unavoidable, and the larger the differences are, the more important it becomes to use merge instead of rebase. And as any time traveler knows, changing history comes with risks.