Git 101: basic cheat-sheet

In this post I'll just talk about a few commands to be able to work in a team's repository.

Clone repository

git clone <repository_link>

Shows files not included (untracked files), modified files (not staged), and modified files in the staging area (in the staged area, changes to be committed)

git status

in simpler words, 3 types of files

• not tracked (git add for include it)

• modified, tracked by git, not included (git add for include it)

• modified, tracked by git, included if you do "git commit -m 'something...' "

Check which git branch you are on

git branch

List all branches

git branch -a

Switch to existing branch (existing branch)

git checkout <branch_name>

Now let's suppose we are in main, and we have to create a new branch based on it

git checkout -b "new_branch_name"

This creates and switches to this new branch new_branch_name, and it will be a clone of the branch in which you executed the command, in this case main.

Add all the changes to the staging area

git add .

You can also add a specific file to the staging area

git add </path/to_your_file>

Makes the staged changes into a commit with the message 'commit message'

git commit -m 'commit message'

Upload the commits into GitHub, GitLab, or the git provider you're using

git push

Now if there are new changes in eg main (normally)

git pull origin main

You need to update your branch with the main branch to avoid conflicts:

# go to main
git checkout main

# bring new changes from GitHub (update branch)
git pull

# go to your branch
git checkout <your_branch>

# merges your branch with main
git merge main

Show the history of commits

git log

git log shows the:

• branch

• commit hash

• author

• date

• commit message

Go to specific commit (you can get the commit hash from the git log command)

git checkout <hash>

Now my favorite: GIT STASH, wait, it isn't the same that the staging area. The git stash grabs all the files in the staging area and saves them on a separate place. Let's suppose you modified two files, when you do git stash the changes are stored into a stash stash@{0} that you can retrieve later. Tu sum up:

# add files changed to staging area (in this example all)
git add .

# stash them
git stash

# stash with message
git stash push -m 'stash message'

# list the stashes
git stash list

[this will display something like this]:
stash@{0}: WIP on ...
stash@{1}: ...
stash@{2}: ...

# retrieve specific stash
git stash appyl stash@{0}

# delete stash
git stash drop stash@{0}

# remove a single stashed state from the stash list and apply it
git stash pop stash@{0}

Conventions

There is a commit message convention which says that we should use the following prefixes

• fix: a commit that patches a bug in your codebase

• feat: a commit that introduces a new feature to the codebase

• BREAKING CHANGE: when introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type. eg BREAKING CHANGE: use JavaScript features not available in Node 6

• "!": draws attention to breaking change eg feat!: send an email to the customer when a product is shipped

• scope (): eg feat(client): login with firebase or feat(lang): add Polish language

Bibliography

• Conventional Commits

• Git Stash Documentation