Forem: Srebalaji Thirumalai

How to add multiple authors to a commit in Github

Srebalaji Thirumalai — Mon, 03 Apr 2023 09:00:52 +0000

Github supports to add multiple authors to a single commit.

This feature is helpful when developers do pair programming. So it will be clear who contributed to the commit. And their contribution gets attribution in the pull request and in their contribution graph.

And moreover adding co-authors is so simple.

Adding co-authors

You have to mention the author’s info in the commit message as below.

<Commit message>

Co-authored-by: Jon Snow <jon@gmail.com>
Co-authored-by: Tyrian <tyrian@users.noreply.github.com>

In the above snippet, you can see we should add Co-authored-by label. You can add multiple authors as you need.

And remember you should leave at least one line of white space.

Sometimes the author’s email address won’t be public. So Github will be providing a private email address to that user. You can use that email address too for privacy reasons.

You can see I have used a private email address for the user Tyrian

In the above image, you can see I’m adding a co-author.

And in Github you can see it’s showing two authors have contributed to the commit.

Using vs-code extension

If you are using vs-code then adding co-authors is much more simpler.

Git Co-Authors is a handy vs-code extension you can use to add co-authors to your repo.

git-coauthor - Simple multiple author support porcelain for git

I found another helpful tool git-coauthor which is very lightweight tool written in bash.

The usage is very simple. You can add co-authors to a list and use them as appropriate.

And it also has option to switch to solo commits and to co-authors commits easily. This is one of my personal favorite.

Github support for co-authors is a useful feature you can start using. And it comes in handy when you do pair programming.

Dev News - Top articles this week for developers

Srebalaji Thirumalai — Sun, 18 Oct 2020 14:24:13 +0000

Hey Devs

I have compiled a list of top articles from last week that you might find interesting

1. A warning about Glassdoor

Many developers rely on Glassdoor for company reviews. But is Glassdoor really that reliable to look for the company review. This article reflects a perspective about Glassdoor

2. Seems like AWS forked an open-source project and presented themselves a new service

The Twitter user @tim_nolet claims that AWS has forked this project and started with a new service. Of course, it's legal but you know?

3. VS-Code extension to make your life easier

This post lists some useful VS-Code extensions to help you write software better. My favorite on the list is Bracket Pair Colorizer, an Indent rainbow.

4. Free course on Docker and Kubernetes

This free course published on the FreeCodeCamp youtube channel that helps beginners learn the fundamentals of Docker and Kubernetes better. Containers have changed how we deliver Software so learning them gives you much advantage. This course covers docker architecture, images, volumes, and Kubernetes pods, services, configs, etc. Much recommended.

5. 150+ Stanford Computer Science is available online

CS Degree has seen big popularity in the last decade. And that popularity is not going anywhere. This article lists down nearly 150 courses from Stanford that are found online.

6. Computer Scientists Break Traveling Salesperson Record

After nearly 44 years, scientists have found a better way to approximate solutions to the notoriously difficult traveling salesperson problem. Traveling salesperson problem has applications ranging from DNA sequencing to ride-sharing logistics. So finding a better solution to seek the shortest round trip is truly inspiring. Read the full article on finding how traveling salesperson has been a real challenge in CS.

7. docs.github.com is open-sourced

Github open-sourced all of its product documentation. This will help in understanding how Github application design, workflow really works, and how we can benefit from it. And the company claims it is the first private production service that we’ve migrated into the open.

That's it :)

I hope you find it useful

Thank you for reading :) :)

How to use emoji in your commit message ⚡ ⚡

Srebalaji Thirumalai — Sun, 04 Oct 2020 06:57:18 +0000

In this edition let’s see how to use emoji in your commits messages.

Using emojis in your commit messages will be fun (😊) and cool (😎) in the first place.

And another use case I can think of is you can understand the purpose and intention of the commits very easily if you are following standardized rules for adding emoji.

Using Gitmoji in your commit

Gitmoji is one of the fine guides you can refer to add emoji in our commits.

