refresh on Git basic commands
A topical cheatsheet refresher on vital Git basic commands with embedded links as resources for contextual explanations and visuals. Hopefully, this is a more accessible and associative reference in understanding and remembering how these git commands are used. Intended for career changers coming out of Bootcamps like myself.
Updating the main branch with changes from my text editor aka VSC:
- git add . *initiate the changes in the directory at a snapshot like a photo in the staging/staged area before it is finally updated to the remote repository with this git commit command.
- git commit -m “[write in concise update message of that file]” ***make the language concise for other developers to access and understand…***
- git push *this git command send changes from the local repository/environment to remote repository to be updated in git commits.
When to use git init versus git clone:
- git init command can be done both locally on your computer or remotely/in the cloud on GitHub.com is best when starting up a new repository aka repo
- git clone is when we take GitHub’s HTTP or SSH link to clone the repo into our local text editor to begin working on files of an application and its projects aka an already existing repository that is worked on
- Read more on git init
Implement & Change/Update globally the git configurations’ user’s name and e-mail (can be done both globally and locally) with the following commands:
- git config- -global user.name “name”
- git config- -global user.email “email@example.com”
- When working with GitHub, our name and e-mail are what will help track these changes. Here is a tutorial that covers setting up Git on your local machine at the timestamp of 4:16.
- We want to be able to track all the changes done by us and who made what changes when collaborations in our environment.
- enter git config -l **-l means “list” to make sure our machine will display all settings, currently.
Saved Changes and a glimpse of tracking those changes:
- git log command tracks all the git commits starting with the most recent commit listed first in that descending order
- git reflog command only track and highlights the one and most recent commit
- git diff command aims at revealing comparisons with commits, branches, a single file across revisions of branches, etc. or just between what is a snapshot of commits between the working and staging areas
- git status command reveals the state of the working directory and the staging area, except for the project’s history commits, so for that use git log command. Otherwise, the git status command displays staged, unstaged, and untracked files.
More best practices to know:
- .gitignore tells us which file we do not want under version control
Getting started with Git, GitHub & GitHub Desktop: The Coder Coder (YouTube) provides a thorough and topical explanation for beginners about Git, Github, and GitHub Desktop when managing Git workflow in these various actions from creating commits and publishing to the remote repository to ignoring files, updating files, deleting files, reverting commits, branching and pull requests. This tutorial is digestible and concise to take it all in. Length time: 22 minutes and 15 secs
Git alert: no longer using username and password when accessing Github from the Git command line. To best secure the account, we are encouraged to activate or use “Personal Access Tokens,” aka PATs with Git and GitHub. Ed Goad’s Youtube tutorial is a walkthrough on setting up these tokens. Along the way, I update my global email using this git command, “git config user.email
- GitHub Docs: Creating a personal access token documentation walkthrough
- PATs “are an alternative to using passwords for authentication to GitHub when using the GitHub API or the command line” (GitHub Docs)
- PATs can be customized on who and when the repository is accessed. For security purposes, when can set an expiration date on PATs. (GitHub Docs)
- Most importantly, “GitHub automatically removes personal access tokens that haven’t been used in a year” (GitHub Docs)
Finally, I hope this blog serves as a starter kit, sort of to understand the git commands better as purposeful tools in our documentation processes and especially when we collaborate with other engineers. I hope to compose another blog with a deeper dive on different occasional usage with git log.