DEV Community: Dmitrii Pavlov

When HR wants a more experienced developer.

Dmitrii Pavlov — Tue, 27 Jan 2026 15:50:50 +0000

“How many years of experience do you have?”
“We’ve decided to move forward with a more experienced candidate.”

Of course.

Does this sound familiar?

Have 2+ Jobs? Use Git without letting them know about each other

Dmitrii Pavlov — Thu, 12 Jun 2025 15:18:15 +0000

(or just want to separate work and personal projects)

Let’s say you’ve been using GitHub under your personal identity — maybe something like TrollCoder. Everything’s been smooth until you get hired, they give you a corporate email, and set you up with a company GitHub or GitLab account.

Suddenly, you're expected to use your real name and photo in commit history — but your next commit to a work project shows up as TrollCoder:

😱 Awkward. Especially if your Git identity shows ties to a different company...

Bottom line: if you work for multiple clients or just want clean separation between personal and professional activity — it's crucial to manage Git identity per project.

A few Git facts:

Git stores your name and email globally.
This info ends up in every commit.
Unless configured correctly, you risk leaking personal info into work repos (and vice versa).

Let’s fix that.

Step 1 — Check your current Git identity

git config --global user.name
git config --global user.email

If nothing is set globally, check your local project config:

git config user.name
git config user.email

Step 2 — Use conditional Git configs per folder

The idea is to define separate Git profiles depending on the folder path.

Let’s say you work for a company called abcdefg. In your ~/.gitconfig, add:

[includeIf "gitdir:~/mydevfolder/"]
    path = ~/.gitconfigs/.gitconfig-personal

[includeIf "gitdir:~/mydevfolder/abcdefg/"]
    path = ~/.gitconfigs/.gitconfig-abcdefg

What’s happening here:

Any repo under ~/mydevfolder/ will use your personal Git config.
Repos under ~/mydevfolder/abcdefg/ will use your work Git config for company abcdefg.

Step 3 — Create the config files

First, make a place to store them:

mkdir -p ~/.gitconfigs

Personal config (~/.gitconfigs/.gitconfig-personal)

[user]
    name = Troll Coder
    email = troll.coder@gmail.com

Work config (~/.gitconfigs/.gitconfig-abcdefg)

[user]
    name = John Smith
    email = john.smith@abcdefg.com

✅ Now anytime you commit inside a project under abcdefg, Git will correctly attribute the commit to your work identity — no more accidental TrollCoder showing up in corporate history.

Wrap-up

This setup helps you avoid identity leaks between work and personal repos, keeps your commit history clean, and saves you from embarrassing mistakes — especially if you freelance or contribute to OSS on the side.

If you found this helpful, give it a ❤️ and share it with your team.

DO comment your TS code

Dmitrii Pavlov — Wed, 14 Feb 2024 04:26:32 +0000

Once, while creating a module of code that is complex in its logic, I noticed that I wasn't following any rules of code commenting at all. All comments were scattered with different syntax, distracting from the code and providing no benefits.

const me = new CommonFrontend();
class World {}

// Your code isn't as complex as you think
me.has_need_for_writing_articles = 1;

/** Why are you writing this? */
/**
 * TODO - 
 */
me.write_article_for_myself();

// =========
// ! Warning: This article is too simple and no one needs it
//-   Don't write
// =============
if (World.has_someone_who_needs_this) me.go_on();

Everyone knows the difference between single-line and multi-line comments:

// This is a single-line comment

/**
 * This is a multi-line comment
 */

HOWEVER:

// I can
// do this multi-line

/** or do this single-line */

However, comments in the /** */ format are recognized as documentation of function, class, or method, while // comments are not. So, I started describing entire code blocks with // comments (even if they span multiple lines), but variables and functions with /** */ comments only (preferably exactly in a single line, as they are more common in your code).

Now, when hovering over a function anywhere in the code, I see the comment written above it:

Of course, a comment that would describe an entire block or file would hinder understanding the purpose of a function, as it would also be displayed in the popup-description as a documentation of that one exact function.

Here's an example:

// Description of some blocks in a file
// Some facts that should be known about classes here
/** 
 * Class description
 * Some
 */
class CorrectCommentedClass {
    /** described */
    constructor() {}

    /** described */
    method() {
        // use such a comment to describe some strings in a functions' body as well    
    }
}

Secondly, unused and often buggy code remained behind comments, which we simply forgot about and couldn't find again. To avoid this, use keywords in /** */ and // comments both:

!DEPRECATED - for explicitly outdated code that should be replaced or has already been removed in some places.
TODO - to denote code that needs further implementation.
FIXME - for obvious bugs or potential issues that need to be fixed as soon as possible.
*KLUDGE - description of necessary workarounds and illogical pieces of code, followed by a description of "why?". These keywords and signs at the beginning are highlighted by the BetterComments extension for example or by default (depends on IDE), and you can search for them using these keywords.

And, forgive me, but I really do use this:

?WTF - for parts of the code that I completely don't understand and don't have time to figure out, hoping that one of my colleagues will see this in the code and leave a comment next time.

/** !DEPRECATED - why? where is new code? */
/** TODO - what? */
/** *KLUDGE - why? what is it for? */
/** FIXME - describe the bug */
/** ?WTF */

And this brings us to the conclusion:

Write comments for your code. Sometimes I write them before writing the main code - it helps to think through how exactly it should work.
Every time you need to take a break or have a minute, write comments for the code adjacent to yours.
Sometimes enter keywords in the search in your IDE, and, if possible, refine FIXME and explain to your colleagues ?WTF.