You can see a list of emoji with their code. You can simply use this code in your code.

git commit -m ":bug: Fix Bug BD-1910"

You can see our bug emoji in Github.

Also, know that these Gitmoji won’t show up in the terminal without additional configuration.

Using gitmoji-cli

Another easy option is using gitmoji-cli

Gitmoji-cli gives an interactive option to add emoji in your commit. This is one of the easiest options to add emoji in your commit messages.

In the above image, you can see how the user is prompted to add respective emoji using auto-complete from the Gitmoji guide. Then an appropriate commit title and message.

Using gitmoji-vscode for VSCode users

gitmoji-vscode is a VSCode extension that helps you to add emoji right from your editor itself. This will come in handy if you are already a fan of the Git feature in VSCode.

You can also find gitmoji supported extension for your favorite editor too.

Apart from all the above-mentioned methods, You can also take a look at Emoji-log

This repo contains an experimental short standard for adding emoji in your commits. You can take inspiration from this repo and start using it in your repo with ease.

It also contains a few code snippets and aliases that you can start using right away.

And apart from these methods, you can just copy-paste emoji from the internet too 😂

That will work too but I know its a boring process and it may not support all systems.

Using a proper emoji standard can really help give your commits a real meaning. And of course, it will be fun and colorful to use too 😃 😈

Thank you for reading :)

How to reset a file to an old revision

Srebalaji Thirumalai — Sun, 04 Oct 2020 06:54:11 +0000

In this post let’s see different ways of resetting a file to a particular revision. This may come in handy in many situations.

Using checkout

git checkout <commit_hash_id> -- <file_path>

Example
git checkout cc1d4a7 -- example.py

I think the above command is very self-explanatory.

You are reverting a file to a particular commit. In other words, git will take the mentioned file and apply the mentioned commit changes to it.

You can mention multiple files to revert too.

git checkout cc1d4a7 -- example.py index.py

Using restore

git restore --source <commit_hash_id> <file_path>

Example
git restore --source cc1d4a7 index.py

We have seen restore in our previous edition. Restore is a new command and it helps in restoring a particular revision.

In the above command, we are using the —source option to tell restore to use only the particular commit hash. And we have also mentioned the file path to apply the changes only to the mentioned file.

You can use any of the above commands to reset a file. My personal favorite is restore.

Thank you for reading :)

How often you read (big) technical articles fully

Srebalaji Thirumalai — Wed, 30 Sep 2020 07:40:23 +0000

Hey Devs

How many of you read technical articles fully.

I used to read a lot of technical articles from different sites and I mostly skim through the articles.

Only very few (big) articles I used to read it fully.

And when it comes to listicles I mostly read it fully and bookmark it :P

And most listicles I see have much traction and engagement than other articles especially big and thorough articles.

What is your take on this? And how often you read big technical articles completely or you just skim through most of it

How to use git restore effectively

Srebalaji Thirumalai — Sat, 26 Sep 2020 13:27:36 +0000

git restore is used to restore or discard the uncommitted local changes of files.

Assume that you have done some changes in some files and then if you want to discard those local changes you can safely use git restore.

Another use case is if you want to unstage a file you can use this command. In other words, it is used to undo the effects of git add.

Usage

git restore <file_name>

Example:
git restore example.txt

In the above image, you can see that we have used git restore to discard the local changes of a file.

Other options

git restore one.txt two.txt // Mention multiple files

git restore . // Discard all local changes

git restore *.rb // Wildcard option

Unstage files

As said earlier, you can also use this command to unstage a file from the staging area.

git restore --staged <file_name>

You can see that the mentioned file is unstaged but the local changes of the files are still present.

Source option

git restore --source <source_id/commit_id>

The source option is used to restore a file from a particular commit. By default, restore will take the contents from HEAD

git restore --source f9456ba one.txt

In the above command, we are restoring a file from a mentioned commit.

Patch option

git restore one.txt -p

As you can see, you can select the chunks interactively.

