The main difference between Git and any other VCS (including Subversion and friends) is the way that Git thinks about your data. Conceptually, most other systems store information as a file-based changelist. These systems (CVS, Subversion, Perforce, Bazaar, etc.) consider the information they save as a set of files and the changes made to each file over time.
Git doesn't think of or store your data in this way. Instead, Git thinks of your data more like a set of snapshots of a miniature filesystem. Every time you commit or save the state of your project in Git, it basically takes a picture of what all your files look like at the moment and stores a reference to that snapshot. To be efficient, if the files haven't changed, Git doesn't store the file again, just a link to the previous identical file that it has already stored. Git thinks of your data more like a snapshot stream.
-
Nearly Every Operation Is Local: Most operations in Git only need local files and resources to function; generally, no information is needed from another computer on your network.
-
Git Has Integrity: Everything in Git is "digested" for verification before being stored and then referenced by that checksum. This means that it is impossible to change the content of any file or directory without Git knowing about it.
-
Git Generally Only Adds Data: When you perform actions in Git, almost all of them just add data to the Git database. It is difficult to get the system to do something that cannot be undone or to erase data in some way.
Git has 3 areas in where your file could be:
- Your working directory
- Staging area
- Your Git repo
The files can be in different states for the Git VCS, and depending on the operations performed can change the area and the status.
Git has a hierarchy for the configuration, you can modify all of them, the hierarchy is from minor to mayor priority:
Command: git config
-
System [path]/etc/gitconfig or C:\ProgramData\Git\config:
--system
git config -f
-
User ~/.gitconfig or ~/.config/git/config or $HOME:
--global
-
Repository .git/config :
--local
To see all settings:
git config –list –show-origin
The hierarchy:
-
File [path]/etc/gitconfig: Contains values applied to each user on the system and all their repositories. If you pass the --system option to git config, it reads and writes from this file specifically. Since this is a system configuration file, you will need administrator or super-user privileges to make changes to it.
-
~/.gitconfig or ~/.config/git/config file: Settings specific to you, the user. You can make Git read and write to this file specifically by passing the --global option, and this affects all repositories you work with on your system.
-
Configuration file in the Git directory (ie .git/config) of whatever repository you are currently using: Specific to that single repository. You can force Git to read and write to this file with the --local option, but that's actually the default. Unsurprisingly, it must be located somewhere in a Git repository for this option to work properly. Each level overrides the values of the previous level, so the values in .git/config surpass those in [path]/etc/gitconfig.
Your identity
The basic information you need to provide to Git to use it is your name and your e-mail:
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
You can also specify other things, like your GPG key, your default branch name, the default signing status for the commits, etc.
Your editor
Another important thing you need to specify is your default editor, e.g:
git config --global core.editor emacs
git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"
We can know the status of or repository in every moment with:
Command: git status
Command: git log
Limiting what git shows us:
git log -3
A little prettier:
git log --decorate --oneline --graph
If we want a most colorful printing we can use:
git log --graph --pretty=format:'%C(red)%h%Creset -%C(yellow)%d%Creset %s %C(green)(%cr) %C(yellow)<%an>%Creset'
the available format specifiers are:
Looking for a piece of code (Added or removed):
git log -S "#define SAMPLES"
Looking for a piece of code (Changed):
git log -G "#define SAMPLES"
The possibility of making amends for our mistakes:
git commit –amend
Example:
$ git commit -m 'Initial commit'
$ git add forgotten_file
$ git commit --amend
Reckless commands:
Rebooting to a previous state:
git reset HEAD
With an empty branch:
git checkout -
Safe commands:
The conventional option when we have not made a commitment:
git restore --staged
What if I already got engaged?
git revert HEAD ~ 1
git push
DON'T use git push --force unless you wish to bring down the opprobrium of all other users of that repository. NEVER rewrite public history.
How do I keep my secret files secret? How do I avoid uploading unnecessary files for the project?
When a file or directory is ignored, it will not be:
-
Tracked by Git
-
Reported by commands such as git status or git diff
-
Staged with commands such as git add -A
The .gitignore file
We can use predefined .gitignore files from the GitHub page:
Deleting a remote branch:
git push [remote-name] --delete [branch-name]
Changing the URL of our remote origins:
git remote set-url origin [new-url]
Renaming a remote source:
git remote rename [original-name] [new-name]
How to find key versions of our repository faster? We can tag versions of our project in order to mark important versions.
With message or without message? We have the option to add a message to our tags.
Showing all our tags:
git tag
Without a message:
git tag
With a message:
git tag –a –m
Tags in git are not a commitment, so to view them they will not appear in the log, but rather show all the repository elements (blobs, trees, tags and commits).
git show
As they are not a commitment, they are not sent to remote sources unless specified, only message labels can be sent:
git push origin
Or if we want to send all our labels:
git push origin –tags
Deleting our labels:
git tag –d
And what is it for? We can use the tags to mark an important point in the history and point a branch there in every moment:
git checkout