Git Issues

In the my local javascript community here in Shanghai, a graphics made by Justin Hileman about git issues got topic for some discussions. In this post I quickly want to communicate my opinions on the subject. It is about, how do you go about a mess in git.

There are different types of a mess. First is, you got lots of changes in your projects files, but nothing is committed to git jet. There is a very good proposal, of making multiple commits. You can probably identify some files, that can be pushed without the rest. Do them first. You can stash the rest and test if the few files introduced any bugs. Resolve these bugs and repeat the process, until all your changed files are committed or reset.

The problem gets more complicated, when you already committed some files, that introduce a new bug. The Graphic then show what commands can be used to resolve the issue. Undoing some commit and making a new history.

The problem gets bigger, if the changes had already been pushed to the public repository, the one that is shared with your team. The graphic describes a danger zone, where you can even rewrite the git history on the server. In our Shanghai Javascript chatroom, was said, you should never use ‘git push –force’. And I agree, it is just a pain in the ass for all your team member.

my take:

For some part, I of course like as most others to see a nice and easy to follow git history. In best case the folks use ‘git pull –rebase’ to keep the history in a single line of commits.

Yes this is a nice to have, but I also think, it is just not worth it, to discuss and waist the teams time on this matter. Usually git is not only used as a version control, it is just used or collaboration and have a shared filesystem, that can easily synchronize.

Often people get into a feedback loop, of making a change, testing it on a dev environment. The developer every time is making a new commit. Often only switching some variables on and off.

I you want to use git for version control, I think it is better to use tags for that. I mean, how often do you go back, and start working from a previous version. It is more often, that you want to look back, and check, what the file has been in the past. And maybe a few files get restored from earlier times.

In my opinion, it is better, to take the content of that older versions file and add this to the current working branch. This has the advantage, that it is very honest, the history only go forward. And your dear colleagues are happy, that they can simply use ‘git pull’ to get the latest code and keep working to make progress, instead of tricking around with git.

And like in coding itself: you are not paid to use all features of your language or library, but to make progress. And sometimes, admitting to have done something wrong and going forward into the future with the right approach, is better, then covering up / rewriting the history.