git config is a powerful command in Git. You can use the Git configuration file to customize how Git works.

This file exists in the project level where Git is initialized (/project/.git/config) or at the root level (~/.gitconfig). If no configurations are specified, Git uses its default settings.

In this article, you'll learn some helpful Git configurations that can improve your development workflow. The tips shared here are things that have worked for me. There are a lot more you can try after reading.

Git Configuration Tips

Here are some global Git configuration tips.

1. Choose the default editor for Git

When you try to make commits in Git, it by default will open a vi editor that looks like this:

This editor can be difficult to use, and if you're like me, you may want to use your preferred editor for writing commits. In your ~/.gitconfig file, add the following:

[core]
    editor = code --wait

or use this shell command:

git config --global core.editor "code --wait"

This configuration tells Git that for operations like commits and tags, I want to use my VSCode editor.

For other types of editors, please refer to this image from Atlassian:

Editor configurations for git from git config | Atlassian Git Tutorial

2. Git pruning during fetch

Do you know what the pruning command does during fetch? If not, you may want to check this article first that covers how to delete outdated local branches with the prune git option and the branch delete command.

TLDR: Pruning during fetch is a cleanup method that deletes outdated remote references in your .git directory when you do a git fetch --prune.

As I explain in that article I just linked, you can automate this without always adding the --prune option. To do this, add the following to ~/.gitconfig:

[fetch]
    prune = true

or use the following command:

git config --global fetch.prune true

With this in place, pruning will occur whenever you do a git fetch.

3. Git aliases

In the Git configuration file, you can add aliases for those long commands you type from time to time. For example, commits, stashing, and so on.

Let's say you want to add an alias for adding an empty commit. In that case, you can add the following to the config file:

[alias]
    empty = "git commit --allow-empty"

or in the terminal:

git config --global alias.empty "git commit --allow-empty"

And you can use the command like this:

git empty "Empty commit"

You can also add other shell commands outside Git as aliases. For example, an alias that deletes local branches that have been merged in remote:

[alias]
    delete-local-merged = "!git fetch && git branch --merged | egrep -v 'master' | xargs git branch -d"

The exclamation mark "!" tells Git to run it as a shell command and not a git * command.

For the alias, we do a git fetch. Then we get the merged branches, pipe that as input to the egrep command, filter out the "master" branch, and delete the branches.

4. Setting the default branch

When initializing a repository (git init), the default branch is master. Today, some developers would prefer that to be main or something else entirely.

You don't have to create a new branch called main, delete the master branch, and use the main as your default. That's a long process. In the Git configuration file, you can set a default branch upon Git initialization. Here's how:

[init]
    defaultBranch = main (or whatever name you want)

This way, git init would create a "main" branch as the default.

5. Show short status by default

By default, the git status command shows you changes in your project with long details. It's in this format:

On branch [branch name]
Your branch is up to date with ...

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in the working directory)
    modified: ...

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    ...

no changes added to commit (use "git add" and/or "git commit -a")

This is a helpful output with instructions, but sometimes you just need a summary of the repository status. The --short option added to git status gives a short formatted output. The result would look like this:

M [file]
?? [file]

"M" means modified, and "??" means untracked. We can improve this process one step further by making it the default status view using the following configuration:

[status]
    short = true

Conclusion

In this non-exhaustive list, we've seen five ways to improve our development workflow by customizing the way the Git works by default.

You can find more information about all the Git configuration options (from branches to pulls, to fetches, and many more) in the git-config Documentation.

Configuration is an essential part of every application. It helps enhance an application's flexibility and maintainability.

With this in mind, it's very important that developers are able to correctly identify what items should be in configuration.

In this article, I'll walk you through 8 items that should be configurable in your applications.

Define "Configuration"

We will not be aligning with any existing platforms out there.

For the context of this article, an application configuration has the following characteristics:

• A set of simple or complex values that can affect an application's behavior
• Values can easily be changed without requiring any code deployment

With that out of the way, let's go to our list!

The "Configurables"

Here are the 8 items that should be configurable in your applications.

Magic Numbers

These are special numbers that are used in certain displays, validations, or business rules.

Examples:

• Number of days before an SLA (Service Level Agreement) is breached
• Number of decimal places when rendering a currency

URLs

When connecting to 3rd-party services, there's no knowing when their URLs will change. It's best to keep these values configurable. Additionally, configurable URLs can help you control the value in different environments.

Examples:

• API Endpoints
• External websites

Feature Toggle

