•  dudinax   ( @dudinax@programming.dev ) 
    9•1 year ago

    Merge. One of the values of a VCS is to preserve history in detail, and merge is the only method that does that. Also, it’s easy to foul a remote branch with the other methods if someone has already pushed changes to branch 1.

    •  Ferk   ( @Ferk@kbin.social ) 
      2•1 year ago

      I feel it’s a balance. Each operation has a purpose.

      Rebasing makes sense when you are working in a feature branch together with other people so you rebase your own commits to keep the feature branch lean before you finally merge it into the main branch, instead of polluting the history with a hard to follow mess of sub branches for each person. Or when you yourself ended up needing to rewrite (or squash) some commits to clean up / reorganize related changes for the same feature. Or when you already committed something locally without realizing you were not on sync with the latest version of a remote branch you are working on and you don’t wanna have it as a 1-single-commit branch that has to be merged.

      Squashing with git merge --squash is also very situational… ideally you wouldn’t need it if your commits are not messy/tiny/redundant enough that combining them together makes it better.

  •  ulkesh   ( @ulkesh@beehaw.org ) English
    6•1 year ago

    And what this graphic fails to discuss is that all these methods should be done BEFORE pushing. Once pushed, then the hashes are set and if you do any squashing, fixuping, etc, then you are rewriting hashes (and history) — and possibly orphaning other developers local copy.

      •  ulkesh   ( @ulkesh@beehaw.org ) English
        3•1 year ago

        The moment you push your changes to origin, other developers can then pull them. If you intend to squash or fixup commits, then you should do so after committing to your local git, but before you push to origin.

        Once you push to origin, the commit hashes from your local branch become what origin has, and then those commit hashes are now possibly on another developer computer after they pull.

        If you do a squash or a fixup, the existing commits are effectively rewritten into a new commit with a new hash so the developers who happened to pull what you previously pushed now have their HEAD pointing to a hash that no longer exists — thus orphaning.

  •  amio   ( @amio@kbin.social ) 
    5•1 year ago

    I’ve tended to rebase before anything else. If I feel unsure about the massive interactive rebase fuckery I’m about to embark on, I just make another branch where I start. Then undoing it’s fairly trivial.

  •  linuxPIPEpower   ( @linuxPIPEpower@discuss.tchncs.de ) 
    2•1 year ago

    I was trying to learn this again last week. I just play around with this stuff for fun.

    If I want to consolidate all the commits into a a single message (to create a changelog sort of), which kind of merge do I use?

    Another question: I’m torn between wanting to keep a complete history of my work, for my own benefit, and not wanting anyone to see how messy and crappy everything is. I’ve been trying to work in one branch then merge only when a task is “complete”. But it’s a bit confusing for me especially if I leave a project for a while then come back to it. Especially especially if submodules are involved. Is there some sort of convention about how to do this? Or am I thinking about it wrong?

  •  jadero   ( @jadero@programming.dev ) 
    2•1 year ago

    I’m only just embarking on my git journey as a hobbyist. When programming was my career, I was a solo programmer and subversion was almost overkill.

    When I look at the diagram of “merge” I see what I would have thought to be perfection itself, not something pain inducing.

    As I said, I’m just getting started. Is there no tooling to make this graph painless and useful or is it left to mental visualisations?