Git is it's a version control system (VSC), a software designed to help us manage and track different versions of our code, initially created in 2005 by Linus Torvalds who is also the creator of Linux. Git makes it possible to store a separate version of the file every time you make a change.
Git is a distributed version control system or decentralised version control system and what that means is that many developers can work on a single project without having to be on the same network. It coordinates work between multiple developers and tracks every single version and every single change that's made on the system or in the project.
CORE CONCEPTS
Git keeps track of changes you make to your code
such that you have a full revision history, of all the changes you make to the code. It’s like Git taking a snapshot of the files you work on when using a specific command (commit), so you can always go back to see any snapshot of previously written code.
Git synchronises code between different people
You might imagine having some files that you and a collaborator, a partner, are working together on; what Git makes it easy to do is to give both you and your partner the same version of these files, such that you can both independently make modifications, and then eventually synchronises them back up together in some sort of central server (something like GitHub or Bitbucket). This way you can both always have the updated version of the files.
Git makes you test changes to your code without losing the original copy of the code
For instance, you might want to add a new feature to a project, but doing so might involve breaking the stuff you've already made. Git makes it very easy to solve this by branching off, meaning try something else for a little bit while keeping the original and working code. Only when you've tested it and you're feeling comfortable with it, you can then merge it back in with the original code.
Git can reverse back to old versions of code
This way the code is extremely safe. For instance, if you decide the feature you’re working on is not what you want, or that what you've done has a mistake in it, with git you can go back to a previous version.
BASIC COMMANDS
- git init will initialise a git repository; the term "repository" indicates a folder where you’re going to contain the code files that you want to track. Initialising is necessary to start to run other git commands, it will create a .git folder in that project that will be hidden by default.
git add will add the file or files that you specify to the staging area and they'll then be ready for commit. You can run this command as many times as you need to before committing. If you want to add every file in the folder you’re working you can use the dot symbol instead of listing the names of the files, it indicates “every file in the current folder” git add . If you instead want to add only some specific format of the file, like .html, you can use git add *.html. While if you don’t want to include some files, you need to create a file in the repository called .gitignore and then write inside it the file or folder names to ignore.
git status lets you see what you have in the staging area and is ready for commit. It will display the differences between the working tree and the staging area. It’s a command to get a better understanding of what's happening inside your Git repository.
git commit -m ‘comment’ will take everything that's on staging area and put it into the local repository. Basically, it will save the current and updated version of all your files in the repository. When we talk about “commit”, just think of it as if it’s a version of the repository that you’re saving. TUTORIAL TIME: You type git commit -m and then, in quotation marks, you're going to include what's called a commit message, which is just an English phrase or sentence describing what it is that you changed in this commit. That could be anything you want, but the rationale for this is that when you're going back and looking at your history, it becomes very clear what changes you made when.
why do we add before we commit? It's sort of a two-step process that Git uses. The reasoning here might be maybe you've made modifications to a bunch of different files, but you don't want to commit all of them at the same time. Maybe you are only done with two or three of them and are ready to commit, but the others are not ready yet. So you can only add the files you actually want to commit, and then commit all of these files. There's also a shorthand workaround to combine both add and commit steps together: git commit -am the "a" will automatically add all of the changed files and commit.
git clone will copy a remote repository into your current folder. So if you find a program or a project that you like on GitHub you can simply clone it and that will download it into your machine, this way you will have a local copy of the project.
git push will take you a local repository that you've created and then push it to a remote repository so that anyone who goes online onto GitHub and looks at my repository can actually see the changes I’ve made. You will have to add GitHub or another remote service using your credentials or SSH key.
Why would you commit something and not push it? Pushing is only relevant if you care about other people online being able to access that same version. There are many times when I'm working on a project independently, for instance, I might care about committing things for myself, but I don't really care about other people on the internet being able to access the repository.
git pull is the opposite of push, it downloads the latest changes from a remote repository onto your computer, making it possible to have the latest version when someone makes a change.
What might go wrong if multiple people are trying to make changes to the same repository? So imagine a situation where multiple people are making changes to the same line and now Git is not going to be able to resolve for itself how to deal with that. Which version should it actually be if person A has made this change and person B has made that change? Git is normally pretty smart about things. If I'm adding something to the beginning of a file and someone else is adding something to the end of the file, Git is usually pretty smart about just being able to merge those changes together. But sometimes you'll run into situations when people are working on the same file, where we can't quite resolve it. And this brings up what we call merge conflicts when we try to merge two people's changes and we can't resolve those differences. It also might happen when pulling some changes down from GitHub, but the changes I'm pulling conflict with whatever I have on my repository. The automatic merge failed. To fix this, you open up the file and you'll see something really cryptic like
This can be strange and confusing at first. What you'll see between the left arrow symbols and the equal signs (from line 8 to 10), are the changes that you've made to your repository. While the changes between the equal signs and the greater-than signs (from line 10 to 13), are the remote change\s that you’re trying to merge. The long sequence of numbers and letters at line 12 is what we call a commit hash. Every time you make a commit, Git gives it a commit hash, which is just a long sequence of numbers and letters to uniquely identify that commit. To solve this, the first thing you can do is remove those marker symbols. And then you need to decide what the file should look like. Basically, you need to manually go in and tell Git how it is that you want to resolve these different conflicts.
git branch , create a branch but that will NOT switch branch, to switch branch we need git checkout
git merge , merge the code from the branch to the master branch, this needs to be done on the master branch (so we first need to switch)
git branch -D delete a branch
A couple of other “optional” commands:
- git log is a command that basically just shows you a history of the commits that you've made. It's a way of seeing all your commits on the command line. They're in reverse chronological order, but you can see this whole history of all the comments that you've made and what their commit hashes were.
- git reset is a way of going back to a previous version of a commit. there are differences between soft resets and hard resets: git reset —hard takes you back to this particular comment that will eliminate all those changes and take you back. git reset —hard origin/master go back to a particular branch as well.
INSTALLING GIT
with Linux, it’s a simple package command
- (Debian) sudo apt install git-all
- (Fedora) sudo dnf install git-all
with Mac On Mavericks (10.9) or above it comes with the command line tools otherwise you can both install Xcode Command Line Tools or use homebrew
with Windows, there are several ways, but the easiest is using this URL (this also comes with a tool called git bash which is a command-line tool and it gives you a more Linux environment on Windows)
Before starting using git the first thing to do is to configure user and email, to do that, after installing git, simply open the terminal and write git config —global user.name ‘Name Surname’ and git config —global user.email email@mail.com.
If you want to know more about Git, go check
- this book: Pro Git book
or
- this video: Git - CS50 Seminars 2021