git restore is one of the useful commands you can start using it in your workflow. It is marked as experimental in git docs but it’s not a very destructive command that you have to worry about.

Thank you for reading :)

Forgit - A utility tool to use git interactively

Srebalaji Thirumalai — Sat, 26 Sep 2020 13:25:01 +0000

Forgit is a lightweight CLI tool that helps you to use Git interactively. This tool is a very useful tool that helps you to work effectively.

You can view the repo here.

Installation

This tool uses fzf.So don’t forget to download it.

To install fzf, follow these instructions for your respective platforms.

To install Forgit,

Download the source from the repo.
Open .bashrc or .zshrc and add forgit.plugin.sh or forgit.plugin.zsh.
source .bashrc or source .zshrc

Usage

Some of the useful commands in Forgit

git add

The default command is ga

In the above image, you can see the interactive screen.

You can use arrow keys to navigate up and down.

Use Tab and Shift-Tab to add/remove the file.

git log

The default command is glo

As the tool uses fzf, you can fuzzy search the logs.

git stash

The default command is gss

Change default alias

Forgit also gives the option to change the default aliases.

Just configure these variables in your shell and source it. Some of the common variables are:

forgit_log=glo

forgit_diff=gd

forgit_add=ga

forgit_stash_show=gss

forgit_cherry_pick=gcp

For the full list of options, you can see this configuration to change the aliases.

Forgit may take some time to fit in your workflow but it’s a very useful tool that comes in handy in many places.

Thank you for reading :)

Introducing Go tutorial series

Srebalaji Thirumalai — Sat, 05 Sep 2020 09:04:29 +0000

Hey Devs

I'm starting a tutorial series to learn Go from scratch.

This series will help people to learn the language from scratch and will be covering advanced topics.

Lately, I was reading about learning in public. So I thought of just trying this out in small steps.

And I will be updating all my notes in my blog.

Let's see how it goes :) :)

Branch based vs Trunk based development

Srebalaji Thirumalai — Sat, 05 Sep 2020 08:41:45 +0000

Choosing the right-branching model can save you a lot of time in development. It also helps your dev team to work efficiently.

Coming to the point, we are gonna discuss two branching models today

Branch based
Trunk based

Branch based development

This is a very common strategy and most of them know it.

You have a stable branch like a master.

Then you have a feature branch like develop.

So whenever you develop new features or fix any bugs, you take a branch from develop and finish your work.

Then you raise a PR to the feature branch. After the code review, the branch will be merged.

When you have finalized the changes, then you merge the feature branch to master for the main release.

I know how common it is. Most of the open-source software use this method.

Trunk based development

On the other side, trunk based development doesn’t use branches or has very limited use of branches.

You have the main branch like master

Every developer will do all the changes in the main branch and push it directly to the main branch.

There are no PRs, branches, merge conflicts.

Just push directly to the main branch.

Seems very dangerous right?

With trunk-based development, you mostly can’t control who pushes the code and which code is being merged to the stable branch.

But there are things we have to consider with Trunk based development.

Trunk based development is useful when you want to deliver software in a fast phase.

And this method is always accompanied by best practices in writing software like TDD, CI/CD integration, Automation testing, high code coverage, pair programming, etc.

Trunk based development is a required practice of Continuous Integration (CI). With CI you get a deployment pipeline where you can run all tests and other integration jobs and safely deploy the code to production.

Most companies who are practicing CI often welcome Trunk based strategy.

Trunk based development is often practiced in a group of professional engineers. Because they have experience in writing software and know the best practices often. This comes with a high advantage.

Imagine a small group of professional engineers (maybe 10) who know best practices in development like TDD, Automation testing, etc, and are following Trunk based development. This group can deliver software in a fast and efficient way to its full potential.

This type of development is highly encouraged in Agile methodologies where you have to ship software frequently to get feedback often.

One can always argue that with Trunk based development you have very limited control over the code being released. It’s true but with the best practices, it can always be mitigated.

