Forem: Eduardo Maciel

Streamlining Your Git Commit Workflow: Commands and Handy Aliases ☕

Eduardo Maciel — Tue, 21 Jan 2025 16:13:46 +0000

Git workflows are essential for maintaining a clean and efficient development process.

Whether you’re working solo or collaborating with a team, structuring your commits properly ensures that changes are tracked, conflicts are minimized, and dependencies stay up to date.

Below, I'll break down a common Git commit workflow and explore time-saving aliases to simplify these steps.

A basic Git Commit Workflow to create new code

1. If you are not on main, switch to the `main` Branch

git checkout main  # Or use the alias: gcm

2. Code ... Code ... Code ☕

3. Stash Your Changes

git stash  # Alias: gs

4. Pull Latest Changes

git pull  # Alias: gl

5. Create and Switch to a New Branch

git checkout -b <branch>  # Alias: gcb <branch>

6. Pop stash

git stash pop # Alias: gstp

7. Git Commit

git commit -m "feat(subject): descriptive message"

8. Push Branch to Remote

git push -u origin HEAD && gh pr create --fill --body ''  # Obs: this uses the gh cli

9. Code Review...

10. After merging to `main`.

git checkout main  # Or use the alias: gcm
git pull  # Alias: gl

Git Aliases Configuration

Add to .gitconfig:

[alias]
    co = checkout
    s = status -sb

Shell Aliases

Add to your shell profile:

alias gs="git stash"
alias gl='git pull'
alias gstp='git stash pop'
alias gcb='git checkout -b'
alias gcm='git checkout main'

In Conclusion

Always start from an updated main branch to avoid conflicts
Every possible conflict will be solved locally
Use dedicated branches for isolated work
Keep commits small and focused with clear messages
Leverage aliases to save time on repetitive commands

Woovi

Woovi is a Startup that enables shoppers to pay as they like. Woovi provides instant payment solutions for merchants to accept orders to make this possible.

If you want to work with us, we are hiring!

Photo by Deva Darshan on Unsplash

How a Senior can be more helpful on company

Eduardo Maciel — Tue, 18 Oct 2022 14:38:59 +0000

What is a Senior developer?

A Senior Developer is a person in a company that has a lot of knowledge relation to other developers, but the concentred knowledge on this Senior is not so cool for the entire company, because it can be shared with other developers, and increase the team's seniority.

How the Senior Developer can share your knowledge?

The Senior developer can share your knowledge building the documentation for each doubt that each developer can have. If he builds documentation for each doubt, when another dev asks or needs the content of this doc, the Senior dev won't take time to explain about making a pair programming.

For new devs in the company, the documentation can't be enough, so the senior developer can make a pair programming, making a tour of the code and explaining how the flow works on code.

On the Woovi we have a culture of creating new documentation for each question, core processes, and new patterns/rules that we create. So by now, we have more than 240 documents, explaining processes, code patterns, and tests. With this amount of documentation, we ensure that our new Developers with take less time on onboarding time, and have more time to focus on delivering value.

Another way to share knowledge

Context

When we are on a new codebase or get a new feature we don't have too much context about it. So the Senior Developer can share your known context for the developers across the issues, detailing with high granularity how the new feature should be implanted, your cons and pros, how to test, etc...

Mentoring

Mentoring devs will help them how to understand the code and understand the mental model behind the code. So before they code, they will know the above vision of the code

The cool part of elevating the team's seniority

Be Replaced

If the Senior Developer teaches Junior Developer how to do the things that he already knows, this Senior is ready to learn and implement new things on the codebase, because he doesn't need still doing the same thing that the Junior now knows and will replace the Senior Developer.

Discuss advanced topics

The intention of the team it's grown on seniority over time, so how more basic things the team knows about the code, the more advanced things the team will be able to discuss because the basic things already known by the team and don't need to learn again. "The base it's important!".

If you want to work with us, we are hiring!

Migrating our scripts to Node.js v16 using codemod

Eduardo Maciel — Thu, 11 Nov 2021 14:25:17 +0000

At Entria we have a lot of Node.js scripts to automate common tasks
we also make a script for any migration and to make it easy to run a single migration for test purposes and each script starts with anonymous async functions that is auto executed.
Like this template

const run = async () => {
   //migration code
}