This is helpful when there is a feature that's already in production, but which can only be enabled after a certain time.

An example of this is a feature that can only be enabled after a live stream event. Normally, this can be a Boolean value, but you can also use Date Time for this. This just means that the feature will automatically be enabled once that time has passed.

Regex Patterns

Some Regex patterns, especially those used in validation, have the potential to change regularly.

An example of this is phone number validation. Initially, your application might allow phone numbers from several countries. Then, perhaps a change in requirements came about where you now have to allow only phone numbers from specific countries.

If your validation pattern is in configuration, then you can quickly make this change.

Special Dates

Not the romantic ones! In some applications, there's a need to "block" certain dates from being selected by users.

A perfect example of this are public holidays. Since these dates can change regularly, they should be placed in configuration.

Connection Strings

Database connection strings should never be placed in your code! When you place connection strings in configuration, you'll also be able to set a different value per environment.

Formulas

For finance-related applications, making formulas configurable is very important. For these type of applications, adapting to policy or regulatory changes as soon as possible is a must.

Special Messages

This may be more applicable to non-CMS applications. In some cases, the regular changes in text messages are tied to legal or regulatory policies. Therefore, these messages should be easy to update.

A good example of this is an announcement that shows whether the application is currently facing any issues or is under maintenance.

Conclusion

These are the 8 items that I believe should be configurable in every application. I'm sure you have other items on your mind. Let me know! Looking forward to hearing from you.

Glad you reached the end of this article. I hope you learned something new from me today.

_Cover photo from Unsplash_

EditorConfig on its own is just a vendor-agnostic configuration file. It relies on third-party tools or integrations to implement support for the rules declared in the file.

They can be read by IDEs (Integrated Development Environments), code editors, or build tools to enforce or apply formatting conventions.

What Does EditorConfig Solve?

Users usually configure the code style settings in an editor to their preferences. Unfortunately, their preferences probably don't correlate with yours.

What happens when they're contributing to a shared project? This might be a project at work, or an open-source project on GitLab or GitHub.

The user's style settings get applied to the files they modify. This can result in projects feeling inconsistent or messy, with some or all of the following issues:

• Mixed use of tabs and spaces.

• Mixed use of line endings. (Usually not a significant issue with Git.)

• Files may not have the desired character encoding.

• Various indentation sizes across files.

Without consistency, the code can appear untidy and be a pain to read, depending on a user's development environment.

eclipse.jdt.ls mixes tabs and spaces, here's how it looks on GitHub with a tab size of 8.

A common solution is to share editor settings as part of the project, but this assumes all committers are using the same editor as you, which probably isn't the case.

For Java development alone, the following are all popular choices:

• Visual Studio Code (What I use!)

• Eclipse

• IntelliJ

• NetBeans

You'll bloat your project with unrelated files if you add the configuration for every editor someone might use.

So, how about a vendor-agnostic solution where editors are responsible for utilizing a shared configuration instead?

How EditorConfig Helps

Defining conventions helps everyone throughout a project's life-cycle. There are namely three ways it saves time.

EditorConfig Makes Code More Readable

Making code more readable is by far the most important reason to use it. This improves the maintainability of the project, and the speed that people can work.

“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code… Therefore, making it easy to read makes it easier to write.”
― Robert C. Martin

There are many other reasons someone might be reading the code outside of development too:

• Researchers that need to better understand how the project works.

• Security analysts that are checking for vulnerabilities.

• Technical writers that are documenting application behavior.

People will be able to perform their role more effectively if your code is kept tidy, consistent, and human-readable.

EditorConfig Makes Code Reviews Easier

As a project maintainer, you'll inevitably have to review code contributed by others. They might be a fellow team member, or open-source contributors that discover your project.

Enforcing formatting should be delegated to software. This will make reading and reviewing the code more efficient, and avoids the need to request changes based on formatting.

Reducing the feedback loop ultimately saves everyone time.

EditorConfig Makes Development Easier

Developers can save a lot of headache by having conventions that are automatically applied by their editor.

Without it, they have to find a contribution guide, style guide, or check other code manually to learn project conventions.

Even when the conventions are known, they may conflict with a developer's settings. Then they'll have to code against the editor's automatic formatting, or frequently change settings between projects.

This is especially useful for developers that jump between projects a lot. For example, open-source contributors frequently write code for projects across organizations that follow different coding conventions.

How EditorConfig Works

EditorConfig uses a simple INI-like file named .editorconfig. This file declares rules that will be translated to settings in your editor, or perform formatting over your workspace.

