Learn More
Resend Email
5
GhostDev
5y

So I thought I knew source tree, apparently I do not... Lost a week's worth of work, went to history, saw someone removed it with a commit, and now I'm getting blamed for my own work 'disappearing'. The reason I am being told I am to blame is how I control my branches... So how I do it is that I keep a local copy of the master branch, I keep it updated and monitor it for changes regularly (meaning fetch and pull cause double tap..) before I do a merge, I check for any new code on master again, then using the local copy of master, which I just updated, I pull the master changes into my branch, deal with any conflicts, build and done. Then I request my changes into master once I am happy everything is good.

My question is, clearly there is something wrong with the way I do things, so please source tree users, what is the most fool proof way to pull latest from master so that I don't loose code? 😔

question

git gud

source tree
Favorite
Ranter
Comments
  • 3
    5y
    Never pull another branch into your own and rebase your branch onto master instead.
  • 1
    5y
    @Commodore Why?
  • 0
    5y
    @jespersh I did not. I am familiar with the stash issue... Now also being told that using terminal in source tree is wrong... Think I need to read the documentation again... Clearly missed something
  • 1
    5y
    @Commodore rebase? Okay, I can look into that... And what the differences are and incorporate that into things...
  • 1
    5y
    Rebases should be done with great care. As someone once said: "each rebase is a lie".
  • 1
    5y
    Well, it all depends on what your branch represents.

    I try to have a branch per feature which means that they'll be short lived and dedicated to a specific task. Thus, I expect my branch to only hold changes related to the feature and that the actual timestamp of a commit matters less than the sequence or the date the feature gets merged.

    When you do a rebase, you're basically replaying each commit of your branch but from another starting point.

    While this is indeed rewriting history this is also discarding information that doesn't matter in profit of a readable commit history.
  • 0
    5y
    I don't get it. You lost your work because of someone else's commit and you're getting blamed? I find your branching style a little perplexing but if you have pushed your changes then they were lost, you are not to be blamed here.
  • 0
    5y
    Orphan child commits bro, its reclaimable until the garbage collector clears it
  • 1
    5y
    @swablu if you like a visualisation tool I'd recommend smartgit
  • 1
    5y
    @dr-ant kinda how I feel too.. But I'm willing to hear if there is a better way for me to skin the cat. Personal preference is a pain, so I thought it worth it to ask the people here and find out a bit more so I can get my facts and all straight... Cause even being told to not use the terminal on source tree (to trigger kdiff merge) is wrong is making me wonder what I'm missing..😐
  • 2
    5y
    @GhostDev what @Commodore said.
    You have you local master always updated and a couple of local branches with your changes. When you feel ready to push changes of local branch A, update master, rebase on master from A, merge A into master, push master.
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment