Git

Git bisect is a git command that makes it easier to track down where a problem was introduced to a codebase.

In large projects you may find that a change was added to the code that causes a problem and you then need to track down where that problem occurred. Knowing where the problem was introduced makes debugging the issue a lot easier.

You could just checkout commits until you find the culprit, but git comes with the bisect tool that can assist in this process and can even be automated to quickly find the problem.

I have been using Git for a number of years and I can remember feeling quite daunted at the complexity of some of the commands I saw on the internet. When I started using Git on a daily basis I soon realised that the basics were quite simple and the complexity only lay further down the road with commands like cherry-pick or rebase.

Whilst Git does sometimes make me scratch my head, it is never as bad as the days of SVN where I would have a notepad of 'fix' commands that I would copy and paste into my terminal to solve random problems. I usually didn't even know what the problems were, just that this command fixed things so I could continue on and not lose work.

The git diff command will allow you to view the differences in your workspace. This can be used in a number of ways to look at the differences in a file, in a branch or between two branches.

For example, you can view the differences in your current workspace by just running git diff on its own. By supplying a file you can look at the differences in just that file.

To compare the difference between one branch and another you use '..' to separate the branch names. For example, to look at the differences between the head of the 'main' branch and the head of a feature branch use this syntax.

git diff main..feature_branch

This can often be quite noisy, especially on large projects, so to check just one directory between two branches you can add the directory path to the command.

Creating branches in git basically free and is easy to do. This has lead to the development of techniques like git flow and other branch related work streams, which are now commonplace in development.

If you have a project being worked on by many developers you can get into the situation where there are many branches in the project. Some will be merged, some will be worked on currently and some more will be branches that were worked on, but never finished (for one reason or another). This can lead to some confusion over what branches are being worked on, especially if you want an oversight on the current health of the project.