3 ms·
> My experience talking to some Git people is that they often branch as a habit without considering what could be gained from branching. There's just never a r
by baseballdork 8y ago
> My experience talking to some Git people is that they often branch as a habit without considering what could be gained from branching.
There's just never a reason to not branch. It keeps ideas, efforts, tasks separated really nicely and has essentially no cost to doing so. It lets me have a completely different environment to try things out, wreck, and abandon things without ever touching the branches that are important. When I'm done, a simple merge brings it all in at once.
- btrettel 8y ago> It lets me have a completely different environment to try things out, wreck, and abandon things without ever touching the branches that are important. These are all completely valid reasons to branch. They also don't apply to most of my projects. And for the ones they do apply for, I use Git. My small projects tend to be relatively simple, and often contain a lot that's not code. (Some contain almost no code at all.) For example, I've had people recommend branching to keep track of different versions of the same paper they're writing. But this immediately struck me as a waste of time. I'll be submitting only one version of the paper. Why keep multiple internal versions? I am not convinced by the argument that I can have a branch for each person I ask to read the paper. Merging in the handwritten changes they provide me is not hard. Branching would just be extra work in this case. It can be nice to try different organizational structures sometimes, but I've found it easier to simply have a different TeX file in that case. (Or better yet, multiple TeX files for each part, and then a set of master TeX files that organize the paper differently.) If someone has a good argument for distributed version control in this use case, I'd be happy to hear it.