For example, in my editor I use 2-space indentations for XML files, but a project I contribute to might prefer 4-space indentations.

[*.xml]
indent_size = 4

When I open the project, my editor will see the .editorconfig file, and override the settings to suit the project's conventions.

Writing an XML file with my default editor settings. I use spaces for indentation with a size of 2.

Automatically reformatting the file after overriding the XML formatting settings.

How to Use EditorConfig

Depending on your editor of choice, it may have native support for EditorConfig already. There is a list of "No Plugin Necessary" editors on the website, which includes JetBrains IDEs and Visual Studio.

If your editor doesn't have native support, you'll likely be able to add it with a plugin. Editors like Visual Studio Code and Eclipse support it this way, which can also be found on the EditorConfig website under "Download a Plugin".

Once installed, your editor should automatically find the EditorConfig file in your project if it exists, and start applying the rules.

How to Define Rules in EditorConfig

You can find a list of rules on the EditorConfig Wiki. It contains all officially supported rules, as well as proposals for domain-specific rules that may be supported by certain implementations.

Not all implementations support every rule. This is especially true for domain-specific rules like curly_bracket_next_line. It can still be worth declaring these properties anyway for users that can utilize it, or to at least document the preference.

You must set root to true for the top level EditorConfig in the project, which is normally in the root of your project directory.

Additional EditorConfig files can be defined in nested directories, but shouldn't set root to true.

Then you can define a header that selects files, with rules for what to apply to matching files.

# Declares that this is the top-level configuration
root = true

# Applies to all files
[*]
indent_style = space
indent_size = 2

# Applies to all Markdown files
[*.md]
trim_trailing_whitespace = false

# Applies to all C# and Java files, overriding rules declared before
[*.{cs,java}]
indent_size = 4

There are no standard conventions for how to write an .editorconfig file, but there are two notable approaches you can take.

Define Rules Per Project

Just add to it as you need to. This means just defining rules, or appending file formats as your project grows.

You can start by generating the file with your editor, or just create a file named .editorconfig manually. You can copy-and-paste the example from the official website.

Define Rules for All Projects

Alternatively, you can put together all of your preferences and plan the ideal configuration for all files you might interact with.

You can work from scratch, or start with mine and make the necessary adjustments.

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
curly_bracket_next_line = false
spaces_around_operators = true

[*.bat]
end_of_line = crlf

[*.cs]
curly_bracket_next_line = true

[*.{cpp,cs,gradle,java,kt,py,rs}]
indent_size = 4

[*.{js,ts}]
quote_type = single

[*.md]
trim_trailing_whitespace = false

[*.tsv]
indent_style = tab

EditorConfig Rule Recommendations

These are rules I'd objectively recommend declaring, if your project contains the respective file format. It'll help you avoid tedious issues that can occur due to a user's development environment.

Batch

Line endings need to have a textual representation when stored. This is usually something you wouldn't see or have to worry about.

However, different systems use different characters to represent the end of a line. (More Info)

• Unix systems use a line feed. (lf or \n)

• Windows uses a carriage return and line feed. (crlf or \r\n)

Batch files can have unexpected behavior if they end with Unix line endings. You can avoid this by setting end_of_line to crlf to ensure they have Windows line endings instead. (More Info)

[*.bat]
end_of_line = crlf

Markdown

In Markdown, you can write a line break in the current paragraph by adding 2 spaces at the end of a line. (More Info)

You'll want to set trim_trailing_whitespace to false to avoid having your editor remove those spaces when you save.

[*.md]
trim_trailing_whitespace = false

Tab Separated Values

TSV (Tab Separated Values) files are very similar to CSV (Comma Separated Values), but use tabs instead of commas as the column delimiter.

It's very common for developers to have tabs automatically convert to spaces. You should set indent_style to tab to avoid the delimiter from being replaced, otherwise your entire table might become a single column.

[*.tsv]
indent_style = tab

Conclusion

If you're a maintainer, either working in a collaborative environment or in open-source, I strongly recommend adding an .editorconfig file defining the project's conventions to the root of your repository.

Maintainers can then spend more time reviewing clean pull requests that adhere to the style guide, as the editor will automatically start enforcing or applying the conventions.

Committers get a better experience, as the project will override their workspace settings. This reduces the need to reformat code or work against preconfigured editor settings.

And projects will be cleaner, as the conventions will be in a single vendor-agnostic file, rather than editor-specific files that only certain contributors can use anyway.