{ "uuid": [ { "value": "042e4d0c-f835-47dd-8075-745df0a7f8f2" } ], "langcode": [ { "value": "en" } ], "type": [ { "target_id": "daily_email", "target_type": "node_type", "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7" } ], "revision_timestamp": [ { "value": "2025-05-11T09:00:57+00:00" } ], "revision_uid": [ { "target_type": "user", "target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849" } ], "revision_log": [], "status": [ { "value": true } ], "uid": [ { "target_type": "user", "target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849" } ], "title": [ { "value": "How I've configured Git" } ], "created": [ { "value": "2022-08-24T00:00:00+00:00" } ], "changed": [ { "value": "2025-05-11T09:00:57+00:00" } ], "promote": [ { "value": false } ], "sticky": [ { "value": false } ], "default_langcode": [ { "value": true } ], "revision_translation_affected": [ { "value": true } ], "path": [ { "alias": "\/daily\/2022\/08\/24\/2022-08-24", "langcode": "en" } ], "body": [ { "value": "\n

After yesterday's post on why I prefer using Git on the command line rather than using a GUI tool, today I thought that I'd post about how I've configured Git.<\/p>\n\n

First, I rarely ever run the git<\/code> command - I usually run a g<\/code> function that I've created within my zsh configuration.<\/p>\n\n

Rather than being an simple alias, it's a shell function that will run git status -sb<\/code> to show the current status of the repository if there are no additional arguments. If there are, such as when running g add<\/code>, then this is executed as a normal Git command. (This is something that I first saw from Thoughtbot, if I remember correctly).<\/p>\n\n

Using .gitconfig<\/h2>\n\n

The main part of my configuration is within Git's ~\/.gitconfig<\/code> file, where I can configure Git to work how I want.<\/p>\n\n

For example, I like to avoid merge conflicts, so I always want to use fast-forward merges whilst pulling and also to rebase by default. I can do this by adding ff = only<\/code> and rebase = true<\/code> to the [pull]<\/code> section of my ~\/.gitconfig<\/code> file.<\/p>\n\n

I can do this manually, or running git config --global pull.rebase true<\/code> will set the option but also update the file automatically.<\/p>\n\n

Some of the tweaks that I've made are to only allow fast-forward merges by adding merge.ff = only<\/code>, automatically squash commits when rebasing by setting rebase.autosquash = true<\/code>, and automatically pruning branches by adding fetch.prune = true<\/code>.<\/p>\n\n

Simple aliases<\/h3>\n\n

Another way that I configure Git is using aliases, which are also within the ~\/.gitconfig<\/code> file.<\/p>\n\n

For example, if I ran git config --global alias.b \"branch\"<\/code>, then running git b<\/code> would just run git branch<\/code> which shortens the command and saves some time and keystrokes.<\/p>\n\n

I have similar one- or two letter \"short\" aliases for pushing and pulling code, and some that also set some additional arguments such as aa<\/code> for add --all<\/code> and worktrees<\/code> for worktree list<\/code>.<\/p>\n\n

More complicated aliases<\/h3>\n\n

Aliases can be more complex if needed by prefixing it with a !<\/code>, meaning that it executes it as a shell command.<\/p>\n\n

This means that I can have repush = !git pull --rebase && git push<\/code> to chain two separate Git commands and combine them into one, and ureset = !git reset --hard $(git upstream)<\/code> which executes the full command, including another alias as part of it.<\/p>\n\n

I also have issues = !gh issue list --web<\/code> and pulls = !gh pr list --web<\/code> to open the current repository's GitHub issues or pull requests respectively, which can be done as it's not limited to just running git<\/code> commands.<\/p>\n\n

Custom functions<\/h3>\n\n

Finally, if an alias is getting too long or complex, then it can extracted to it's own file.<\/p>\n\n

Any executable file within your $PATH<\/code> that starts with git-<\/code> will automatically become a Git command.<\/p>\n\n

One example that I have is git-cm<\/a> which, similar to the g<\/code> function`, is a bash script that checks for any arguments passed to it and runs a slightly different command. It achieves the same thing as if it were an alias, but it does make it easier to write and maintain as it's in a separate file.<\/p>\n\n

These are just some examples. If you want to see my entire configuration, then check out my dotfiles repository on GitHub<\/a>.<\/p>\n\n

How have you configured Git for your workflow? Reply to this email and let me know.<\/p>\n\n ", "format": "full_html", "processed": "\n

After yesterday's post on why I prefer using Git on the command line rather than using a GUI tool, today I thought that I'd post about how I've configured Git.<\/p>\n\n

First, I rarely ever run the git<\/code> command - I usually run a g<\/code> function that I've created within my zsh configuration.<\/p>\n\n

Rather than being an simple alias, it's a shell function that will run git status -sb<\/code> to show the current status of the repository if there are no additional arguments. If there are, such as when running g add<\/code>, then this is executed as a normal Git command. (This is something that I first saw from Thoughtbot, if I remember correctly).<\/p>\n\n

Using .gitconfig<\/h2>\n\n

The main part of my configuration is within Git's ~\/.gitconfig<\/code> file, where I can configure Git to work how I want.<\/p>\n\n

For example, I like to avoid merge conflicts, so I always want to use fast-forward merges whilst pulling and also to rebase by default. I can do this by adding ff = only<\/code> and rebase = true<\/code> to the [pull]<\/code> section of my ~\/.gitconfig<\/code> file.<\/p>\n\n

I can do this manually, or running git config --global pull.rebase true<\/code> will set the option but also update the file automatically.<\/p>\n\n

Some of the tweaks that I've made are to only allow fast-forward merges by adding merge.ff = only<\/code>, automatically squash commits when rebasing by setting rebase.autosquash = true<\/code>, and automatically pruning branches by adding fetch.prune = true<\/code>.<\/p>\n\n

Simple aliases<\/h3>\n\n

Another way that I configure Git is using aliases, which are also within the ~\/.gitconfig<\/code> file.<\/p>\n\n

For example, if I ran git config --global alias.b \"branch\"<\/code>, then running git b<\/code> would just run git branch<\/code> which shortens the command and saves some time and keystrokes.<\/p>\n\n

I have similar one- or two letter \"short\" aliases for pushing and pulling code, and some that also set some additional arguments such as aa<\/code> for add --all<\/code> and worktrees<\/code> for worktree list<\/code>.<\/p>\n\n

More complicated aliases<\/h3>\n\n

Aliases can be more complex if needed by prefixing it with a !<\/code>, meaning that it executes it as a shell command.<\/p>\n\n

This means that I can have repush = !git pull --rebase && git push<\/code> to chain two separate Git commands and combine them into one, and ureset = !git reset --hard $(git upstream)<\/code> which executes the full command, including another alias as part of it.<\/p>\n\n

I also have issues = !gh issue list --web<\/code> and pulls = !gh pr list --web<\/code> to open the current repository's GitHub issues or pull requests respectively, which can be done as it's not limited to just running git<\/code> commands.<\/p>\n\n

Custom functions<\/h3>\n\n

Finally, if an alias is getting too long or complex, then it can extracted to it's own file.<\/p>\n\n

Any executable file within your $PATH<\/code> that starts with git-<\/code> will automatically become a Git command.<\/p>\n\n

One example that I have is git-cm<\/a> which, similar to the g<\/code> function`, is a bash script that checks for any arguments passed to it and runs a slightly different command. It achieves the same thing as if it were an alias, but it does make it easier to write and maintain as it's in a separate file.<\/p>\n\n

These are just some examples. If you want to see my entire configuration, then check out my dotfiles repository on GitHub<\/a>.<\/p>\n\n

How have you configured Git for your workflow? Reply to this email and let me know.<\/p>\n\n ", "summary": null } ], "feeds_item": [ { "imported": "1970-01-01T00:33:45+00:00", "guid": null, "hash": "4d3892ad51836bdd33e47e7043615d75", "target_type": "feeds_feed", "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76" } ] }