This is all nice and dandy (as usual with git tutorials, which I find to focus on what works great), but what about a long-lived feature branch where you need t

This is all nice and dandy (as usual with git tutorials, which I find to focus on what works great), but what about a long-lived feature branch where you need to get the changes from your master branch into your feature branch on a regular basis? Are you going to merge master into your branch? Are you going to rebase? Whatever choice you make, it's going to be kind of sucky experience, awful merges or a long series of resolving conflicts for each commit replayed on top of the HEAD of your main branch, with random git rebase --skip and "conflicted" files that you edit only to discover that the file actually doesn't contain any conflict. What about the famous: + EMPTY_LINE - EMPTY_LINE That for some reason I still get every other day in git diff outputs? What about deleting a branch? Tough shit son, the branch is not fully merged, BOOYA! Want to pull? BANG, merge bubble. Oh, you decided to be smart about it and to git pull --rebase instead? Nah sister, you've pushed that code before and you're now rewriting the history and screwing with it. I don't know, it feels like there are no good choices in git, there's no "right way", there's no workflow that guarantees your peace of mind. It's always a fight. And the solutions to those problems are something that I never see in the git tutorials and examples. It feels like informercials, you really want to buy into it and go create branches, engage into interactive rebases and git bisect into nasty bugs but after a few shots at it, it becomes the software equivalent of that exercise bike collecting dust in the basement you pretend not to see on your way to the backup fridge. The one that reminds you how much you suck. (Most of this tongue in cheek, I think git is great, it's just frustrating sometimes)