Essentially, Git keeps tabs on text changes, but the definition is a version control system. Chances are you've already used git one way or another: it is a de-facto standard for code versioning due to it's distributed nature, as opposed to centralised Apache Subversion (SVN).
Installing Git
To check if you have Git installed run in your terminal:
git version
# git version 2.30.1 (Apple Git-130)
If you don't have it, follow instructions on https://git-scm.com/downloads. Mac users can install it with brew: brew install git
Configuring Git
There are just a few things we want to configure:
git config --global user.name "John Doe" && # your name
git config --global user.email johndoe@example.com && # your email
git config --global init.defaultbranch main # default branch name, to be compatible with GitHub
You can see current global configuration with:
git config --global --list
# Type ":q" to close
Git stores configuration in plain text and, if you prefer, you can edit global configuration directly in ~/.gitconfig or ~/.config/git/config.
As the command suggests, removing --global would make these commands scoped to the current folder. But to test that out we need a repository.
Creating new repository
A repository is just a folder with all the stuff you want to track. To create one run:
mkdir gitexample &&
cd gitexample &&
git init
# gitexample git:(main)
This command creates a folder .git inside gitexample folder. That hidden .git folder is what makes a repository: all local configuration and changes are stored there.
Making changes
Let's create something in the repository:
echo "Hello, Git" >> hello.txt
If we ran git status, we'll see the newly created untracked file:
git status
# On branch main
#
# No commits yet
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
# hello.txt
#
# nothing added to commit but untracked files present (use "git add" to track)
As the output suggests, let add the file. It can be done directly with:
git add . # Or `git add hello.txt`, if we don't want all files
If you check on the repository status now, you'll see that the file is added (aka staged), but not yet committed:
git status
# On branch main
#
# No commits yet
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
# new file: hello.txt
To record the changes, let's commit them:
git commit -m "Add hello.txt"
# [main (root-commit) a07ee27] Adds hello.txt
# 1 file changed, 2 insertions(+)
# create mode 100644 hello.txt
Pro tip: git commit -m <MESSAGE> is a short hand command, you can use git commit to open editor (mostly vim) and provide a detailed commit description instead.
Let's check the changes with:
git log
# type :q to close
It will show something like:
commit a07ee270d6bd0419a50d1936ad89b9de0332f375 (HEAD -> main)
Author: Your Name <your@email.address>
Date: Sun Jul 11 11:47:16 2021 +0200
Adds hello.txt
(END)
Creating branches
Having a separate version of the initial code can be useful in a lot of situation: e.g. when testing out a feature you're unsure about or to avoid code conflicts when working together. That's exactly what a git branch is: it grows from a particular point in history.
To create a branch run git branch NAME and to switch branch run git checkout NAME. Or simply:
git checkout -b dev # switches to a new branch called "dev"
# Switched to a new branch 'dev'
# gitexample git:(dev)
Let's change something in the hello.txt file and commit the changes:
echo "\nHello, Git Branch" >> hello.txt &&
git commit -am "Change hello.txt"
Now let's switch back to main version:
git checkout main &&
cat hello.txt
# Switched to branch 'main'
# Hello, Git
As you can see, the file contents are still the same as they were. To compare branches we can run:
git diff dev
# diff --git a/hello.txt b/hello.txt
# index 360c923..b7aec52 100644
# --- a/hello.txt
# +++ b/hello.txt
# @@ -1,3 +1 @@
# Hello, Git
# -
# -Hello, Git Branch
# (END)
# type ":q" to close
Let's make changes in main branch as well:
echo "\nHi from Main Branch" >> hello.txt &&
git commit -am "Change hello.txt from main"
# [main 9b60c4b] Change hello.txt from main
# 1 file changed, 2 insertions(+)
Now let's try to combine the changes:
git merge dev
# Auto-merging hello.txt
# CONFLICT (content): Merge conflict in hello.txt
# Automatic merge failed; fix conflicts and then commit the result.
Because the file was changed in the same place twice we got a conflict. Look at the file:
cat hello.txt
<<<<<<< HEAD
Hello, Git
Hi from Main Branch
=======
Hello, Git
>>>>>>> dev
There is also a tool to see changes separately:
git diff --ours # :q to close
git diff --theirs #:q to close
You can manually edit the file and commit the changes, but let's imagine we only want one of the versions. We'll start with aborting merge:
git merge --abort
And restarting merge with "theirs" strategy, meaning that in case of conflict we'll use whatever incoming branch insists on:
git merge -X theirs dev
# Auto-merging hello.txt
# Merge made by the 'recursive' strategy.
# hello.txt | 5 +----
# 1 file changed, 1 insertion(+), 4 deletions(-)
The opposite to this strategy is "ours". Merging both changes together will require manual editing (or use of git mergetool).
To see list of all branches run:
git branch # type :q to close
# dev
# * main
Finally, to delete the branch run:
git branch -d dev
# Deleted branch dev (was 6259828).
Rebasing branches
Branches "grow" from a particular point in git history, rebase allows to change that point. Let's create another branch and add some changes to hello.txt once more time:
git checkout -b story &&
echo "Once upon a time there was a file">>story.txt &&
git add story.txt &&
git commit -m "Add story.txt"
# Switched to a new branch 'story'
# [story eb996b8] Add story.txt
# 1 file changed, 1 insertion(+)
# create mode 100644 story.txt
Now, let's come back to the main branch and add changes there:
git checkout main &&
echo "Other changes" >> changes.txt &&
git add changes.txt &&
git commit -m "Add changes.txt"
To replay the changes we made in main to story branch run:
git checkout story &&
git rebase main
# Successfully rebased and updated refs/heads/story.
You can see new file created in main branch being added to story branch:
ls
# changes.txt hello.txt story.txt
Word of caution: do not rebase branches that someone else might have used, e.g. the main branch. Also, keep in mind that every history manipulation on a remote repository will require forcing these changes to take effect.
Remote repository
If you haven't yet, create a GitHub account, login and create a new empty repository (private or public).
Assuming the repository name was "example" run the following command (change to your username):
git remote add origin git@github.com:USERNAME/example.git &&
git push -u origin main
You can refresh the page and see files in main branch. To push all local branches to remote repository run:
git push --all origin
Let's edit something on GitHub: just click any file and the pencil icon. Add a line with any text you want and press "Commit changes".
Now run this command locally to get the remote changes:
git checkout main &&
git pull
Managing uncommitted changes
If you want to save your local changes for later you can use git stash:
echo "Changes" >> hello.txt &&
git stash
Now you can use following command to check, apply or discard these changes:
git stash list
# stash@{0}: WIP on main: 92354c8 Update changes.txt
git stash pop # to apply changes
git stash drop # to drop changes
Pro tip: you can use stash number, i.e. git stash pop 0 to apply a particular stash or git stash drop 0 to drop it.
If you want to discard all local changes and simply restore repository to last committed changes run:
git restore .
Managing committed changes
Once you create a commit, this change is saved in local git history. As mentioned before, all changes affecting remote history would require a git push --force. Keep it in mind for all following commands.
Let's start with editing the last commit message :
git commit --amend # type :wq to save and close
# Press "i" to edit, "Esc" to stop editing
How about we reset everything to the very beginning?
To find the ID of the very first commit run this command and scroll (with arrow down) to the very end:
git log --abbrev-commit
# commit a07ee27
# Author: Your Name <your@email.address>
Date: Sun Jul 11 11:47:16 2021 +0200
Adds hello.txt
(END)
# type ":q" to close
Now run this to reset the repository, but keep all changes unstaged:
git reset --soft COMMIT # e.g. a07ee27
As opposite to it, you can also make a hard reset and get rid of all the changes with git reset --hard COMMIT. There are several other types of reset that you can learn from git documentation
Aliases
Most of the times you'll be using just a handful of command (checkout, add ,commit, pull, push and merge mostly), but are some things you might want to have around for "just in case".
One way to store those are git aliases. To configure an alias just set it in a config. For example, one alias I use a lot is git tree, it prints a nice history log in a form of a tree:
git config --global alias.tree 'log --graph --decorate --pretty=oneline --abbrev-commit'
# Try it with `git tree`
Another useful alias deletes all merged branches:
git config --global alias.clbr '!git branch --merged | grep -v \* | xargs git branch -D'
As you can see it's prefixed with "!", which allows us to use any command, not only git commands.
That's all for today, hope it helps in your developer journey. As always, feel free to share your thoughts and feedback in the comments. Till the next time!
Top comments (37)
As a beginner got to know a lot because of this, I would like to add one more to it
git rm --cached filenameit removes files from your repo but still is available locally.Thank you for the addition!
this command removes file from your staging area but not locally
It removes files from from staging/index only
I think it wont remove from remote repo but staging area.
Git
rmis the exact opposite ofadd.So if you *add*ed files and then called
git rm --cached smthit will remove that something from the staged changes. If you didn't change or add anything since the last commit, callinggit rmwill create this change (as if you would delete the file), staging it for your next commit.I tried
git merge -X theirs hello.txtand received the messagemerge: hello.txt - not something we can mergeHave you encountered this?Try
git merge -X theirs devinstead.I apologise for this mistake, git merge requires a branch name, of course, not the file name. I've corrected that in the article, thank you!
thanks!
Thank for this amazing article, could you please help me with one more issue.
How do I add changes made after a commit to the last commit. For example, I just created a nav menu and committed, after which I made a small change which I don't want to commit on its own but to add to the last commit.
Hope you understand and thank you in advance.
Sure thing! Firstly, you add the changes with
git add, then change the last commit withgit commit --amend.If you pushed your commit to the remote repository to push this change you'll need to use
git push --force.Does it matter if branch changes are pushed to a remote before rebasing? Would the steps be any different?
No, the steps would be the same, but force push would wipe remote branch commits that have not been pulled and may require hard reset on all local repositories, apart from your own.
I don't think I 100% follow.
If I created a branch
git checkout -b my-new-branchand then stage, commit, and push:git add .git commit -m "my message"git push origin my-new-branchDoes it matter that it the code was pushed to the remote? Could I then rebase as you described?
Yes you can rebase my-new-branch from main with
git rebase mainlocally, but you will need togit push --forcemy-new-branch to push these changes to a remote originThanks for the clarification. I think I understand. My plan at the moment is to try it with different scenarios and make sure I really do get it.
Great guide. Very much appreciated!
Great Article @valeriavg , helpful for those, whose beginning with Git.
Thank you, Your way is very useful, could you do another one for mid and advanced levels please
There's a very good book that covers git in depth should you seek more knowledge on the subject.
Thank you for your input, much appreciated
How are you being compatible with GitHub by changing the default branch name? It's completely unnecessary. If you're using "master" as the default branch name, GitHub will still let you use it as the default branch name.
When you create a repository on GitHub the default branch is main. It's not prohibited to use master as a default branch, but that would require a bit of a setup on GitHub to change the default name. Now I personally don't have a preference on how the branch is going to be called, but if a service, that I rely on a daily basis, asks me to do a one tiny naming change I prefer to comply out of respect.
I got to the part of remote repository, made an example repository in github and tried the commands above and get a RSA key fingerprint "not known by any other names". I try to continue and get permission denied (publickey). Ideas?
Try this solution from stack overflow: stackoverflow.com/questions/956089...
Great article! Well done!
Here is also a free open-source eBook on how to get started with Git that might be helpful for some people:
Free Introduction to Git and GitHub eBook
This is an open-source introduction to Git and GitHub guide that will help you learn the basics of version control and start using Git for your SysOps, DevOps, and Dev projects. No matter if you are a DevOps/SysOps engineer, developer, or just a Linux enthusiast, you can use Git to track your code changes and collaborate with other members of your team or open source maintainers.
The guide is suitable for anyone working as a developer, system administrator, or a DevOps engineer and wants to learn the basics of Git, GitHub and version control in general.
To download a copy of the ebook use one of the following links:
Dark mode
Light mode
After read this, I am a git master now! 😎
Very useful
Very helpful article! Thanks for sharing
Great article, and I hope people will try all the commands out and spend more than 7 minutes in practicing these 🙂
Great article!
thank you for sharing