Some beautiful newbie mistakes to make using git
Tags: git, github, programming, beginners
Published: 2020-11-01 09:25:47

_So let say I am working on a feature, X_

As a newbie, new to the **job**, new to the **project**, new to the **team**, and new to the **environment**. Won't it be better you get all the help you can get?

We all make mistakes. It is okay but is it on the fourth time? These are some mistakes that I have made. I have also heard and seen other developers do the same.

## Working directly from the main branch

What was previously known as the `master` branch is now `main` in most projects. Apart from `main`, there could be `docs` or `development`.

The `development` branch is for the development and testing of the project locally. So anyone can pull from the `development` branch and make changes. We did not know that we weren't supposed to develop on the `development` branch. Everyone on the team has something to do with the `development` branch.

Working directly on the `development` branch is not cool. Making and commit and pushing is worse. You can do this if you are the only one working on the project.

It is wrong and unacceptable, especially when the `CONTRIBUTOR.md` guide specifically dictates that contributors should create a new branch from the `development` branch and only push to their new branch ( remotely). The worse part of this experience is when you have admin privileges (Usually in a small team).

Is it a bad practice to pester the CTO, Lead or one of those "Seniors"?

## Create a new branch before touching the code

Usually, we rookies are used as "bug-hammers". We are meant or brought in to _fix_ bugs. How funny it is to _fix_ a bug you didn't create. How funny is it to _fix_ a hack you didn't implement? How are you supposed to _fix_ a bug with little or no information?

Create a new branch. That is what you are supposed to do. This point here complements the previous.

It doesn't matter whether you created the bug or the hack. You were employed to _fix_ it (Felix). 

## Pull and merge

`pull` and `merge` the `main` or the `development` branch to the branch you are working on before you `push`. 

So why do we have to `pull` and `merge` before a `push`? Well, there could be some changes made to the developing branch and such changes (merged to `featureX`) gladly reduces merge conflicts.

Won't it be better you are on a safer side when developing? Do you remember the feeling of pushing a feature branch after a long day? Do you want to keep remembering that feeling? I don't think you want to get the notification that there was a `merge` conflict and you have to `fix` it. You would get the notification from the platform you are using, from the Lead, CTO or a maintainer. You don't want to get that message or call.

## Make a lot of commits

Make a lot of commits, reasonable ones, as such. So for `featureX`, we would break the implementation into about four phases. Then I'd encourage you to make a `commit` after each phase. It may seem a bit unprofessional. As newbies, we look at efficiency over professionalism - we are learning. Having just one commit for the several phases of one feature is also great - squash the commits.

## Initialize git in the root directory

Have you ever tried pushing a project to GitHub and only realized later that you have pushed several projects? I bet you felt good? No.

Usually, this issue is related to vscode.

> Now, I am not saying vscode does that (push others folders along with the said project).

I am saying that open the project folder with vscode.  Do not just open the file you want to edit or write to with vscode.

On Ubuntu, where would vscode terminal point when you open a file with vscode? `home/<user>`.

So what happens when you initialize git?

One of the following happens:

- `Reinitialized existing Git repository in /home/<user>/git/`
- `Initialized empty Git repository in /home/<user>/.git/`

In both cases, that was not what you wanted. The first was kind of safe though it is still a flaw.

What other circumstances, similar to this that we should look out for?

- Initializing git in one of the folders in our project
- `add`, `commit` and then `push` from one of the folders in our project

## The `.gitignore` file

Add and always put the `.gitignore` file in the root directory of your application. Deleting unwanted files or binaries is awesome until you delete a file you shouldn't have had deleted.

How does it feel like to move files in a project that uses git to track files? I mean, what then is the purpose of git? If there is something you don't know, "google it".

## Install a Spelling Checker

There was a notification and it is was from the maintainer. It says, "There are typos in your fix. Fix it please".

This maintainer means business.

I use `streetsidesoftware.code-spell-checker`, a vscode extension. It has about 3.7M downloads.

Typos occur when we code. It is another aspect of a developer's life. It is unavoidable on its own as we type but try to.

## Use a commit hash

Using meaning commit messages can save us a tonne when we mess up a branch. Do not delete the whole project because of a mistake on a branch. Wouldn't it be better if you learnt some git commands over the weekends?

## Where do you keep credentials for old projects

It is nice once in a while to work on our old projects. To fix some bugs and update some dependencies.

A project that requires API keys and other credentials become a little unfriendly. We have to visit all the APIs we used and get new keys. SO wouldn't it be simpler if we had a backup of our `.env` file?

`.env` file paths are added to `.gitignore`. So when the project is deleted from our PC, there won't be a `.env` file when you clone the project again. I found [bitwarden].

## Get used to the simple way of doing things

I used to do `git branch featureY` from the `main` branch, then `git checkout featureY`, which could be done straight away as, `git checkout -b featureY`.

## `pull` after a `fetch`

Sometimes doing a `pull` after a `fetch` resolves a lot of conflicts. What was the simplest way you solved a `merge` conflict?

## `push` origin featureZ

Git `push` on branch `featureZ`, `git push featureZ`, does not work since there is nowhere remotely does branch for `featureZ` exit. I had to do, `git push --set-upstream origin featureZ`. I learnt and usually used, `git push origin featureZ`, and it works. 

##

Fixing merge conflict remotely (on GitHub) is quicker compared to locally. I learnt that if I want to merge `featureX` to `main`. Locally I would fetch any changes with `git fetch && git pull`. Then checkout into `featureX`. I then merge `main` into `featureX`, fixing any conflicts. I checkout into `main` if everything works out fine. Finally, I merge `featureX` into `main`, using `git merge --no-ff featureX` and push to GitHub. Read on [when-to-use-the-no-ff-merge-option-in-git]

#

[when-to-use-the-no-ff-merge-option-in-git]: https://stackoverflow.com/questions/18126297/when-to-use-the-no-ff-merge-option-in-git
[github-logo]: https://verdievoice.blogspot.com/2021/06/github-logo-png-discover-49-free-github.html
[bitwarden]: https://bitwarden.com/download/