Some beautiful newbie mistakes to make using git

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