TU, and write what you think in comments:

class World {
    static has_someone_who_needs_this =
}

Proper use of git for beginners and beyond

Dmitrii Pavlov — Sun, 30 Apr 2023 17:11:17 +0000

I have noticed that many programmers neglect the rules outlined below, or don't know about them. Nevertheless, following these rules can standardize the work of both large and small teams using git, avoid problems and errors in dev branches, and on production.

It is important to note that I am not a git guru and don't know all the commands and features, but I hope that this article will be useful

"We always push to master"

The first rule that needs to be followed is to separate branches for production and development. I usually use the main and develop branches. The main branch is usually automatically deployed with each change, while the develop branch is used for development but there are no errors and all the functionality is completed.

As shown in the diagram, any changes to the main branch come only from the develop branch (which may be linked to some test environment), but no one works directly with the develop branch. Every task should start with inheriting from develop and creating a new branch. Any fixes should be made in a separate branch and then merged into develop.

In cases where a task affects a large functionality, especially if it requires the involvement of multiple developers, it is necessary to inherit from develop into a separate "EPIC" branch. They can have sequential numbers EPIC-100, EPIC-101 ... or reflect the essence EPIC-notifications. Each developer working on this "EPIC" should inherit from it and merge their completed task directly into it.

With this hierarchy, it becomes possible to delegate tasks to developers of different levels. For example, you can allow push to develop only to team-leads and senior programmers. And for some tasks, you can give full control of EPICs to middle developers so that they can control the merging of tasks of juniors and be responsible for the code quality in the EPIC. This will minimize errors and distribute responsibility for the project to all developers according to their abilities. And your branch will always be yours - sudden desynchronization of the local and remote server due to unsynchronized pushes of different programmers will not happen.

Something is wrong - we need to roll back

Sometimes one of the developers working on a project may accidentally introduce incorrect changes (due to inexperience, carelessness, or simply because his changes did not negatively affect local development). And sometimes it can be very difficult to find and fix the cause of newly appearing bugs and errors.

Recently, I witnessed a situation where an obscure error occurred after 8 commits on top of the last correct version of the application and over 200 changed files.

In such cases, rolling back is necessary.

Suppose we need to roll back the last 2 commits, which we believe contain the error. This can be done in 2 ways:

git revert HEAD~2..HEAD

That creates 2 new commits that undo the changes of the previous commits. This means that the commit history remains unchanged (new commits with changes are added).

git reset --hard HEAD~2

That undoes the changes made in one or more commits, completely removing them from the commit history.

!!! I strongly advise against using the second option !!!

Firstly, it permanently deletes commits in which, in addition to the error, there may be useful code written by other developers, which may be needed to create new commits after the rollback.

Secondly, this will undoubtedly cause synchronization problems with other developers, since the commit history in the remote repository will be changed.

To summarize - use git revert,
...or git reset --hard, but you must understand what you are doing.

Proper committing and merging

Such situations should happen extremely rarely and should be minimized as much as possible.

1) To do this, you should always understand what you are pushing to the remote repository and forget about the command git add . forever. Instead use the UI of your IDE to add files to the commit. In VSCode and WebStorm, you can view all modified files and click + on those you are sure that the changes were not accidental keystrokes, but your meaningful changes.
2) The code in your branch should be committed for each small but complete change. And the commit message should contain enough information: the task number or name and a brief description of what you have done. For example, "Notifications - creating a class for connecting to websockets."
3) But in EPIC branches and other shared branches where your commit will be merged, there should be only one commit with a reference to your branch. To do this, merging into this branch should be done with the flags --no-commit and --squash.

# In a some EPIC branch:
git merge your-branch --no-commit --squash

This command will not immediately merge your branch, but will only apply all the changes from your branch to the shared branch. You can view them in the UI of your IDE and double-check if you are sure about each modified file in the shared branch. After that, you can commit with a description that contains the branch name and the name of the merged branch. For example, "Site-sidebar - Notifications merged."
4) After merging into the shared branch, especially into the develop branch, you should test the functionality of your feature and the areas that you think could have been affected by your code changes. If everything works correctly, you can push the shared branch with the merge commit to the remote repository.
5) Merging into develop should be done in the same way as described above. EPIC branches, verified before, can contain many commits for each completed task. Now each EPIC needs to be merged into develop with one commit. "Site-sidebar merged". After some time, when the tasks prove their worth in action, task branches can be deleted from the repository (this can be done after a certain period, for example, 1-2 months, depending on the pace of your team's work).

Don't forget to use "merged" word in a description to differentiate regular commits from merging

Some Tips

1) Writing Git commands with all flags and parameters can be tiresome for programmers who are not used to typing blindly with 10 fingers, especially if they have to enter them constantly.
Personally, I use OhMyZsh to simplify some commands. If you're not a Windows user, I highly recommend it. For example:

gcmsg 'first commit'
# This is the same as
# git commit -m 'first commit'

gco develop
# git checkout develop

gcb new-branch
# git checkout -b new-branch

2) If you use VSCode, like I do, take a look at the Git Graph extension. Typing in the console is always faster than using the mouse to navigate, but sometimes it's hard to orient yourself in the project without a good GUI.

3) Even with this work structure, problems and errors arise. And here it is extremely important to understand how it is easier for you to communicate:

Write comments on completed tasks in your task managers with a description of the current branch state (possibly with a description of new errors and necessary scripts to run the application),
Mark yourself in messengers about your status
Divide your general meetups into smaller ones - for those working on a specific epic.