Git: Squashing multiple commits to one

Submitted by Peter Majmesku on Tue, 10/04/2016 - 21:14

Let's say you are done with an new feature. Now you want to merge your feature into the master or develop branch. To keep a good overview within your Git log, you want just 1 Git commit within your log. You do not want all Git commits which you have made during the development in your Git log. Because this would pollute the Git log.

The following way firstly checks out your master branch. Then you are "squashing" all your Git commits to 1 commit. Afterwards you specify the 1 commit which holds your changes.

$ git checkout master
$ git merge --squash yourBranch
$ git commit -m "[#MY-TICKET-ID] Squashed commits."

Creating a patch by Git

Submitted by Peter Majmesku on Mon, 08/29/2016 - 20:25

Firstly create a new Git branch: 

git checkout -b BRANCH-WITH-CHANGES

Do your changes and commit:

git commit -am "My changes."

Now create the patch file by a diff from your new branch and the master branch to extract the changes:


To test your patch, you can switch back to your master branch and apply the patch (the changes will not be commited, until you commit them in another Git command):

git apply EXTRACTED-CHANGES.patch

Git: Working with Git on different file systems

Submitted by Peter Majmesku on Mon, 08/29/2016 - 20:09

Git works also on Windows by the Git bash program, which integrates into certain terminal clients, like the one from PhpStorm IDE. To use Git on Windows, you should be aware of a few issues, if you work with other file systems, like the ones from the Unix world (Linux/Mac).

Case insensitive file system

Windows has a case-insensitive filesystem. That means, that the filenames "facebook.jpg" and "Facebook.jpg" are the same file for Windows. If you have such files, you cannot regularly commit. You have to use a special command, to let Git assume this files are unchanged:

git update-index --assume-unchanged FILENAME

Afterwards you can commit and Git will not bother you with that file.

Unix file and folder permissions

Windows does not know about Unix file and folder permissions. Even you have not visibly changes inside your code, Git will mark all files as changed after clone from a Unix file system. To let Windows ignore the file mode use:

git config core.fileMode false

Line endings

Windows has a pair of CR and LF characters to terminate lines. Linux and Mac have a single LF character. To not have all files marked as changed after cloning on a Windows system, use the following setting:

git config --global core.autocrlf true

sed: Another way of fixing wrong line endings on linux

sed is a stream editor which is pre-installed on linux systems like Ubuntu. It can fix line endings by the following command.

sed -i -e 's/\r$//'

git clean - Cleaning the Git repository to be able to merge with remote

Submitted by Peter Majmesku on Mon, 08/29/2016 - 20:06

Sometimes you get Git messages like

The following untracked working tree files would be overwritten by checkout

 The following command can be helpful in that case.

git clean -d -fx ""


-x means ignored files are also removed as well as files unknown to git.
-d means remove untracked directories in addition to untracked files.
-f is required to force it to run.

 I've learned this by a discussion on Stackoverflow:


GitHub not accepting public SSH key: fix it by switching from HTTP(S) to SSH in the Git repository config

Submitted by Peter Majmesku on Mon, 08/29/2016 - 19:57

If you clone a Git repository from GitHub via the HTTPS URL, which is placed in the section as shown below, than your public SSH key will not be recognized by GitHub.

You can test your public SSH key for GitHub usage by the following command:

ssh -T

If you have chosen the wrong HTTPS option before (it must be SSH), you can fix that by the following steps.

  1. Open the file at .git/config
  2. Look for 
    url = or url =
  3. Replace it by
    url = ssh://
  4. Save the file and GitHub will accept the public SSH key on the next push. No username and password typing anymore.

Git: Fixing "error: src refspec BRANCHNAME matches more than one."

Submitted by Peter Majmesku on Mon, 08/29/2016 - 19:50
Sometimes it happens, that there're more heads with the same name in the Git repository. That can happen by copy and pasting folders. To delete any duplicate head, the following command can be used.
git push origin --delete refs/heads/BRANCHNAME
Then the last command, which will bring it to work again:
git push origin BRANCHNAME
Subscribe to Git