The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Strange. Nothing of theat kind happens on my Linux boxes...
Rule #1: If you want to sell something, don't get let your paying customers jump through all kinds of hoops, like licensing or updates. I don't want you to tell me what we are going to do today, I don't want a Mickeysoft account or mail address, I don't give a damn when something has not been activated or a license has gone 'stale'.
It's only the pirates who are spared all this, thickskulls.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
I am not a game player, but I understand even games are a lot more buggy now, and depend on updates to fix their bugs instead of thorough testing.
I remember that Microsoft use to have a lot of writers that were working on documentation, which was nice. Then when .net came out they had already gotten rid of them all, and so we got .net and an absolute minimum of documentation. When Microsoft finally got around to having a Wiki, it would not allow the public to update, and the documentation, as it is today is so bad. Now if you do a search for software help and you see it is a Microsoft site, you look at the next hit.
It appears that thorough testing is now considered optional by software developers...let the users find the bugs, and then fix them if you can reproduce them...or maybe not.
When using git, there is no reason not to branch. Besides, I commit every 15 minutes or so while working, so can't just stash (git equiv. to shelve) and work on something else. Just make a branch (takes about 10 seconds or less) and fix it there. Merging is generally not an issue in git (I have only had one merge conflict in the last month on a team of 7 devs and used to have many in TFS).
Merge conflicts usually only occur if the same file was worked on by more than one person, prior to check in/merge. We do our best not to let this happen, and "that" is what controls merge conflicts, not the software.
If you like to manually control merge conflicts, that's great, but I would rather let the software be better at merging and only get involved when there is truly a bad conflict. There are always certain files that are frequently modified (configuration files, common UI, etc.) and if your software can intelligently merge the code for you, then I welcome it. I have used almost every source control software out there in my 30+ years of development (some of them as a build automation engineer) and git gives a better development experience than most (ok, I prefer Mercurial, but the industry chose git and I use github for collaboration on my private projects).
I've actually had that situation and resolved it relatively easily with Git.
I think Git makes that very easy using the git checkout command. I'm sure you know that already, but it is quite amazing how you can switch branches in Git so easy.
Much easier than Subversion where I would often start working on the change, only to remember later I needed to branch first.
You're checking out the branch, I don't see the issue with the name? Not that it's an amazing name, many non-Microsoft names do leave a lot to be desired ("Blame" springs to mind), but it's not the worst name either.