So choose your branching strategy wisely. If you need to deliver software in a fast phase, then Trunk based development is the best choice. On the other hand, if you need to tightly control the release you can follow a branch-based approach.

Thank you for reading :)

Github CLI - bring Github to the command line

Srebalaji Thirumalai — Sat, 05 Sep 2020 08:35:32 +0000

Github CLI is one of the useful tools you can start using right away if you are a very active Github user.

You can visit the repo here.

This is still in beta but you can still use it. It brings PRs, issues, and other useful features of Github to the command line.

I will cover some commands that I find very useful. And you can also play around with the tool.

Listing Pull requests

You can list all the PRs of the repo.

gh pr list

There are options for filtering PRs with the assignee, base branch, labels.

Examples :

gh pr list --label "WIP, help" // List PRs with the provided labels

gh pr list --base "master" // List PRs with master as base

gh pr list --assignee "john" // List PRs with the respective assignee

Creating a Pull request

Creating a PR is very easy with CLI. This can make you really productive.

gh pr create

The above command is a very basic option. This will create a PR with the _ master _ as the base branch and the _ current branch _ as the target branch.

There are other options as well for changing the base branch, labeling, assigning people, etc

Examples :

gh pr create --base develop // Here develop is the base branch

gh pr create --title "PR title" // Create a PR with title

gh pr create --reviewer "john, arya" // Assign reviewers

gh pr create --label "prod, help" // Assign labels

View Pull request change

gh pr diff <PR number / url>

Example
gh pr diff 3

The above command will show the diff of the respective PR. This will come in handy if you are looking for small changes in PR.

Creating an issue

Creating a simple issue from the CLI will come in handy often.

gh issue create --title "Search not working" --body "Search in main dashboard is not working"

The above command will create a new issue with the respective title and body.

There are like other useful options too

Examples

gh issue create --label "help, priority" // You can assign multiple labels

gh issue create --assignee "john, arya" // You can assign people

Listing issues

gh issue list

This will list all issues.

Examples

gh issue list --label "help, priority" // List issues by labels

gh issue list --assignee "john, arya" // List issues by assignees

gh isssue list --author "srebalaji" // Lists issues by people who created the issue

Creating gist

This is one of my favorites. You can create a public or private gist from the command line itself.

gh gist create main.js

The above command will create a private gist with the given file.

By default, gists are made private.

Other options,

gh gist create --public main.js // Creating a public gist

gh gist create main.js -d "NodeJS example" // Creating a gist with a description

gh gist create main.py copy.py home.py // Creating a gist with multiple files

Github CLI is a very useful command-line tool you can use. I have been using it for a couple of weeks and I can say it’s very useful. Of course, there are some hiccups but I believe it will be resolved in the upcoming versions.

Highly recommended if you are using Github often.

Thank you for reading :)

How to change git default branch from master

Srebalaji Thirumalai — Tue, 25 Aug 2020 13:01:22 +0000

Recently, there are many suggestions about renaming the default branch master to some other name. This was mainly due to the master-slave metaphor that some people are talking about.

There is evidence that states it was intended to mention master-copy or master recording. And it is not intended to master-slave.

But I think it’s people's perspective and if some think that they are not cool with that they can change the default branch.

So let’s see how to change the default git branch _ master _ to _ default _ (you can use your preferred name)

Before starting I have to tell you that I have tried this in multiple repos and its working fine without any breaking changes. If you are not confident enough then fork your repo and try it first.

Prerequisites

Make sure your CI/CD flow doesn’t get interrupted.
Make sure you have merged all the PRs targeting master. Other PRs are fine

There are three steps in renaming the default branch

Change the branch name
Set remote upstream tracking for the new branch
Change the new branch name in repo host (Github, Gitlab)

Change the branch name

git branch -m master default

The above command just renames the default branch to the name default.

-m attribute is used to rename the branch name without affecting the branch’s history.

Now the default branch is changed in the local but not in the remote.

Set remote upstream tracking for the new branch

