Any git pros here? My limited git skills are failing me

Discussion in 'Tech Heads' started by Utumno, Sep 7, 2018.

  1. Utumno

    Utumno Administrator Staff Member

    Post Count:
    38,914
    I can do basic clone/pull/merge shit in git, and I can deal with your basic merge conflict. But my understanding really falls apart when it comes to more complex things (like rebasing and handling conflicts).

    Here is the scenario.

    Say you got your standard master branch in github, then you decide to do a staging branch for a bunch of changes you want to prep for an event in the future (let's assume that will happen in November).

    So you fork off master into a "staging" branch, you and a bunch of other devs are making to this staging branch happily for a couple weeks, and now the changes are pretty much in the final state that they need to be for November.

    However, you know for a fact that the master branch is evolving all the time, with little trivial changes. You want to periodically (say every few days), keep the staging branch relatively fresh, so come November, you're not trying to merge months of changes all at once and dealing with the inevitable conflicts.

    Now what I *think* I want to do in this case, is use git rebase, to make it seem like the most recent master changes happened before I forked.

    In my brain, this is how it looks when when I forked:

    upload_2018-9-7_13-14-3.png

    And this is how I want it to seem after I rebase each week:

    upload_2018-9-7_13-14-35.png


    I believe the commands to do this are: (assuming a branch called "feature")

    git fetch --all
    git checkout feature
    git rebase origin/master
    git add .
    git push origin feature (may need force flag here, not sure)

    But when I get to the rebase command, I get a merge conflict, because specific lines changed by the feature branch, conflict with changes made in commits C, D, and E. Fine, I have to resolve the merge conflict. However, when resolving the conflict, I don't know whether to keep the C/D/E changes, or the changes made in the feature branch (for purposes of the rebase).

    Does anyone know which set of changes (master or feature) to keep when resolving the confict? Does any of this make sense?
     
    Last edited: Sep 7, 2018
  2. Utumno

    Utumno Administrator Staff Member

    Post Count:
    38,914
    Well fuck. I tried this (keeping the "feature" branch changes as authoritative), then did the git rebase --continue - everything seemed to work fine after that.

    My latest push to github now has all the needed feature changes, as well as the master branch changes from the past few days. However, when I try to repeat the git rebase origin/master command, I now get more conflicts. FUUUUU
     
  3. Kilinitic

    Kilinitic 6,000 feet beyond man and time

    Post Count:
    15,960
  4. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    44,724
    rebase is evil

    avoid rebase yo
     
  5. Utumno

    Utumno Administrator Staff Member

    Post Count:
    38,914
    WELL THIS IS REALLY HELPFUL HOW ABOUT AN ALTERNATIVE SOLUTION????????????????


    (p.s. After the fact, I think I could have actually just did pull requests from master to feature branch and that would have accomplished the same thing w/nice clicky buttons on github?)
     
  6. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    44,724
    i think that would have made more sense

    or regularly merge branch changes into master (but not necessarily through pull requests)

    the major difference with rebase is that rebase changes the history to apparently be what you want to claim it was, and i think that's more dangerous than helpful unless you feel like the bruce lee of git
     
    Last edited: Sep 8, 2018
  7. Sifter

    Sifter TZT Addict

    Post Count:
    3,165
    Rebase is good for when you have a few crappy little commits in a staging branch, and you want to squash them into one clean, authoritative commit BEFORE merging or cherry-picking to master.
     
    Utumno likes this.
  8. Sifter

    Sifter TZT Addict

    Post Count:
    3,165
    Also Utumno you won't like this, but IMO this is a bad pattern. You should be trying to get small incremental changes from your feature branch merged into mainline as soon as possible, in order to avoid having to do shit like what you want to do.
     
  9. Utumno

    Utumno Administrator Staff Member

    Post Count:
    38,914
    This isn't a standard dev case though at all. This is a whopping set of DNS changes, that we wanted to work well ahead of time. A few weeks from now, we'll want those changes live, but in the meantime, little shit will trickle in, and I want to keep this "dev" branch (which is really just a staged uberset) fresh enough so we don't have an assload of conflicts the day of reckoning. The last time we did this, nobody thought to do this and it was a last minute scramble.

    That said, the rebasing thing was a bad pattern. I've instead been merging master into the staging branch every few days and it's worked rly well. I made it much more complicated than I need to Lol!
     
  10. AgelessDrifter

    AgelessDrifter TZT Neckbeard Lord

    Post Count:
    43,128
    All your rebase are belong to us
     
  11. Utumno

    Utumno Administrator Staff Member

    Post Count:
    38,914
    damn you went there
     
  12. Kilinitic

    Kilinitic 6,000 feet beyond man and time

    Post Count:
    15,960