Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

The place I work at does the following:

  1. They manage a dev version of an app
  2. They manage another replicate version of that app, they call this the rep version
  3. The live version of the app that is running
  4. They believe branches are evil

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)

share|improve this question

marked as duplicate by gnat, GlenH7, MichaelT, Bart van Ingen Schenau, psr Jul 7 at 19:25

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1  
I think you forgot to put in your actual question :) –  metacubed Jul 3 at 23:01
10  
One of the upsides of git - even with a brain-dead process like that, you can keep your branches local and hide their existence before pushing ;) –  Izkata Jul 3 at 23:08
    
Are all the versions the same, except for time delays during testing, or are you picking and choosing parts to copy over? –  Karl Bielefeldt Jul 3 at 23:38
5  
Git branches can be considered harmful when you have a hook that detects branch usage and formats all the company's servers. –  Idan Arye Jul 4 at 1:31
1  
People coming to git from subversion might have the "branches are evil" mindset. They should let it go; git is not svn. –  Michael Hampton Jul 4 at 15:14

6 Answers 6

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.

share|improve this answer
    
This is why in situations where you have developers using merge/branch features, you insist on using Pull Requests for all merging of feature or bugfix branches into dev. You only allow the project manager(s) to authorize pull requests or initiate merging from dev to master. It can definitely be hard to get into that process mindset without training and consistency though. –  Derek Jul 4 at 7:03

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.

share|improve this answer
1  
Your answer is fairly helpful, but grammatically unclear. OP asked "When are git branches considered harmful", and your answer begins "This is a git process." You may want to be more explicit in the future --> "branches are not harmful in git". –  DougM Jul 4 at 4:57
    
When I have written my answer the question was "So it this process correct". You could have looked it up if you have seen that the question was edited after I have written my answer. So your comment is really out of place. –  ragol Jul 4 at 9:58
    
In order to consider it I had to be made aware of the change in question. But I do not sit in front of a computer 24/7, especially in the middle of the night. So your comment came way to late. Anyway, I think there is nothing more to be said here. I won't change my answer above because there are enough other answers already posted here. Good night. ;) –  ragol Jul 4 at 23:25
    
If you dont feel that your answer contributes, you may want to delete it. (And, fwiw, comments are for suggesting improvements, not discussion. I've deleted my chatty comment and encourage you to do the same.) –  DougM Jul 5 at 0:58

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.

share|improve this answer
    
should we autoformat reduces some of the hassle with merging. There is a code formatting standard, it's mechanically applied, therefore two copies of the same code must have identical format. –  Ӎσᶎ Jul 4 at 4:33
    
One benefit from merging is that you find places where a bug was only fixed in one branch, which can be hugely beneficial if both branches have been released. Where I work we have no "common" repository, just multiple copies of some files. Merging those fixed a number of significant issues. –  Ӎσᶎ Jul 4 at 4:34

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.