When you’re working with Infrastructure as Code (IaC) you’ll likely be using some sort of version control system. If not, it’s something you should strongly consider getting comfortable with if you’re going to improve your skills as a Cloud Engineer.
When you’re working with an enterprise codebase, chances are that most repos will already exist so you simply have to clone them. If a new repo does need to get created, it’s typically done in the GUI and cloned via your terminal. Every company is different, so take that with a grain of salt. However, in my experience, knowing how to perform these 10 git commands are roughly about 85% of what you need to know how to do on a daily basis.
Here are 10 git commands you should know as a cloud engineer:
1. git clone
If you need to work with a repository that you don’t have on your local workstation you’ll need to download it using this command. Cloning the repo will include every single branch, file, and commit history onto your workstation. There are two main methods to clone a repo; https and ssh.
Cloning a repo using https will require you to enter a username and password so it’s the more onerous method. This is the less common approach of the two methods.
SSH is typically the preferred method since it allows you to clone repos without providing a username and password. Instead, you will need to generate a ssh key pair on your workstation. Your private key will be stored on your workstation and the public key will be uploaded to your version control system.
#https method
git clone https://bitbucket.org/atlassian_tutorial/helloworld.git
#ssh method
git clone git@bitbucket.org:atlassian_tutorial/helloworld.git
###
2. git checkout
There are three ways I use this command most often in my role:
- Switching between branches
- Creating a new branch
- Reverting an un-staged modified file back to most recent commit
Command, ‘git checkout’, is most commonly used to switch between various branches. Adding a ‘-b’ flag to your command will create a new branch if it doesn’t already exist. However, this will transfer any modified changes in your current working directory over to that new branch. Therefore, perform a ‘git status’ to ensure you don’t carry over any unintentional changes.
Say you’re working on a file but later decide that you want to revert everything back to its original version. If you didn’t add that file to your staging area yet, you can simply perform a ‘git checkout filename.txt’ and it will revert that file back to the most recent committed version.
#Switching to a new existing branch
git checkout feature/another-branch
#Creating a new branch
git checkout -b feature/my-new-branch
#Reverting a modified file back to most recent commit
git checkout my-file.txt
###
3. git status
This command is useful because it provides an overview of any new files that have been added, deleted, staged, and so forth. Not sure if you added a file to your staging area or see one that you added by mistake? This command is useful in those cases.
#Get overview of working repo
git status
###
4. git diff
This command allows you to compare changes between different file versions. Hit your spacebar to expand the list of changes you made and ‘q’ to exit viewing your changes.
#Display differences between modified files and previous commit
git diff
###
5. git add
Once you’ve made a change to a file you need to add it to your staging area before they can be committed. You can add any modified files all at once or list specific files separated by a space.
# Add all new files to be tracked in your staging area
git add .
# Add specific files to be tracked in your staging area
git add file1.txt file2.txt
###
6. git commit
Once you have files in your staging area, this command is ran to create a snapshot of those changes. As a good practice it is good to follow some form of convention when making your commit messages.
If the ‘-m’ flag isn’t specified in your commit command, a text editor in your terminal window will appear prompting you to enter a message. Passing this flag in will allow you to enter your commit message in a single command.
If your company enforces a standard for commit messages, it’s possible for your commit to get rejected when attempting to push it to your remote branch. When that occurs, the ‘git commit –amend’ command allows you to easily correct your commit message so it is accepted by the remote server.
#Create snapshot of staged files.
git commit
#Commit all changes in working directory
git commit -a
#Commit changes passing in a commit message
git commit -m "feat: init commit"
#Commit all changes in working directory with message
git commit -am "feat: init commit"
#Modify message from previous commit
git commit --amend
###
7. git pull
This command performs the same thing as ‘git fetch’, which retrieves tags and remote branches. However, this command also downloads the latest changes from the remote branch and merges them into your local branch.
#Pull changes from remote branch
git pull
###
8. git push
Just because you commit something, doesn’t mean those changes will be seen in your remote branch for others to see. You’ll need to push your changes for that to happen. Performing a ‘git push’ immediately after creating a new branch without any changes will simply create a new remote branch.
#Performed after you've committed your changes
git push
###
9. git merge
This command is mostly used to merge two feature branches together or merging upstream changes in the master branch into a feature branch. In my experience, it will be rare for you to merge a feature branch directly into master using this command. That will likely be done from the web GUI.
#Merge master to current feature branch
git merge master
###
Say you’re working on a feature branch cut from master. There’s a good chance master could develop new changes that’s missing in your feature branch from when it was cut. Ensuring your feature branch is up-to-date with upstream changes to master will prevent you from encountering merge conflicts when you’re ready to merge your pull request.
To update your feature branch with upstream changes from master, checkout master and pull the latest changes. Next, switch to your feature branch and merge the changes from master to it. If Git can’t merge something it’ll create a merge conflict which will need to be fixed before you can continue. Once you’ve fixed any merge conflicts commit and push your changes to your remote feature branch.
#git merge method
git checkout master
git pull
git checkout feature/my-branch
git merge master
git push
###
There is another git command called, ‘git rebase’ that can also update a branch with upstream changes from another branch. However, the ‘git merge’ method is typically the safer method since it preserves the commit history. The ‘git rebase’ method overwrites commit history.
Refer to the merging versus rebasing article for a more in depth explanation between the two and knowing when not to rebase.
10. git log
This command is used to look at a list of commit messages associated with the branch you’re on. Commonly used to ensure the working version of a repo on your local workstation matches with another person’s branch or with a remote branch.
#Display list of commits
git log
#Displays shortened commit messages
git log --oneline
###
Sample Workflow
Now that we’ve gone through our git commands, let’s try to piece everything together and see what a typical git workflow looks like:
#Start
#Clone a new remote repo onto local workstation
git clone git@bitbucket.org:atlassian_tutorial/helloworld.git
#Ensure you're on the master branch
git checkout master
#Create a new feature branch
git checkout -b feature/my-feature
#Do development work here and commit all changes
git commit -am "feat: added new feature"
#Push changes
git push
#Create pull request from web GUI
#Modify PR based on comments received
git commit -am "feat: addressing PR comments"
#Push new changes
git push
#Comments addressed and approvals obtained
#Merge your PR from GUI
#End