How to fix some common problems
Git is the main version control system we use at Narato through Github, Bitbucket or Visual Studio Team Services. Using Git so intensively means that my colleagues and I also bump into some common Git problems once in a while. In this blogpost I would like to tackle some of those Git issues.
Main Git FAQ
When you are working on a project with a team using multiple operating systems, you can get into trouble with line endings. Due to legacy reasons, the line endings on Windows based systems are different from those on Unix based systems. Windows uses carriage return + line feed for a new line, while Unix systems only use a line feed. Some text editors will change the line endings according to their style.
Solution for yourself: set the config (globally) core.autocrlf correctly (true for windows)
Solution for the team: add a gitattributes file to configure how Git has to deal with line endings
Additional: remove the index file in the .git folder one time and perform a git reset to reset the line endings for all files
Sometimes we accidentally commit files that don’t belong in source control, like the bin folder or a file containing secure data like connection strings.
Solution: Add a gitignore file to configure which files and folder Git has excluded for tracking.
Additional: If you already committed an unwanted file, perform a git remove with the “cached” option.
Merge vs Rebase
Merge and Rebase solve the same problem. They merge a source branch into a target branch, like a feature branch into the development branch.
Using the merge command, a merge commit is created on the target branch in a non-destructive way. The last commit before the merge commit still has the same commit hash. Anyone working on the target branch can just pull and continue their work.
A Rebase rebases a source branch on top of the target branch by replaying all the commits from the source branch one by one onto the target branch. When using a rebase, the history (git log) of the branch is very clean, but unlike a merge, rebasing is destructive because it rewrites the history. Anyone working on the target branch will get an error when they pull.
Tip: Never use a Rebase on a public branch (a branch where you’re not the only working on it)
Sometimes you want to have multiple commits in a feature branch while working, but when you merge into a dev or master branch those many commits are not relevant for the target branch history. In this case you can perform a squash merge, squashing all the commits into 1 commit with one clean message.
Most people never heard of Bisect, even though it’s a very handy tool to find a commit that caused an issue using a binary search. First, you have to tell Bisect to start and define the commit that is bad or has an issue. In our demo that’s the current commit. Secondly, you give Bisect a random commit earlier in history where the issue hasn’t occurred yet. Bisect will then select a commit somewhere in de middle of this timeframe and you have to give feedback whether this version is good or bad. If it’s still bad, then Bisect will search another commit earlier in time. Usually it only takes a few times to find the root cause.
Make sure you have a look at my video for the full details and live examples!