It was, historically, definitely a technical problem. You had to know what the base changelist for a branch was in order to integrate into it from trunk or to m

It was, historically, definitely a technical problem. You had to know what the base changelist for a branch was in order to integrate into it from trunk or to merge it back into trunk cleanly. I believe these problems may now have been fixed, but I haven't used svn in so long that I can't say for sure. Regardless, branching and merging in git were designed to be straightforward from the outset. Due to the nature of git's commit graph it is straightforward to tell (with appropriate tools, and this is somewhere that git suffered initially but has improved dramatically as its popularity has waxed) where in history a branch was created and which commits are being merged. If you want a branch and merge workflow where branches are used frequently and merges are the mechanism by which changes arrive in 'trunk' (which is basically how the Linux kernel is maintained with Linus being the final integrator -- he merges branches from what are effectively lieutenants who act as integrators for their respective subsystems) then git makes this workflow very straightforward.