git push -u origin default

The above command will push the new branch to the remote.

-u attribute is used to set the upstream tracking for the branch.

As you can see that the upstream is set for the new branch. But still, the reference to the old upstream is present in the local.

Change the new branch name in the repo host

In this tutorial, let’s consider Github. But the same option is also available in Gitlab, Bitbucket.

In Github, go to settings -> branches. You can change the default branch there.

That’s it you are done.

But remember that the old branch’s upstream is still present. It won’t affect your workflow. But you should delete it to keep your repo clean.

To delete the old branch’s upstream you can use

git push origin --delete master

As you can see the old remote stream is deleted.

Now the changes are done in your local and in the remote host. Let’s see how to bring those to other people who are already using the repo.

I mean there will be other people who will be using this repo. They have to do few changes to complete the flow.

As you can see still the branch master is present in the local of others who are already using the repo.

There are three steps for people who are already using the repo

Fetch all the branches
Update the upstream remote’s HEAD
Rename the default branch

Fetch all the branches

git fetch

The above command will just fetch all the remote branches to your local.

Update the upstream remote HEAD

git remote set-head origin -a

The above command will query the remote host for the HEAD upstream and it updates that upstream in the local.

Rename the default branch

git branch -m master default

This is the same as the old one. We are just moving the branch without affecting the history of the branch.

As we have already set the remote upstream in the previous step, the new branch is changed and is in sync with the remote.

Now the person can work with the default branch.

As I said earlier, I have tried this is in multiple repos of mine and it’s working fine without any breaking changes. This may seem to be confusing at first, but if you understand the process and read it multiple times you will get familiar.

If you got any doubts or stuck somewhere, you can contact me.

Thank you for reading :)

9 useful tricks of git branch you might not know

Srebalaji Thirumalai — Fri, 14 Aug 2020 07:09:22 +0000

List all branches that are already merged into a particular branch

git branch --merged <respective_branch_name>

Example
git branch --merged master

The above command will help you to find all branches that are already merged with the master branch.

Quickly switch to the previous branch

git checkout -

This will switch to the previous branch you checked out.

Alternatives

git checkout @{-1} // checks out to previous branch

git checkout @{-2} // checks out to second previous branch

List all branches ordered by most recent commits

git branch --sort=committerdate

The above command will list branches in order of the most recent commits. So you can see branches that you are using it most in recent times.

Very helpful command and it comes in handy when you are working with multiple branches.

In the above example, develop has the most recent commit. And master has the second most recent commit and so on.

Delete local and remote branch

git branch -d <branch_name>

This command will delete the branch only if it is merged with the parent.

git branch -D <branch_name>

This command will delete the branch irrespective of whether it is merged or not.

To delete the branch in remote you can use

git push origin <branch_name> -d

-d attribute will delete the branch in remote too.

Showing diff between branches

We have already seen this command in two of our previous issues.

git log master..develop

This command will help you show all the commits from develop but that are not present in the master branch. In this way, you can know that how many new commits are added to the develop branch that is not present in the master branch. And make sure you have the updated changes in the local before comparing.

Rename a branch name

git branch -m <old_name> <new_name>

Example
git branch -m development develop

The above command will rename the branch name in local.

To push the updated branch name to remote,

git push origin :old_name new_name

Example
git push origin :development develop

List remote branches

git branch -a

This command will list all the local and remote branches.

To list only the remote branches

git branch -r

These commands will be useful to see which remote branches are still present in local so that you can delete them.

I mean even after the branch is deleted in remote, there will be a reference to it in the local machine.

To delete all remote references in local, you can use

git remote prune origin

List branches containing a particular commit hash

git branch --contains <commit-hash>

Example
git branch --contains f9456ba

The above command will list down all branches that contain a provided commit hash.

Show all commits in the current branch yet to be merged to the parent

git cherry -v <parent_branch>

Example
git cherry -v master

The above command will list all commits in the current branch that are yet to be merged to the respective branch.

Thank you for reading :)