(async () => {
  try {
    await run();

  } catch (err) {
    // eslint-disable-next-line
    console.log('err: ', err);
    process.exit(1);
  }

  process.exit(0);
})();

This works well, but not enough for our use case. Because we create tests for our scripts and migrations if they are used in production.

If you import the run function in your test files it will run the async functions in your tests, which is not the behavior you wanna. So we have a check async function that is only auto executed when we are running directly.

To make this check, we used module.parent propriety, but it will be deprecated on Node v16.

Context of Node v14 and v16

In October 26th, 2021 Node.js v16 replaced v14 as the LTS release.
And with these changes we on Entria bring to us breaking changes into our codebase on Entria, like a module.parent.

module.parent has used on Node v14 to locate if script is a module or executable, like:

if (!module.parent) {
   // running like `node myfile.js`
} else {
   // running like require('./myfile.js')
}

We had 206 files that use module.parent

And we want changes all occurrences of module.parent to require.main, that allows we check the same thing of module.parent.

if (require.main === module) {
   /// running like `node myfile.js`
} else {
   // running like require('./myfile.js')
}

To change all occurrences of module.parent we used a codemod, with jscodeshift. Codemod is a tool/library to assist our with large-scale codebase refactors that can be partially automated.

But Eduardo, why you not use find and replace of your IDE?

R: Because this require a lot of attention and time of our developers, and if we not used codemod can't sure that can exists more module.parent on the future.

Time of code

We want change

if(!module.parent) {

}

if(require.main === module){

}

How ?

We used jscodeshift to codemod.

First you should add jscodeshift in your node_modules with

npm install -g jscodeshift

After this, you should create an archive that contains our codemod, in this case, replace-module-parent.js.

First, we should create a function that is used in all files of the folder that we select, and pass two arguments, fileInfo and api.

The fileInfo argument represents information of the currently processed file, and api is object that exposes the jscodeshift library and helper functions from the runner.

// replace-module-parent.js
function transform (fileInfo, api) {

};

module.exports = transform;

Now we want to get jscodeshift helpers, from api.jscodeshift and transform our code to AST (Abstract System Types).
And you can explore more of our AST here AST Explorer.

const j = api.jscodeshift;

const root = j(fileInfo.source)

Now, we want find all occurrences of if(!module.parent), and replace to if(require.main === module)

// finding all ocurrences of if(!module.parent)
root
  .find(j.IfStatement, {
      type : 'IfStatement',
      test : {
        type : 'UnaryExpression',
        operator : '!',
        argument : {
          type: 'MemberExpression',
          object: {
            type: 'Identifier',
            name: 'module'
          },
          property: {
            type: 'Identifier',
            name: 'parent'
        }
      }
    }
  })
  .filter((path) => {
    if (path.node.test.type !== 'UnaryExpression') {
      return false;
    }
    return true;
  })

Replacing all to require.main

.forEach((path) => {
    const requireMain = j.ifStatement(
      j.binaryExpression(
        '===',
        j.memberExpression(
          j.identifier('require'),
          j.identifier('main')
        ),
        j.identifier('module')
      ),
      path.node.consequent,
      path.node.alternate
    )
    j(path).replaceWith(requireMain)
  });
  return root.toSource();

And on final our codemod is

function transform (fileInfo, api) {
  const j = api.jscodeshift;

  const root = j(fileInfo.source)

  root
  .find(j.IfStatement, {
      type : 'IfStatement',
      test : {
        type : 'UnaryExpression',
        operator : '!',
        argument : {
          type: 'MemberExpression',
          object: {
            type: 'Identifier',
            name: 'module'
          },
          property: {
            type: 'Identifier',
            name: 'parent'
        }
      }
    }
  })
  .filter((path) => {
    if (path.node.test.type !== 'UnaryExpression') {
      return false;
    }
    return true;
  })
  .forEach((path) => {
    const requireMain = j.ifStatement(
      j.binaryExpression(
        '===',
        j.memberExpression(
          j.identifier('require'),
          j.identifier('main')
        ),
        j.identifier('module')
      ),
      path.node.consequent,
      path.node.alternate
    )
    j(path).replaceWith(requireMain)
  });
  return root.toSource();
};

module.exports = transform;
module.exports.parser = 'ts';

To run this code you can use this on your terminal:

jscodeshift -t replace-module-parent.js [your-input-files] -d -p