Git splitting files procedures comparison


In one of the previous posts, I described the Git procedure used to split files with preserving history. I also mentioned that if this procedure is used with a branching strategy where feature branches are squash-merged to main branches, it won’t work. History will be gone no matter how we’d split the file.

This post is a short appendix with the comparison of the three methods of splitting files proposed by Raymond Chen. I examined all of them against a number of commits needed to correctly split the files and posted results here.

This time I don’t use a custom class as an example, but I’m just exactly following the procedure described by Raymond and showing the results.

Base method

Described here

Base method tree

Hard way with commit-tree

Described here

Hard way with commit-tree tree 🙂

Easy way with misleading commits

Described here

Easy way tree


As we can see, these three ways differ not so much. Most neat is the hard way, but it requires “plumbing”, which means that cannot be done via GUI tools and command-line + experience is needed. In turn, we get the smallest number of commits. The base method adds two more commits, “easy” method one additional commit.

My opinion is that if no special requirements are present, one should stick to the “easy method with misleading commits”. It’s a good tradeoff in terms of complexity and numbers of additional commits. Only experienced users should choose the most difficult procedure.


0 0 votes
Article Rating
Powiadom o
0 komentarzy
Inline Feedbacks
View all comments