Git commands - for setup and daily work

 This article is just to collect some of the Git commands that are being used on a regular basis.

Git commands for daily work

git clone <https link to repo> (clone a remote repo. Make sure you’re in the correct directory when running)

git pull (sync the latest changes from remote repo)

git checkout -b feature/new_branch_name (create new feature branch)
git switch -c feature/new_branch_name (create new feature branch)

git checkout main (switch to main branch)
git switch main (switch to main branch)

git add -A (pre-commit/stage command to add all new/modified/deleted files to local staging for whole repo, run this before local commit)

git add . (same as -A but for current directory and sub directories only)

git add -u (stages all modified and deleted files but leaves new and untracked files)

git commit -a -m "adding a test file" (commit all files to local branch and add a message)

git push --set-upstream origin feature/testingbranch (publish local branch to remote repo, use the same name as the current feature branch)

The git push command can be simplified further, see below around the push.autoSetupRemote setting (then you can just use git push).

git add -A && git commit -a -m "adding a test file" (combine git add and git commit and run sequentially)

git checkout main && git pull (combine switch to main branch and run git pull)

git branch -d localBranchName (delete local branch)

git push origin --delete remoteBranchName (delete branch remotely)

git branch -l (list local branches)

git branch --all (see all branches including remote)

Undo last commit

If you've pushed a local repo to a remote repo and also created a PR in e.g. Azure DevOps, you can undo the last commit, make some changes or remove/add files and re-push the changes:

git reset --soft HEAD~1 (undo last commit)

git add -A (run this after changes have been made to re-stage)

git commit -a -m "updated commmit message"

git push --force (this will overwrite the remote branch history. If you don't use --force it will throw an error that remote branch is ahead)

Load everything from remote branch and overwrite local branch

git switch my-local-branch

git fetch origin

git reset --hard origin/my-remote-branch

Git commands configuring Git

git config --global user.name "First Last" (user name and email should be set up as a one time config)

git config --global user.email <user@email.com>

git config --global core.longpaths true (fixes an error with long path names)

git config --list (show git config)

git config --list --show-origin (show git config including where variables are defined)

git config --global http.https://dev.azure.com/.proxy https://someaddress (this is a proxy related setting)

git config --global http.https://dev.azure.com/.proxyauthmethod negotiate (this is a proxy related setting)

git config --global http.https://dev.azure.com/.emptyAuth true (this is a proxy related setting)

git config --global --edit (edit the global config file in VI editor)

git config --global --replace-all user.name "username" (replaces current user name)

git config --global --replace-all user.email <user@email.com>

git config --unset-all credential.helper (unset named settings)

git config --global --set credential.helper (set the credentials helper type)

Note, that if you set push.autoSetupRemote to true with the below command, it is enough to just run: git push and you don't have to specify (--set-upstream origin feature/testingbranch) and it will automatically create a remote branch with same name as current local branch and enable tracking, see more info here:   

git config --global --add --bool push.autoSetupRemote true

   

Deploying Terraform in Azure using Github Actions workflow

 This article will summarise the steps I went through to set up Github Actions with a private repo to be able to push Terraform code from VS Code to Github and then to Azure.

It is based on a great article by Guillermo Musumeci and if you want to replicate this setup, that is the guide you should follow, see article.

The overall steps are as follows:

• Create a Service Principal (SPN) with contributor permissions
• Create a storage account and a container (this is used to hold the backend state and is created up front. I did this via AZ CLI but any method, such as via the Azure Portal, will do)
• Create a Private Repo in Github
• From VS Code, clone the repo to your local machine
• Add 4 x secrets to Github under your private repo: Repo -> Settings -> Secrets -> Actions -> New Repo Secret (these secrets contain the SPN info so that Github Actions can authenticate towards Azure
• Create providers.tf, variables.tf, outputs.tf files according to article mentioned above. And a main.tf file that just contains a resource group to get started
• Create Github Actions workflow using a simple Terraform YAML pipeline file

These are the base steps. From now on when you create a pull request (PR), the workflow will start and will run terraform init, plan, and apply and if there are no issues the code will be pushed. It doesn't wait for you to complete the PR though but you can do that as the last step.

Under Actions, you can see the status of all the workflow runs (it looks quite similar to a push pipeline run in Azure DevOps):

In the repo I have just placed all the files in the root folder. This works but can likely be organised better as the amount of files grow, see below:

I ran into two minor issues, these were:

An error message saying the following:

"Error message: state blob is already locked" and "Terraform acquires a state lock to protect the state from being written by multiple users at the same time. Please resolve the issue above and try again. For most commands, you can disable locking with the "-lock=false" flag, but this is not recommended."

I tried updating the pipeline file to include the -lock=false under the "terraform plan" command but that didn't work. For some reason I had a lock on the state file in the storage account that was created earlier. From the Azure Portal, you can navigate to the file in the blob container and from there remove the lock (or break the lease, is the terminology, see screenshot below). After doing this, there has been no more issues with the lock.

The other issue I ran into was that when I tried to deploy the first resource, the workflow was hanging for a long time and it was unclear what was holding it up.

It turns out that it was waiting for the Microsoft.DocumentDB resource provider to be registered. This is a one time thing that is done on the under the subscription under Resource Providers (it specifies which resource types are allowed and not all resource types are allowed by default). I would recommend to just go and enable/register it manually before running the Actions workflow (it takes some time for it to register, maybe 30-40 mins).

Once this was in place the workflow has been running smoothly and any errors has been related to my code but the error messages have been pretty clear so it has been easy to address.

That's it. It may seem like a lot initially, but if you take step by step, it's not that bad. And the final setup is quite cool and useful.