The place I work at does the following:
We are asked to manually copy paste the code from one version to another. What are the circumstances under which git branches are considered harmful?(we all add code to master)
Branches can be hard to understand for people who are not used to them, and can be tricky to explain to managers if you need to avoid saying things like "different versions". To a manager who is using a mental model based on clean division of labour and a waterfall process, the idea that you would even want to permit more than one person to work on a file at a time is bad, let alone having a tool that's designed to encourage it.
A further problem is that manual merging can be problematic, and manual deployment more so. It only takes one mistake in a new process to push some people back to the familiar one. You might be better off first automating the existing process as much as possible, then later merging the repositories.
I've found that programmers who are used to older tools have often experienced considerable trauma with branch/merge operations. This is especially true for users of the misnamed "Visual Source Safe" where merging was difficult to impossible and in some versions of that tool used to be a really effective way to corrupt the database. But even the better tools often struggled to deal well with concurrent changes to single files (people often struggle too, which is one reason for the move to smaller units of code over time).
For those programmers I suggest first getting them to use git, which you seem to have done, and ideally one of the pretty GUI front ends for it. The pretty front ends usually present things in a fairly familiar way. Once you have that you can show them how you use branches on your local machine to manage workflow. Specifically, that they're easy to understand and that merging is 90% trivial. I've had some success moving developers this way.
I work in an office thats taken over 2 years (and still counting) to move to a Git/Branch workflow model from an RCS based config management tool. i.e. Git with gerrit was installed 2 years ago, yet releases and half the team still use the old tool. The old tool was a state of the art configuration management tool in 1994, and has features that Git/Gerrit do not provide, but branch based revision control is not its strength and manual copy/paste is how branches are managed.
The guys who have used this tool for 20 years have no awareness of the benefits of properly managed branches and merging, and strongly believe if you do not make every source change by typing it in yourself at a keyboard it cannot possibly be correct.
Another problem with branches also happens when code branches diverge to the point that they are no longer the same code base. This often happens in the above scenario as keeping everthing in sync is hard - if a change is not needed in one repo, the manual effort to merge it is seen as a waste of time. Do this a few times over a few years, and automatic merging becomes more difficult to manage than manual merging.
Some simple things for a person to resolve are impossible to automate. As the merges were not automated, no understanding or disipline exists around these things, and automatic branch merging usually fails. A couple of difficult merge conflicts reinforces the mindset that its not reliable. Code layout changes are a really good example, as are changing tabs to white space and training white space changes in files - things a person does not see or care about, that stop a merge dead in its tracks. Refactoring while making a one line defect fix, or worse - doing multiple unrelated changes in one commit - its easy for a person to tell which bits are needed, but a merge tool cannot.
No amount of technical training or refering to current best practice will change their belief system. Until they move over and start using branching, they will not be comfortable with it. Hence a catch 22. They won't move because the are not confident in it, they won't become confident until the move.
Putting it bluntly, most of the circumstances that branches are considered harmful is when dinasours who are not prepared to change and have never used it are in control.
To answer your question: This seems to be the most brain dead process using git. The whole point of using git is because of easy branching and merging. Manually copying / pasting changes is just asking for trouble, because some day someone will forget to copy something and you will have no track of who did that.
My previous company had a manual copy/paste code deployment process. Everyone loved it except the Release Engineers. It wasn't changed until an accident wiped out several days worth of work and restoring from backup wasn't an option.
Using a version control tool with proper branches was an easy sell after that.
If you can demonstrate to your management that it is more cost effective and less risky to use branches properly, the "branches are evil" mantra should begin to dissipate.
tldr: Saving Money > Branches Are Evil
The people are afraid of things that they don't understand, this is why they think branch are evil.
The problem its that decide about the version control politics of a company without understanding branching its... well, not very professional.
You are using a very similar approach that the one that the tool git-flow (https://github.com/nvie/gitflow) propose with dev/production branches, the good thing about this tool is that its very, very easy to use and define a rigid but very easy to understand branching model. Can be a very good way to introduce the proper use of git to people new to the tool.
I've been faced with a couple of hard speed bumps that I've been surprised by:
1) having to using git from the command line (I've always been lucky & lazy enough to run it through one GUI or another :P)
2) a shop where the development flow relies heavily on rebasing instead of merging.
After stubbing my toes a bunch of times, I finally whipped up a "git cookbook" that I use to keep track of how I need to do each process I commonly run through, and a few of the recovery steps when something goes whacky. That's been really helpful for me.
It's also helped me to identify the steps that are "easy", and the steps that are good to know, but "hard" or "dangerous" (like "checkout --" or "push -f", which can result in code loss.)
Also -- and this goes to your question -- getting the mental model right, and branching it adds a layer of complication. So there are local changes, staged changes, changes committed locally, and changes in the origin repository. And figuring out where your changes are currently can be kind of baffling. The messages git provides can be very obscure, and sometimes there's inconsistent syntax in how you specify source and branch.
So it's like any other adaptation, or mal-adaption: the current shop has figured out how to make an extremely bad process work, but easing the learning curve and moving to best practices will largely be a matter of helping make the learning curve less steep, and the downside of learning less risky.
