Optimize Your Git Setup: Strategies for Handling Multiple GitHub Accounts

Jorge Sisco — Sun, 07 Apr 2024 16:58:02 +0000

You can easily configure Git settings for each repository you work on or globally for all repositories on your machine. For detailed instructions, refer to the official GitHub documentation on setting your username in Git.

If you're looking for a customized solution to set your Git configuration based on the working directory, I recommend the following approach:

Home Directory Structure for .gitconfig Files

In your home directory ~/, you should have the main .gitconfig file along with two additional configuration files: .gitconfig_personal and .gitconfig_work. These files are structured as follows:

~/
├── .gitconfig
├── .gitconfig_personal
└── .gitconfig_work

In your .gitconfig file, you will define conditions for each GitHub account's information. The configuration should appear as follows:

[gpg]
    format = ssh
[gpg "ssh"]
    program = /Applications/1Password.app/Contents/MacOS/op-ssh-sign
[commit]
    gpgsign = true

[includeIf "gitdir:~/work/"]
    path = .gitconfig_work
[includeIf "gitdir:~/dev/"]
    path = .gitconfig_personal
[core]
    excludesfile = ~/.gitignore_global

The gitdir can be any directory you decide to use with one exception:

If you're using any cloud file management services like iCloud Drive or any similar cloud storage solution, it's important to be cautious about where you place your git repositories. Initiating a git repository within a directory that is being synchronized to the cloud can lead to significant and frustrating complications.

The section titled [gpg] in the configuration is used for scenarios where you plan to utilize SSH for authentication purposes and for signing commits via the 1Password Command Line Interface (CLI). However, configuring this section is optional.

For both .gitconfig_personal and .gitconfig_work the setup should be the following:

[user]
    name = <github_username>
    email = <github_email>
    signingkey = <ssh_public_key> # Optional

Setting Up Git SSH Authentication for Multiple GitHub Accounts [Optional]

If you're looking to use SSH keys for authentication with GitHub via the 1Password CLI, it's essential to configure your SSH settings properly. This involves adding a specific host configuration for each GitHub account in the ~/.ssh/config file to differentiate between your work and personal accounts. Here's how to do it:

Prerequisites

Ensure you have generated SSH keys for both your GitHub accounts. If you haven't done so, follow GitHub's documentation on creating SSH keys. You should have two separate public keys, one for each account.

Configuring SSH for Multiple GitHub Accounts

Open your SSH configuration file: Use a text editor to open ~/.ssh/config. If the file doesn't exist, you can create it.

Add the SSH configuration for each account

You'll need to specify a custom host for each GitHub account, as shown in the example below. Replace public_key_gh_work_ed25519.pub and public_key_gh_personal_ed25519.pub with the actual filenames of your SSH public keys.

# Work account
Host work.github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/public_key_gh_work_ed25519.pub

# Personal account
Host personal.github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/public_key_gh_personal_ed25519.pub

Reference Docs

After setting up your Git configurations and SSH keys for different GitHub accounts, incorporating the GitHub CLI and 1Password CLI into your workflow can further optimize your development process, making it more secure and efficient.

GitHub CLI

The GitHub CLI (gh) is a powerful tool that extends GitHub functionalities to your terminal, allowing you to script and automate various GitHub actions without leaving your command line. Whether you're working with issues, pull requests, repositories, or GitHub Actions, gh offers a seamless way to manage them.

For detailed instructions on how to install, configure, and use the GitHub CLI, refer to the official GitHub CLI documentation. It provides comprehensive guides on getting started, command references, and how to perform common GitHub operations directly from your terminal.

1Password CLI

The 1Password CLI provides a secure and convenient way to manage your passwords and secrets, including SSH keys for Git authentication, directly from the command line. By integrating the 1Password CLI with your Git setup, as shown in the [gpg "ssh"] configuration section of your .gitconfig, you can enhance the security of your Git operations. This is especially useful for signing commits or accessing multiple SSH keys securely without having to store them unencrypted on your filesystem.

To get started with the 1Password CLI, visit the official 1Password CLI documentation. Here, you'll find installation guides, usage examples, and how to integrate it with various tools and workflows, including Git and SSH authentication.

By leveraging these CLI tools, you can streamline your development process, manage your GitHub activities more efficiently, and secure your Git operations with advanced authentication and encryption methods. These integrations not only save time but also reinforce the security and management of multiple identities and repositories.

Simplifying Serverless: Custom Domains with AWS SAM

Jorge Sisco — Thu, 22 Feb 2024 11:59:35 +0000

When deploying a Serverless Application Model (SAM) with events that trigger functions via a serverless API gateway, using the default API URL provided by Amazon might not be ideal for your clients.

Example of Default Invoke Base URL:

https://afjdkwosp3.execute-api.eu-central-1.amazonaws.com/dev

Adding a custom domain enhances the appearance of your service, making it more user-friendly.

Setting the Custom Domain in Your SAM `template.yaml`

Your yaml file for the API will look like this:

MyApi:
  Type: AWS::Serverless::Api
  Properties:
    StageName: !Ref Environment
    DefinitionBody:
      Fn::Transform:
        Name: AWS::Include
        Parameters:
          Location: api/swagger-integrated.yaml
    Domain:
      DomainName: !Sub ${APISubDomainName}.${DomainName}.com
      CertificateArn: !Sub arn:aws:acm:${AWS::Region}:${AWS::AccountId}:certificate/${ACMIDENTIFIER}
      SecurityPolicy: TLS_1_2
      BasePath: '' # Base path replaces stage name; if it's '', you don't have to add the stage name in the endpoints.

To incorporate dynamic values in your template, define DomainName, APISubDomainName, and ACMIDENTIFIER in the parameters section as follows:

Parameters:
  DomainName:
    Type: String
    Default: <your-domain>
  APISubDomainName:
    Type: String
    Default: api
  ACMIDENTIFIER:
    Type: String
    Default: e242ea60-359f-4c49-b052-b9ce6d533cd4

Alternatively, you can avoid hardcoding by omitting the Default values for parameters and add them through the samconfig.toml file. However, our focus here is on establishing a custom domain name for the API.

AWS Certificate Manager

Before deploying our SAM, we must complete a few preparatory steps:

Import your domain `SSL` certificate to ACM

This process will provide you with your ACMIDENTIFIER, which you can then include in your template.yaml.

Note: It's also necessary to provide the certificate chain to ensure successful SSL certificate verification for requests. Failing to do so might require disabling verification to achieve successful API requests.

Configure the Domain Name to your Rest API

In your domain registrar's panel, add a new CNAME record in your DNS settings that points to your API Gateway's domain name.

Note: The API Gateway's domain name is different from the Invoke URL. This URL can be found in:

Deploy your SAM

You are now ready for deployment. However, be aware that DNS settings changes may take up to 48 hours to propagate fully. Use a DNS checker to confirm the CNAME's propagation and to ensure the configuration is correct. Once verified, your API will be accessible via the custom domain.

DEV Community: Jorge Sisco