How to fix git error “fatal: bad object HEAD”

During development, I stumbled upon an error in GIT that prevented me to complete any operation that required to contact remote origin (Fetch, push, etc..)

No matter which branch I was on, I would always received the following error when trying any of the above operations:

fatal: bad object HEAD

The repository in question was quite big ( over 4gb) and I wanted to find a solution that did not require me to pull a full copy of the repository down again.

The problem

The source of the issue, is a corrupted file within the GIT folder. There is no special reason for this to happen ( or at least I could not find any reasonable explanation for it), but it is not extremely common.

The code

I am going to share the solution that I have used in my specific case. It solved the issue in just a few seconds.

The following code, need to be run from the location of the affected repository.

cp .git/config .git/config.backup
git remote remove origin
mv .git/config.backup .git/config
git fetch

The explanation

The code above is self explanatory, but for the curious I will explain below line by line.

cp .git/config .git/config.backup

This line uses the command utility for copying files (read more). It is simply make a backup copy of the config file, within the .git folder

git remote remove origin

This line of code uses the remote feature of git, that has the main duty of
managing set of track repository. As explained on the official Git documentation , the remove command is used to remove all remote-tracking branches and configuration settings.

This last line of code, is the actual solution to our problem. By removing all configuration and existing files of remote branches, we remove our corrupted files.

mv .git/config.backup .git/config

We are not going to use another command utility, the one for moving files MV, as explained on the wikipedia website. The command is restoring our previously backed up config file. This step is needed to re-set all the remote branches.

git fetch

If you have ever used GIT, you will have come across the FETCH command. Running this command, will recreate all the files that we have previously removed. GIT is going to use the information within the config file, to know what branches and tags should be fetched from remote.


The above code helped me, and I hope it will support you in solving your issues. Please feel free to post any comment and/or suggestion to improve the above fix.

Vue Js development resource

I have been using Vue JS for the last couple of years, and I have created a set of resources that can be extremely beneficial for someone who is trying to get started or wants to have a reference to some resources throughout their development.

Disclaimer: I am not gaining any economical advantage by sharing this links and I have no affiliation with any of the following resources.

Official Vue Documentation –

Vue js official documentation screenshot

The official documentation is the perfect place to reference at any point of development. It is simple to follow, kept up to date and very comprehensive. I am amazed how well it is written.

Vue Dynamic Cheatsheet

Vue js dynamic cheatsheet scrennshot

No matter how well you know the API, a sneak peak of its extensive library it is always welcome. This simple page, have dynamic links to the official documentation mentioned above, making it a must have for any vue developer

News VueJs podcast –

Image result for vue podcast

A weekly podcast created to provide Vue developers with the latest news and tutorials to stay up-to-date with their technology. Very useful to know in advance what is coming in future releases.

Vue Cheat sheet –

A free cheat sheet that include all the essential vue syntax provided by the creator of Vue Mastery. This is perfect for people that like to have a visual reference to the Vue api

NativeScript –

nativeScript, homepage screenshot

An open source framework to build truly native mobile apps. It is great to get started with their online playground and fantastic to use, as it enables you to use your Vue skills to make native app.

Codesandbox –

codesandbox homepage screenshot

A powerful online code editor for Vue. It is packed with everything you need to get started and more. It is constantly updated with new feature, and it the one stop for any new project ideas that you may have.


Storybook is a development environment for UI components. It is packed with fantastic free add-ons ( accessibility, responsiveness, dynamic variables). And it is a great resource for any mid/large Vue project. (support other framework).

Vue Devtools ( Chrome /  Firefox) –

Chrome and Firefox DevTools extension for debugging Vue.js applications. A must have for all Vue developers. It support new Vue developer to get started by analysing the components and their state, and it is useful for experience developer to check performance, events triggering and so much more.

Vue mastery –

vue mastery banner

Vue mastery is the one stop for any training resources. They are the biggest supporters of Vue Js ( they donate part of the revenue) and often offer good deals.

Vue interview question –

A very useful blogpost provided by the toptal, that provide insight on the ‘must know’ interview question for a vue js vacancy.


I really hope the resources above will turn to be useful, and please do not hesitate to comment and send me a message if you think that I have missed anything that should be added.

Getting started with Github GraphQL API

This article is going to give you the basic knowledge necessary to start and develop your very own GraphQL API. This post is part of a series that will cover the full development lifecycle that lead to the creation of an example Github graphQL web app that can be found at the following link

GraphQL logo and basic example of query

What is GraphQL?

Before we dive into the actual details of graphQL, I am going to explain what GraphQL is, and what makes it so different from standards Restful API’s.

The actual definition of GraphQL defined on the official website is:

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

To summarise, GraphQL offer great flexibility compared to standards API’s. Clients are able to define what they want from a server in a single query, without the need to have to jiggle around specific API endpoints.

If for example you would like to create a list of users with their relevant address in a restful API, you will probably have to create two specific endpoint request, one to fetch an User and the second to get the user address.

GraphQL makes client request easier, without the need to make major change on the backend ( the server could still implement a restful API behind GraphQL). The above example can be achieved with a single request in GraphQL in which the client can ask for a “User with address”.

Github GraphQL API

Github character

I have specifically chosen to use the Github GraphQL api, because it is easy to access ( it is quite simple to gain a “personal access token”), and it is free and it provides tools and documentation that support its use.

Personal access tokens

For the scope of this post, you are not actually required to use an access token. I am going to show how to gain one, as it is the first necessary step to be able to move your example query into a real app and it is important to know how to obtain one.

To gain a Personal access token, you must have an account with github ( this can be created for free at the following link:

Obtain the token, after you have created an account, is very simple. You just need to follow this link and click the “Generate new token” button.

Screenshot of the "New personal access token" page form github
New personal access token

A token requires a Description, and a selection of access rules for your token. In this example we are going to query users, and we will therefore select the “User” scope.

Github GraphQL Api explorer

As mentioned above, one of the main advantages of getting started with the Github GraphQL api is provided by the tools provided to developers.

Github offer the ability to query live data, directly in the browser using their Developer explorer.

To access the explorer you just need to follow this link and enter your credentials.

Github GraphQL explorer screenshot

The explorer is divided in 4 section:

  1. Query window – Where we are going to define are GraphQL query
  2. Query variable window – This is going to include the dynamic variables accepted by our query
  3. A result window -This is going to show the returned query or a detailed error
  4. Documentation explorer – This window provide extensive documentation on all the API.

Document explorer

Github document explorer
document explorer

The first step is to get familiar with the documentation explorer. This is filled with autocomplete functionality and provides you with a Details, fields list, fields descriptions and a list of Fields that implements the given item. The picture provided shows the result for PageInfo.


If you have ever used a standard Rest API before, you are going to be completely our of your conference zone. GraphQL uses a Json like query. In the following example we are going to search for the first 10, users that match a specific “query variable”.

query SearchTop10Users($user: String!) {
  search(query: $user, type: USER, first: 10) {
    nodes {
      ... on User {

The query includes:

  • Name: SearchTop10Users
  • Variables: $user: String!
  • Search paramethers: query: $user, type: USER, first: 10
  • Expected return: node, name, login, etc..

As the above query shown, this is very different from conventional APi’s that had defined endpoint (eg. getUser). With GraphQL not only we are able to merge different queries together, but we are also in control on which fields get returned ( eg. just a subset of the user object).

Query variables

Running the above query, is going to result in an error, because our defined variable ($user) has never been defined.

In Gitbut GraphQL variables can easily be defined in the appropriate window. In our case we just need to specify a string for our $user. Variables are passed using a JSON object format.

{ "user": "Zelig" }  

Run it..

We have now completed all the required steps necessary to run our first GraphQL query in the explorer.

Github is going to save all different queries on your profile, providing an useful search. This queries can easily be copied in your application, using the Personal Access token generated above.


This post was aimed at providing you with a very first understanding of GraphQL and its power. Using the Github API has allowed me to understand its basic fundamental, without the need to create a full scaffolding around it queries ( no need to set up a project just to send the queries).

Github extensive documentation on the API, is very helpful to understand the different objects available within graphQL. like nodes and edges ( this may vary between different api’s).

In future posts I am going to implement the above query to create a full Vue application with the use of apollo.js.

Frontend Job interview research

Need of change

Last year, during our Front End chapter meeting, we agreed to invest some time to improve our front end interview format, as it was not really fit for purpose and did not really supported us in making the right decision about candidates.

The interview format in use involved a coding test, focused in making an ajax request with some added validation, followed by some adHoc question that were tailored on the individual.

Many people will probably see nothing wrong with the test, as it actually provided both coding visibility and the ability to ask questions. Unfortunately after careful research, me and my colleagues found the test unsuitable for the following reasons:

  • It tested mainly javascript when our company looked for a wide range of skills such as HTML, CSS, Javascript, accessibility, Framework ( react, vue)
  • It required developers to “work under pressure” and not everyone is good at that, and it was not a “requirement” for our vacancies.
  • The adHoc questions where too different to compare overtime, and it was hard to define candidates level on them.

After the above “problems” were highlighted, we started to collate all ideas and change our current process to create something that would fit our company requirements.

The different ideas

The new test required the involvement of everyone, so we opened up a survey to ask people what they thought was a cool test, and what did they dislike about it. The ideas that I received were amazing, most of them interesting.

Some of the ideas that were forwarded were:

  1. Create a set of question from
  2. Ask candidates to complete the FizzBizzTest
  3. Ask candidates to bring a project that they were proud of to discuss during the interview
  4. Ask them to complete a test in the house ( replicate a website page).
  5. Give candidates multiple tests, allowing them to choose what they knew best
  6. Live bug fixing

The ideas above were all great, and choose between then has been a hard and lengthy process. At first all of the above may seem good, but each of them had a problem. Either it would focus too much on a specific skill (2) or have legal complication, because they could not share the code (3), or could really be misleading as people could prepare or cheat (1, 5).


I would like to start this final paragraph by said that what I am going to share with you is not perfect, and it could actually not fit your company at all, but so far we had great feedback from everyone that has completed it, and has allowed us to interview a wide range of candidates, from Graduates to senior, without to need to adapt it.

The result

The final test was a mix of almost all the above suggestion, and has been carefully made ( and is actively tuned with new candidates feedback). The new test has 3 main parts:

  1. Home exercise
  2. Interview bug fixing
  3. Questions

Home exercise

I think everyone could agree with me, in saying that interview are very stressful. You are all dressed up and uncomfortable and scared of doing anything wrong (eg. using google to search for info) and wanting to give the good impression, that sometimes lead to the opposite result. To avoid this points, we all collectively thought that we had abolish having to complete a full exercise while under pressure.

The new proposed solution has the following information

  • Complete a specific exercise ( I am not allowed to give too many details).
  • The exercise will include basic requirement ( basic HTML, CSS and JS)
  • The candidate is asked to complete 2 more points from a pool of 6 specific topic ( responsive design, Advanced Javascript, Unit test, Accessibility, Advanced SASS, JS library Vue or React).
  • The candidate is provided with a ready to use zip ( just need to install node and type npm install).
  • The candidates is asked to spend no more than 3 hours on the exercise, and depending from their availability ( full time or unemployed) we give them the “expected” time to be able to fit the work ( a week or a couple of days).

The main point to get from the above breakdown, is offering the possibility to candidates to choose what skill they like most. We had candidates that just wanted to focus on the HTML make the design beautiful and clean, and others that wanted to show off their Javascript skills, by writing the above with full test coverage and completing the Advanced JS request.

Interview bug fixing

All developers know well that one of the most important skills in programming, is the ability to fix bugs. My team has thought that we needed to introduce a step in our interview that would avoid people from cheating ( asking someone else to create the above exercise for them).

We thought to “ask questions” about the exercise to candidates, but we knew to well that they people could “study” the implementation and be able to fool us. So we decided to ask developers to “fix some bugs”, more precisely, we would “break” their own exercise in a couple of places, and ask them to fix it.

Depending from the level of confidence we either do this together with the candidates, or leave them some space to sort it out.

We found this “step” to be very informative for us. It provides us with the “confidence level of the candidates”, it is less stressful that live coding ( as they are working on their own code), and it also show us their problem solving skills. I have to admit that his is probably the part I love the most.


Unfortunately, until now, candidates test would have been very hard to compare and contrast. We still needed something for different interviewer to be able to “understand” people level, without having to open up tens of projects.

Our final decision was a set of question that we have all build from the group up ( this was the hardest part to agree). The questions are divided in “topics” and “level”.

The topics follow the same distinction of the one provided int he home exercise, plus a few extra (like git, agile, etc..). Each topic has 3-4 questions, all divided by level.

The above distinctions allows us to provide the right questions to the right individual ( knowing their preferences from the exercise and from the “live bug fixing”.

This questions are not really defined, they are just “placeholder” for specific information. For example a JS question could be “ES6”, and a CSS one could be “responsive”. It is the interviewer discretion to ask specific question depending from the discussion they had and the code they have seen. For example what is the difference between “let and const” and “how do you use media queries”.

Each questions are written down by the interviewer, and then the answer level is provided (good, basic, knowledgeable, not know). Writing this single word instead that the complete answer, allows us to be able to “compare” candidates and understand their fir within the company ( I am aware that due to the nature of the OPEN questions, it is not a real comparison, but it provide a good idea of strength and weaknesses).


As mentioned above, this interview seem to be working very well for us. I have not only used it for external candidates, but due to its nice progressive structure, it has also been used for internal “developer programs” and “graduate training”.

We have now build a pool of over 15 different exercise and responses, that is really supporting us in making “good” decision of the candidates. Since the introduction of the above exercise, we also seem to be able to allocate candidate in the right spot, due to the more defined skills information that the test provide us.

I would be very happy to receive any feedback here by commenting below or on twitter. All feedback both positive or negative are welcome, because our real focus is to make our interview as smooth and stress-free as possible to all our candidates.


Post of the Week


Welcome to my “Post of the week”. In these posts I share thought, ideas or fact that I have experienced during my last working week. If this is the first post of this kind, I suggest you to go and check out my latest posts too:

These small posts are aimed at new developers and people that want to learn what I believe to be important events that happened during my week.

I really hope you enjoy it, and as with every of my post, I look forward to see feedback and comments.

Code Review – Business Value / Coding Standards

This week I had the pleasure to work to Bristol, around 2 hours drive from my hometown. This journey help me in catching up on my podcast backlog.

During one of this podcast there was a brief definition of two main types of code review that I have never heard before, but made sense straight away.

The Business Value Review and the Coding Standards Review.

The business value review

This review is usually carried by developer that are aware of the “business value” and are very knowledgeable of the source code. This review focuses less on the actual line by line code, and more on the consistency of the code with the rest of the solution and its architecture/structure decisions.

The business value review are carried by people that usually “outside” the team. These are the review that I get asked the most being a technical lead. I was not aware of this specific distinction, but I was providing “business” insight and suggestion.

The coding standards review

The next type of review are called “coding standards” review. This is usually carried within the team and are more focused on the actual adherence of the coding standards and specific project implementation. This review goes in more details, and at times can actually even point out simple breaking space and class name.

Unfortunately, make these reviews is quite a rarity for me, as I am not part of a team anymore. This review seem to take place within the team, because they require a level of “trust” and “openness” to actually be accepted without feeling confronted or attacked.

Visual studio code – Github Pull request

As part of my unstoppable need to learn, I have found a very cool extension for Visual Studio Code that will allow you to handle pull request without having to leave our favourite IDE. I think this extension, is going to support all those Open Source project administrator that try to support free project to help the community, while overwhelmed by the amount of time necessary to keep it stable and updated.

A small introduction to the extension can be found in this video from Channel 9.

I have started to use Visual Studio Code for my small side project, but in time, I have started to use it more and more, until I feel it irreplaceable. The Visual Studio Code Team is open to listed, quick to change and Microsoft made it simple to extend. No matter what language you write ( I have used it for full c# projects, js, node and PHP) I greatly suggest you to use it.

Agile Values – Commitment

We have been using agile methodology in our company for quite a few years now. I have never actually had a formal training on scrum, but I always enjoy a nice conversation on its principles. It usually turns out that many people “follow” all principles without even knowing it, because at the end of the day, I see agile as a manual for good team management ( i live this as a discussion for another day).

This week I had the opportunity to discuss “agile” with a very knowledgeable person, that has highlighted me with the value of “commitment”.

For people that are now aware, some Agile methodology are build on top of 5 values that are: Commitment, Focus, openness, respect and courage.

I am of the idea that Commitment is probably the most important and the hardest value to actually follow. The value of commitment is not only about “estimating” tasks and filling the sprint up.

Commitment does not stop at the start of the sprint, it is shown throughout the sprint and I share below what I believe to be strong example of commitment:

  • Estimation – Committing to a time estimation for the ticket.
  • Ticket ownership – commitment to own a ticket and to see it DONE
  • UAT/PO demo – Committing to show any progress as soon as they are ready
  • Daily Standup – Committing what you are going to achieve during your work day.
  • Retrospective – Commit on taking action from previous mistake
  • Sprint Goal – Commit to achieve a specific goal at the end of the sprint

Unfortunately most of the above points are not easy to achieve. It is easy to say your part during the daily standup, but it is completely different to really commit to it and working toward achieving the defined goal. The commitment goal is actually a frame of mind, that when achieved it brings the greatest results.


This week I have learned so much. I listened to numerous podcast, watched different videos and had the chance to discuss great topics with great colleagues.

I am always amazed to how much I still have to lean. Our industry is so fast, it never stop and learning should be our primary focus.

I really hope the above points will support you in learning something new and please feel free to comment or contact me if you want to discuss anything further.