gaspersic/freeCodeCamp
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

fix: Update packages and fix local dev (#26907)

Browse Source 
<!-- Please follow this checklist and put an x in each of the boxes, like this: [x]. It will ensure that our team takes your pull request seriously. -->

- [x] I have read [freeCodeCamp's contribution guidelines](https://github.com/freeCodeCamp/freeCodeCamp/blob/master/CONTRIBUTING.md).
- [x] My pull request has a descriptive title (not a vague title like `Update index.md`)
- [x] My pull request targets the `master` branch of freeCodeCamp.
This commit is contained in:
Stuart Taylor
2018-10-23 14:18:46 +01:00
committed by mrugesh mohapatra
parent 153e1c9f38
commit 7da04a348b
341 changed files with 17836 additions and 1026 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
mock-guide/english/git/authenticate-with-github-using-ssh/index.md Normal file
View File

@ -0,0 +1,60 @@
---
title: How to authenticate with GitHub using SSH
---
# How to authenticate with GitHub using SSH
Check that there are no `rsa` files here before continuing, use:
```shell
ls -al ~/.ssh
```
If there is nothing to list (i.e. `: No such file or directory`) then use:
```shell
mkdir $HOME/.ssh
```
If there's nothing there then generate a new keygen with:
```shell
ssh-keygen -t rsa -b 4096 -C your@email.com
```
Now using `ls -al ~/.ssh` will show our `id_rsa.pub` file.
Add the SSH key to the SSH agent:
```shell
eval "$(ssh-agent -s)" # for mac and Linux from bash
```
```shell
eval `ssh-agent -s`
ssh-agent -s # for Windows
```
Add RSA key to SHH with:
```shell
ssh-add ~/.ssh/id_rsa
```
Copy your key to clipboard
```shell
clip < ~/.ssh/id_rsa.pub # Windows
```
```shell
cat ~/.ssh/id_rsa.pub # Linux
```
Go to your GitHub [settings](https://github.com/settings/keys) page and click the 'New SSH key' button paste in your generated key.
Then authenticate with:
```shell
ssh -T git@github.com
```

22
mock-guide/english/git/difference-git-github/index.md Normal file
View File

@ -0,0 +1,22 @@
---
title: Difference between Git and GitHub
---
## Difference between Git and GitHub
Git and Github are two different things. [Git](https://git-scm.com/) is the [version control system](https://en.wikipedia.org/wiki/Version_control), while [GitHub](https://github.com/) is a service for hosting Git repos and help people collaborate on writing software. However, they are often confounded because of their similar name, because of the fact that GitHub builds on top of Git, and because many websites and articles don't make the difference between them clear enough.
![Git is not GitHub](https://i.imgur.com/EkjwJdr.png)
### Git
Git is the distributed version control system. Git is responsible for keeping track of changes to content – usually source code files.
For more info, there is a [complete article about Git itself](https://guide.freecodecamp.org/git).
### GitHub
GitHub is a company that provides Git repository hosting. That means that they provide a turnkey solution to host Git repositories on their servers. That can be useful to keep a backup of your repository (Git only tracks the changes made to you files over time, the repo still needs to be backed up), and to have a centralized place to keep and share your code with others.
More than just a Git repository hosting service, GitHub is a [software forge](https://en.wikipedia.org/wiki/Forge_(software)). That means it also provides an [issue tracker](https://en.wikipedia.org/wiki/Issue_tracking_system), tools for [code review](https://en.wikipedia.org/wiki/Code_review), and other tools for collaborating with other people and creating software.
GitHub isn't the only one to provide this kind of service. One of its major competitors is [GitLab](https://gitlab.com). For more on this, look at the [article about Git hosting](https://guide.freecodecamp.org/git/git-hosting).

62
mock-guide/english/git/git-alias/index.md Normal file
View File

@ -0,0 +1,62 @@
---
title: Git Aliases
---
## Git Alias
Git doesn’t automatically infer your command if you type it in partially. If you don’t want to type the entire text of each of the Git commands, you can easily set up an alias for each command using git config. Here are a couple of examples you may want to set up:
```shell
$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status
```
This means that, for example, instead of typing git commit, you just need to type git ci. As you go on using Git, you’ll probably use other commands frequently as well; don’t hesitate to create new aliases.
This technique can also be very useful in creating commands that you think should exist. For example, to correct the usability problem you encountered with unstaging a file, you can add your own unstage alias to Git:
```shell
$ git config --global alias.unstage 'reset HEAD --'
```
This makes the following two commands equivalent:
```shell
$ git unstage fileA
$ git reset HEAD fileA
```
This seems a bit clearer. It’s also common to add a last command, like this:
```shell
$ git config --global alias.last 'log -1 HEAD'
```
This way, you can see the last commit easily:
```shell
$ git last
commit 66938dae3329c7aebe598c2246a8e6af90d04646
Author: Josh Goebel <dreamer3@example.com>
Date: Tue Aug 26 19:48:51 2008 +0800
test for current head
Signed-off-by: Scott Chacon <schacon@example.com>
```
```shell
$ git config --global alias.st status --short --branch
```
When you run the command `git st`, your git status will be displayed in a nice, streamlined format.
### View, Edit and Delete Aliases
To view all of the aliases you have created on your machine, run the command:
```shell
cat ~/.gitconfig
```
Replacing `cat` with `nano` will allow you to edit them or remove them completely.
### Alias to view all Aliases
To add an alias to view all others created on your machine, add the alias
```shell
git config --global alias.aliases 'config --get-regexp alias'
```

32
mock-guide/english/git/git-bisect/index.md Normal file
View File

@ -0,0 +1,32 @@
---
title: Git Bisect
---
## Git Bisect
The `git bisect` command helps you find commits that added specific changes in your project. This is particularly useful if you need to find which change introduced a bug.
This command works by providing it a "bad" commit that includes the bug and a "good" commit from before the bug was introduced. Through binary search, `git bisect` will pick commits and ask you to identify whether the commit is "good" or "bad". This continues until the command is able to find the exact commit that introduced the change.
### Bisect Commands
To start a bisect session, you will tell git to start a bisect session, identify a "bad" version, and identify a "good" version. Assuming the current commit is broken but commit `4b60707` is good, you will run the following:
```shell
git bisect start
git bisect bad
git bisect good 4b60707
```
Git will check out a commit between the "good" and "bad" versions and output something like the following:
```
Bisecting: 2 revisions left to test after this (roughly 2 steps)
```
You should now tell git if the current commit works with `git bisect good` or if the current commit is broken with `git bisect bad`. This process will repeat until the command is able to print out the first bad commit.
When finished, you should clean up the bisect session. This will reset your HEAD to what it was before you started the bisect session:
```shell
git bisect reset
```
### Other Resources
- [Git bisect documentation](https://git-scm.com/docs/git-bisect)

39
mock-guide/english/git/git-blame/index.md Normal file
View File

@ -0,0 +1,39 @@
---
title: Git Blame
---
## Git Blame
With `git blame` you can see who changed what in a specific file, line by line, which is useful if you work in a team, instead of alone. For example, if a line of code makes you wonder why it is there, you can use `git blame` and you will know who you must ask.
### Usage
You use `git blame` like this: `git blame NAME_OF_THE_FILE`
For example: `git blame triple_welcome.rb`
You will see an output like this:
```shell
0292b580 (Jane Doe 2018-06-18 00:17:23 -0500 1) 3.times do
e483daf0 (John Doe 2018-06-18 23:50:40 -0500 2) print 'Welcome '
0292b580 (Jane Doe 2018-06-18 00:17:23 -0500 3) end
```
Each line is annotated with the SHA, name of the author and date of the last commit.
### Aliasing Git Blame
Some programmers don't like the word 'blame', because of the negative connotation 'blaming someone' brings with it. Also, the tool is rarely (if ever) used for blaming someone, but rather to ask for advice or understand the history of a file. Therefore, sometimes people use an alias to change `git blame` to something which sounds a bit nicer such as `git who`, `git history` or `git praise`. To do that you simply add a git alias like this:
`git config --global alias.history blame`
You can find more information about aliasing git commands [here](../git-alias/index.md).
### Text Editor Plugins utilizing Git Blame
There are a few plugins out there for various text editors which utilize `git blame`. For example, to create something like heat maps or add inline information for the current line you are inspecting. A famous example is [GitLense](https://gitlens.amod.io/) for VSCode.
### Further Reading
- [Git Blame documentation](https://git-scm.com/docs/git-blame)
- [further reading on usage of Git Blame](https://corgibytes.com/blog/2016/10/18/git-blame/)

117
mock-guide/english/git/git-branch/index.md Normal file
View File

@ -0,0 +1,117 @@
---
title: Git Branch
---
## Git Branch
Git's branching functionality lets you create new branches of a project to test ideas, isolate new features, or experiment without impacting the main project.
**Table of Contents**
- [View Branches](#view-branches)
- [Checkout a Branch](#checkout-a-branch)
- [Create a New Branch](#create-a-new-branch)
- [Rename a Branch](#rename-a-branch)
- [Delete a Branch](#delete-a-branch)
- [Compare Branches](#compare-branches)
- [Help with Git Branch](#help-with-git-branch)
- [More Information](#more-information)
### View Branches <a name="view-branches"></a>
To view the branches in a Git repository, run the command:
```shell
git branch
```
To view both remote-tracking branches and local branches, run the command:
```shell
git branch -a
```
There will be an asterisk (\*) next to the branch that you're currently on.
There are a number of different options you can include with `git branch` to see different information. For more details about the branches, you can use the `-v` (or `-vv`, or `--verbose`) option. The list of branches will include the SHA-1 value and commit subject line for the `HEAD` of each branch next to its name.
You can use the `-a` (or `--all`) option to show the local branches as well as any remote branches for a repository. If you only want to see the remote branches, use the `-r` (or `--remotes`) option.
### Checkout a Branch <a name="checkout-a-branch"></a>
To checkout an existing branch, run the command:
```shell
git checkout BRANCH-NAME
```
Generally, Git won't let you checkout another branch unless your working directory is clean, because you would lose any working directory changes that aren't committed. You have three options to handle your changes:
1) trash them (see <a href='https://guide.freecodecamp.org/git/git-checkout/' target='_blank' rel='nofollow'>Git checkout for details</a>) or
2) commit them (see <a href='https://guide.freecodecamp.org/git/git-commit/' target='_blank' rel='nofollow'>Git commit for details</a>) or
3) stash them (see <a href='https://guide.freecodecamp.org/git/git-stash/' target='_blank' rel='nofollow'>Git stash for details</a>).
### Create a New Branch <a name="create-a-new-branch"></a>
To create a new branch, run the command:
```shell
git branch NEW-BRANCH-NAME
```
Note that this command only creates the new branch. You'll need to run `git checkout NEW-BRANCH-NAME` to switch to it.
There's a shortcut to create and checkout a new branch at once. You can pass the `-b` option (for branch) with `git checkout`. The following commands do the same thing:
```shell
# Two-step method
git branch NEW-BRANCH-NAME
git checkout NEW-BRANCH-NAME
# Shortcut
git checkout -b NEW-BRANCH-NAME
```
When you create a new branch, it will include all commits from the parent branch. The parent branch is the branch you're on when you create the new branch.
### Rename a Branch <a name="rename-a-branch"></a>
To rename a branch, run the command:
```shell
git branch -m OLD-BRANCH-NAME NEW-BRANCH-NAME
# Alternative
git branch --move OLD-BRANCH-NAME NEW-BRANCH-NAME
```
### Delete a Branch <a name="delete-a-branch"></a>
Git won't let you delete a branch that you're currently on. You first need to checkout a different branch, then run the command:
```shell
git branch -d BRANCH-TO-DELETE
# Alternative:
git branch --delete BRANCH-TO-DELETE
```
The branch that you switch to makes a difference. Git will throw an error if the changes in the branch you're trying to delete are not fully merged into the current branch. You can override this and force Git to delete the branch with the `-D` option (note the capital letter) or using the `--force` option with `-d` or `--delete`:
```shell
git branch -D BRANCH-TO-DELETE
# Alternatives
git branch -d --force BRANCH-TO-DELETE
git branch --delete --force BRANCH-TO-DELETE
```
### Compare Branches <a name="compare-branches"></a>
You can compare branches with the `git diff` command:
```shell
git diff FIRST-BRANCH..SECOND-BRANCH
```
You'll see colored output for the changes between branches. For all lines that have changed, the `SECOND-BRANCH` version will be a green line starting with a "+", and the `FIRST-BRANCH` version will be a red line starting with a "-". If you don't want Git to display two lines for each change, you can use the `--color-words` option. Instead, Git will show one line with deleted text in red, and added text in green.
If you want to see a list of all the branches that are completely merged into your current branch (in other words, your current branch includes all the changes of the other branches that are listed), run the command `git branch --merged`.
### Help with Git Branch <a name="help-with-git-branch"></a>
If you forget how to use an option, or want to explore other functionality around the `git branch` command, you can run any of these commands:
```shell
git help branch
git branch --help
man git-branch
```
### More Information: <a name="more-information"></a>
- The `git merge` command: <a href='https://guide.freecodecamp.org/git/git-merge/' target='_blank' rel='nofollow'>fCC Guide</a>
- The `git checkout` command: <a href='https://guide.freecodecamp.org/git/git-checkout/' target='_blank' rel='nofollow'>fCC Guide</a>
- The `git commit` command: <a href='https://guide.freecodecamp.org/git/git-commit/' target='_blank' rel='nofollow'>fCC Guide</a>
- The `git stash` command: <a href='https://guide.freecodecamp.org/git/git-stash/' target='_blank' rel='nofollow'>fCC Guide</a>
- Git documentation: <a href='https://git-scm.com/docs/git-branch' target='_blank' rel='nofollow'>branch</a>

55
mock-guide/english/git/git-checkout/index.md Normal file
View File

@ -0,0 +1,55 @@
---
title: Git Checkout
---
## Git Checkout
The `git checkout` command switches between branches or restores working tree files. There are a number of different options for this command that won't be covered here, but you can take a look at all of them in the <a href='https://git-scm.com/docs/git-checkout' target='_blank' rel='nofollow'>Git documentation</a>.
### Checkout a specific commit
to checkout a specific commit, run the command :
```shell
git checkout specific-commit-id
```
we can get the specific commit id's by running:
```shell
git log
```
### Checkout an Existing Branch
To checkout an existing branch, run the command:
```shell
git checkout BRANCH-NAME
```
Generally, Git won't let you checkout another branch unless your working directory is clean, because you would lose any working directory changes that aren't committed. You have three options to handle your changes: 1) trash them, 2) <a href='https://guide.freecodecamp.org/git/git-commit/' target='_blank' rel='nofollow'>commit them</a>, or 3) <a href='https://guide.freecodecamp.org/git/git-stash/' target='_blank' rel='nofollow'>stash them</a>.
### Checkout a New Branch
To create and checkout a new branch with a single command, you can use:
```shell
git checkout -b NEW-BRANCH-NAME
```
This will automatically switch you to the new branch.
### Checkout a New Branch or Reset a Branch to a Start Point
The following command is similar to checking out a new branch, but uses the `-B` (note the captital B) flag and an optional `START-POINT` parameter:
```shell
git checkout -B BRANCH-NAME START-POINT
```
If the `BRANCH-NAME` branch doesn't exist, Git will create it and start it at `START-POINT`. If the `BRANCH-NAME` branch already exists, then Git resets the branch to `START-POINT`. This is equivalent to running `git branch` with `-f`.
### Force a Checkout
You can pass the `-f` or `--force` option with the `git checkout` command to force Git to switch branches, even if you have un-staged changes (in other words, the index of the working tree differs from `HEAD`). Basically, it can be used to throw away local changes.
When you run the following command, Git will ignore unmerged entries:
```shell
git checkout -f BRANCH-NAME
# Alternative
git checkout --force BRANCH-NAME
```
### Undo Changes in your Working Directory
You can use the `git checkout` command to undo changes you've made to a file in your working directory. This will revert the file back to the version in `HEAD`:
```shell
git checkout -- FILE-NAME
```

35
mock-guide/english/git/git-cherry-pick/index.md Normal file
View File

@ -0,0 +1,35 @@
---
title: Git Cherry Pick
---
## Git Cherry Pick
The `git cherry-pick` command applies the changes introduced by some existing commits. This guide will be focusing on explaining this feature as much as possible but of course the real <a href='https://git-scm.com/docs/git-cherry-pick' target='_blank' rel='nofollow'>Git documentation</a> will always come in handy.
### Checkout an Existing Branch Cherry Pick from master
To apply the change introduced by the commit at the tip of the master branch and create a new commit with this change. Run the following command
```shell
git cherry-pick master
```
### Check in a change from a different commit
To apply the change introduced by the commit at the particular hash value you want, run the following command
```shell
git cherry-pick {HASHVALUE}
```
This will add the changes included referenced in that commit, to your current repository
### Apply certain commits from one branch to another
`cherry-pick` allows you to pick and choose between commits from one branch one to another. Let's say you have two branches `master` and `develop-1`. In the branch `develop-1` you have 3 commits with commit ids `commit-1`,`commit-2` and `commit-3`. Here you can only apply `commit-2` to branch `master` by:
```shell
git checkout master
git cherry-pick commit-2
```
If you encounter any conflicts at this point, you have to fix them and add them using `git add` and then you can use the continue flag to apply the cherry-pick.
```shell
git cherry-pick --continue
```
If you wish to abort a cherry-pick in between you can use the abort flag:
```shell
git cherry-pick --abort
```

61
mock-guide/english/git/git-clone/index.md Normal file
View File

@ -0,0 +1,61 @@
---
title: Git Clone
---
## Git Clone
The `git clone` command allows you to copy a remote repository onto your local machine.
First, find the remote repository for the project you're working on or interested in - this can also be your fork of a project. Next, copy the URL for it. For example, if you've forked the freeCodeCamp guides repository, the URL looks like `https://github.com/YOUR-GITHUB-USERNAME/guides.git`.
In the command line on your local machine, navigate to where you want to save the project in your working directory. Finally, run the `git clone` command:
```shell
git clone URL-OF-REPOSITORY
```
The default name of the new directory on your computer is the name of the repository, but you can change this by including the last (optional) parameter:
```shell
git clone URL-OF-REPOSITORY NAME-OF-DIRECTORY-ON-COMPUTER
```
Git gives the remote the alias "origin". This is a useful way to refer to the remote when you want to push your changes to the remote server or pull changes from it. See <a href='https://guide.freecodecamp.org/git/git-push/' target='_blank' rel='nofollow'>Git push</a> and <a href='https://guide.freecodecamp.org/git/git-pull/' target='_blank' rel='nofollow'>Git pull</a> for more details.
Git only pulls the remote's main branch onto your computer. This branch is usually named "master" by convention but may be defined differently depending on the project.
Also, Git automatically sets up your local main branch to track the remote branch. When you run `git status`, you'll see information about whether your local branch is up-to-date with the remote. Here's an example output:
```shell
myCommandPrompt (master) >> git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
myCommandPrompt (master) >>
```
If your local `master` branch has three commits that you haven't pushed up to the remote server yet, the status would say "Your branch is ahead of 'origin/master' by 3 commits."
### Git Clone Mirror
If you want to host mirror of a repository you can use mirror parameter.
```shell
git clone URL-OF-REPOSITORY --mirror
```
After mirroring a repository, you can clone your local mirror from your server.
```shell
git clone NAME-OF-DIRECTORY-ON-COMPUTER
```
### To clone a spacific branch
If you want to clone a spacific branch, you can do that by the following command.
```shell
git clone URL-OF-REPOSITORY -R branch_name
```
### More Information:
- Git documentation: [clone](https://git-scm.com/docs/git-clone)

86
mock-guide/english/git/git-commit/index.md Normal file
View File

@ -0,0 +1,86 @@
---
title: Git Commit
---
## Git Commit
The `git commit` command will save all staged changes, along with a brief description from the user, in a "commit" to the local repository.
Commits are at the heart of Git usage. You can think of a commit as a snapshot of your project, where a new version of that project is created in the current repository. Two important features of commits are:
- you can recall the commited changes at a later date, or revert the project to that version ([see Git checkout](https://guide.freecodecamp.org/git/git-checkout))
- if multiple commits edit different parts of the project, they will not overwrite each other even if the authors of the commit were unaware of each other. This is one of the benefits of using Git over a tool like Dropbox or Google Drive.
### Options
There are a number of options that you can include with `git commit`. However, this guide will only cover the two most common options. For an extensive list of options, please consult the [Git documentation](https://git-scm.com/docs/git-commit).
#### The -m Option
The most common option used with `git commit` is the `-m` option. The `-m` stands for message. When calling `git commit`, it is required to include a message. The message should be a short description of the changes being committed. The message should be at the end of the command and it must be wrapped in quotations `" "`.
An example of how to use the `-m` option:
```shell
git commit -m "My message"
```
The output in your terminal should look something like this:
```shell
[master 13vc6b2] My message
1 file changed, 1 insertion(+)
```
**NOTE:** If the `-m` is not included with the `git commit` command, you will be prompted to add a message in your default text editor - see 'Using detailed commit messages' below.
#### The -a Option
Another popular option is the `-a` option. The `-a` stands for all. This option automatically stages all modified files to be committed. If new files are added the `-a` option will not stage those new files. Only files that the Git repository is aware of will be committed.
For example:
Let’s say that you have a `README.md` file that has already been committed to your repository. If you make changes to this file, you can use the `-a` option in your commit command to stage and add the changes to your repository. However, what if you also added a new file called `index.html`? The `-a` option will not stage the `index.html` as it does not currently exist in the repository. When new files have been added, the `git add` command should be invoked in order to stage the files before they can be committed to the repository.
An example of how to use the `-a` option:
```shell
git commit -am “My new changes”
```
The output in your terminal should look something like this:
```shell
[master 22gc8v1] My new message
1 file changed, 1 insertion(+)
```
### Using detailed commit messages
Although `git commit -m "commit message"` works just fine, it can be useful to provide more detailed and systmatic information.
If you commit without using the `-m` option, git will open your default text editor with a new file, which will include a commented-out list of all the files/changes that are staged in the commit. You then write your detailed commit message (the first line will be treated as the subject line) and the commit will be performed when you save/close the file.
Bear in mind:
* Keep your commit message lines length less than 72 charcters as standard practice
* It is perfectly ok - and even recommended - to write multiline commit messages
* You can also refer to other issues or pull requests in your commit message. GitHub allocated a number reference to all pull requests and issues, so for example if you want to refer to pull request #788 simply do so in either the subject-line or in the body text as appropriate
#### The --amend Option
The `--amend` option allows you to change your last commit. Let's say you just committed and you made a mistake in your commit log message. You can conveniently modify the most recent commit using the command:
```shell
git commit --amend -m "an updated commit message"
```
If you forget to include a file in the commit:
```shell
git add FORGOTTEN-FILE-NAME
git commit --amend -m "an updated commit message"
# If you don't need to change the commit message, use the --no-edit option
git add FORGOTTEN-FILE-NAME
git commit --amend --no-edit
```
Premature commits happen all the time in the course of your day-to-day development. It’s easy to forget to stage a file or how to correctly format your commit message. The `--amend` flag is a convenient way to fix these minor mistakes. This command will replace the old commit message with the updated one specified in the command.
Amended commits are actually entirely new commits and the previous commit will no longer be on your current branch. When you're working with others, you should try to avoid amending commits if the last commit is already pushed into the repository.
With `--amend`, one of the useful flag you could use is `--author` which enables you to change the author of the last commit you've made. Imagine a situation you haven't properly set up your name or email in git configurations but you already made a commit. With `--author` flag you can simply change them without resetting the last commit.
```
git commit --amend --author="John Doe <johndoe@email.com>"
```
#### The -v or --verbose Option
The `-v` or `--verbose` option is used without the `-m` option. The `-v` option can be useful when you wish to edit a Git commit message in your default editor while being able to see the changes you made for the commit. The command opens your default text editor with a commit message template *as well as* a copy of the changes you made for this commit. The changes, or diff, will not be included in the commit message, but they provide a nice way to reference your changes when you're describing them in your commit message.
### More Information:
- Git documentation: [commit](https://git-scm.com/docs/git-commit)

6
mock-guide/english/git/git-fetch/index.md Normal file
View File

@ -0,0 +1,6 @@
---
title: Git Fetch
---
## Git Fetch
The `git fetch` git-fetch - Download objects and refs from another repository

14
mock-guide/english/git/git-hooks/index.md Normal file
View File

@ -0,0 +1,14 @@
---
title: Git Hooks
---
## Git Hooks
Git Hooks are scripts located in the `.git/hooks/` directory of a git repository. These scripts run after being triggered by different stages in the version control process.
### Samples
In this directory are a handful of sample scripts, such as `pre-commit.sample`. This particular sample runs every time a user runs `git commit`. If the hook script exits with a status other than 0, then the commit stops.
### Documentation
- [Documentation for Git Hooks](https://git-scm.com/docs/githooks)
- [Atlassian Tutorial on Git Hooks](https://www.atlassian.com/git/tutorials/git-hooks)
- [Git Hooks Guide](http://githooks.com/)

13
mock-guide/english/git/git-hosting/index.md Normal file
View File

@ -0,0 +1,13 @@
---
title: Git hosting
---
## Git hosting
This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/git/git-hosting/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

93
mock-guide/english/git/git-how-to-undo-things/index.md Normal file
View File

@ -0,0 +1,93 @@
---
title: How to Undo Things in Git
---
## How to Undo Things in Git
As a version control software, Git gives you the ability to undo your changes at all levels. This includes the un-staged edits you made in your working directory all the way through undoing multiple commits.
Here's a quick summary outlining how to undo or revert changes in your Git project. There are Guide articles with more details for each of the following commands.
### Undoing changes in your working directory
If you want to undo changes you made to a file or directory in your working directory (that you haven't staged or committed yet), you use the `git checkout` command. Git replaces the file or directory you've specified with the version of them from in `HEAD`. The `--` in the command tells Git to stay in the current branch and use that branch's `HEAD`.
```shell
git checkout -- FILE-NAME
```
Typically, Git won't allow you to checkout another branch when you have un-staged changes. However, you can do a forced checkout to switch to a different branch, and this will discard all the changes you've made to files in your working directory.
```shell
git checkout (-f | --force) OTHER-BRANCH-NAME
```
See the [Git Checkout article](../git-checkout/index.md) for more details.
### Un-staging files
Say you ran `git add .` to move several files you edited in your working directory to the staging area. It's possible to remove one or all of them from the staging area while keeping your changes in your working directory. You can un-stage certain files with the `git reset` command. This may happen when you edit several files, add everything to your staging area, but decide you want to make multiple, more focused, commits.
```shell
git reset HEAD FILE-NAME
```
See the [Git Reset article](../git-reset/index.md) for more details.
### Amending the last commit
If you've committed your changes, but need to make more edits, Git allows you to amend your last commit. Simply make your changes, stage them with the `git add` command, then use the `git commit` command with the `--amend` option.
```shell
# Use the original commit message
git add EDITED-FILE
git commit --amend --no-edit
# Change the commit message
git add EDITED-FILE
git commit --amend -m "new message"
```
When you're working with others, you should try to avoid amending commits if the last commit is already pushed into the project repository.
See the [Git Commit article](../git-commit/index.md) for more details.
### Changing a file back to a version in an older commit
In a similar workflow to how you removed changes in your working directory, the `git checkout` command also lets you revert to a version of that file in an older commit. First, you need to find the SHA-1 hash for the older commit with the version of the file you want, and copy about the first 8-10 characters of it.
```shell
git checkout PART-OF-SHA-OF-OLDER-COMMIT -- FILE-NAME
```
This puts the file (in the state it was in from the older commit) into your working directory and staging area.
### Reverting a commit
You can undo changes from a recent commit with the `git revert` command. This will rollback the changes you committed but keep a record of the action in the commit history. It's not just for the recent commit, you can revert to older versions.
```shell
git revert PART-OF-SHA-OF-OLDER-COMMIT
```
See the [Git Revert article](../git-revert/index.md) for a detailed example and more information.
### Undoing multiple commits
You can use the `git reset` command to change where your current `HEAD` pointer points. This works for specific files or for the entire branch. The command is different than `git revert` because it will overwrite everything that came after that point.
The following command resets your current branch's `HEAD` to the given `COMMIT` and updates the index. It basically rewinds the state of your branch, then all commits you make going forward write over anything that came after the reset point. If you omit the `MODE`, it defaults to `--mixed`:
```shell
git reset MODE COMMIT
```
There are five options for the `MODE`, but the three you'll likely want to use are `--soft` (resets `HEAD` but doesn't reset the staging area or working directory), `--mixed` (resets the staging area but not the working directory), and `--hard` (resets the staging area and working directory).
See the [Git Reset article](../git-reset/index.md) for all the options and more information.
### More Information:
- [Git checkout documentation](https://git-scm.com/docs/git-checkout)
- [Git commit documentation](https://git-scm.com/docs/git-commit)
- [Git revert documentation](https://git-scm.com/docs/git-revert)
- [Git reset documentation](https://git-scm.com/docs/git-reset)

123
mock-guide/english/git/git-log/index.md Normal file
View File

@ -0,0 +1,123 @@
---
title: Git Log
---
## Git Log
The ```git log``` command displays all of the commits in a respository's history.
By default, the command displays each commit's:
* Secure Hash Algorithm (SHA)
* author
* date
* commit message
### Navigating Git Log
Git uses the Less terminal pager to page through the commit history. You can navigate it with the following commands:
* to scroll down by one line, use j or ↓
* to scroll up by one line, use k or ↑
* to scroll down by one page, use the spacebar or the Page Down button
* to scroll up by one page, use b or the Page Up button
* to quit the log, use q
### Git Log Flags
You can customize the information presented by ```git log``` using flags.
#### --oneline
```git log --oneline```
The ```--oneline``` flag causes ```git log ``` to display
* one commit per line
* the first seven characters of the SHA
* the commit message
#### --stat
```git log --stat```
The ```--stat``` flag causes ```git log ``` to display
* the files that were modified in each commit
* the number of lines added or removed
* a summary line with the total number of files and lines changed
#### --patch or -p
```git log --patch```
or, the shorter version
```git log -p```
The ```--patch``` flag causes ```git log ``` to display
* the files that you modified
* the location of the lines that you added or removed
* the specific changes that you made
### View specified number of commits by author
To view a specified number of commits by an author to the current repo (optionally in a prettified format), the following command can be used
```git log --pretty=format:"%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset" -n {NUMBER_OF_COMMITS} --author="{AUTHOR_NAME}" --all```
#### Start at a specific commit
To start ```git log``` at a specific commit, add the SHA:
```git log 7752b22```
This will display the commit with the SHA 7752b22 and all of the commits made before that commit. You can combine this with any of the other flags.
#### --graph
```git log --graph```
The ```--graph``` flag enables you to view your ```git log ``` as a graph. To make things things interesting, you can combine this command with ```--oneline``` option you learned from above.
```git log --graph --oneline```
The output would be similar to,
* 64e6db0 Update index.md
* b592012 Update Python articles (#5030)
* ecbf9d3 Add latest version and remove duplicate link (#8860)
* 7e3934b Add hint for Compose React Components (#8705)
* 99b7758 Added more frameworks (#8842)
* c4e6a84 Add hint for "Create a Component with Composition" (#8704)
* 907b004 Merge branch 'master' of github.com:freeCodeCamp/guide
|\
| * 275b6d1 Update index.md
* | cb74308 Merge branch 'dogb3rt-patch-3'
|\ \
| |/
|/|
| * 98015b6 fix merge conflicts after folder renaming
| |\
|/ /
| * fa83460 Update index.md
* | 6afb3b5 rename illegally formatted folder name (#8762)
* | 64b1fe4 CSS3: border-radius property (#8803)
One of the benefit of using this command is that it enables you to get a overview of how commits have merged and how the git history was created.
There are may other options you could use in combination with ```--graph```. Couple of them are ```--decorate``` and ```--all```. Make sure to try these out too. And refer to [documantation](https://git-scm.com/docs/git-log) for more helpful info.
#### More Information:
- [Git Basics - Viewing the Commit History](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History)
- [Git Log](https://git-scm.com/docs/git-log)
##### Other Resources on Git in guide.freecodecamp.org
- [Git Merge](../git-merge/index.md)
- [Git Checkout](../git-checkout/index.md)
- [Git Commit](../git-commit/index.md)
- [Git Stash](../git-stash/index.md)
- [Git Branch](../git-branch/index.md)

55
mock-guide/english/git/git-merge/index.md Normal file
View File

@ -0,0 +1,55 @@
---
title: Git Merge
---
## Git Merge
The `git merge` command will merge any changes that were made to the code base on a seperate branch to your current branch.
The command syntax is as follows:
```shell
git merge BRANCH-NAME
```
For example, if you are currently working in a branch named `dev` and would like to merge any new changes that were made in a branch named `new-features`, you would issue the following command:
```shell
git merge new-features
```
**Please Note:** If there are any uncommitted changes on your current branch, Git will not allow you to merge until all changes in your current branch have been committed. To handle those changes, you can either:
* Create a new branch and commit the changes
```shell
git checkout -b new-branch-name
git add .
git commit -m "<your commit message>"
```
* Stash them
```shell
git stash # add them to the stash
git merge new-features # do your merge
git stash pop # get the changes back into your working tree
```
* Abandon it all
```shell
git reset --hard # removes all pending changes
```
## Merge Conflict
A merge conflict is when you make commits on separate branches that alter the same line in conflicting ways. Therefore Git will not know which version of the file to keep
resulting in the error message:
CONFLICT (content): Merge conflict in resumé.txt
Automatic merge failed; fix conflicts and then commit the result.
In the code editor Git uses markings to indicate the HEAD (master) version of the file and the other version of the file.
`<<<<<<< HEAD`
`>>>>>>> OTHER`
From the code editor delete/update to resolve conflict and remove the special markings including the HEAD and OTHER file names, reload your file, then re add and recommit your changes.
For more information about the `git merge` command and all available options, please refer to the <a href="https://git-scm.com/docs/git-merge" target="_blank" rel="nofollow">Git documentation</a>.

112
mock-guide/english/git/git-pull/index.md Normal file
View File

@ -0,0 +1,112 @@
---
title: Git Pull
---
## Git Pull
`git pull` is a Git command used to update the local version of a repository from a remote.
It is one of the four commands that prompts network interaction by Git. By default, `git pull` does two things.
1. Updates the current local working branch (currently checked out branch)
1. Updates the remote tracking branches for all other branches.
`git pull` fetches (`git fetch`) the new commits and merges <a href='https://guide.freecodecamp.org/git/git-merge' target='_blank' rel='nofollow'>(`git merge`)</a> these into your local branch.
This command's syntax is as follows:
```shell
# General format
git pull OPTIONS REPOSITORY REFSPEC
# Pull from specific branch
git pull REMOTE-NAME BRANCH-NAME
```
in which:
- **OPTIONS** are the command options, such as `--quiet` or `--verbose`. You can read more about the different options in the <a href='https://git-scm.com/docs/git-pull' target='_blank' rel='nofollow'>Git documentation</a>
- **REPOSITORY** is the URL to your repo. Example: https://github.com/freeCodeCamp/freeCodeCamp.git
- **REFSPEC** specifies which refs to fetch and which local refs to update
- **REMOTE-NAME** is the name of your remote repository. For example: *origin*.
- **BRANCH-NAME** is the name of your branch. For example: *develop*.
**Note**
If you have uncommitted changes, the merge part of the `git pull` command will fail and your local branch will be untouched.
Thus, you should *always commit your changes in a branch before pulling* new commits from a remote repository.
**Table of Contents**
- [Using `git pull`](#using-git-pull)
- [Distributed Version Control](#distributed-version-control)
- [`git fetch` + `git merge`](#git-fetch-plus-git-merge)
- [`git pull` in IDEs](#git-pull-in-IDEs)
### Using git pull
Use `git pull` to update a local repository from the corresponding remote repository. Ex: While working locally on `master`, execute `git pull` to update the local copy of `master` and update the other remote tracking branches. (More information on remote tracking branches in the next section.)
But, there are a few things to keep in mind for that example to be true:
- The local repository has a linked remote repository
- Check this by executing `git remote -v`
- If there are multiple remotes, `git pull` might not be enough information. You might need to enter `git pull origin` or `git pull upstream`.
- The branch you are currently checked out to has a corresponding remote tracking branch
- Check this by executing `git status`. If there is no remote tracking branch, Git doesn't know where to pull information _from_.
### Distributed Version Control
Git is a **Distributed Version Control System** (DVCS). With DVCS, developers can be working on the same file at the same time in separate environments. After _pushing_ code up to the shared remote repository, other developers can _pull_ changed code.
#### Network interactions in Git
There are only four commands that prompt network interactions in Git. A local repository has no awareness of changes made on the remote repository until there is a request for information. And, a remote repository has no awareness of local changes until commits are pushed.
The four network commands are:
- `git clone`
- `git fetch`
- `git pull`
- `git push`
#### Branches in DVCS
When working with Git, it can feel like there are lots of copies of the same code floating all over the place. There are different versions of the same file on each branch. And, different copies of the same branches on every developer's computer and on the remote. To keep track of this, Git uses something called **remote tracking branches**.
If you execute `git branch --all` within a Git repository, remote tracking branches appear in red. These are read-only copies of the code as it appears on the remote. ( When was the last network interaction that would have brought information locally? Remember when this information was last updated. The information in the remote tracking branches reflects the information from that interaction.)
With **remote tracking branches**, you can work in Git on several branches without network interaction. Every time you execute `git pull` or `git fetch` commands, you update **remote tracking branches**.
### git fetch plus git merge
`git pull` is a combination command, equal to `git fetch` + `git merge`.
#### git fetch
On its own, `git fetch` updates all the remote tracking branches in local repository. No changes are actually reflected on any of the local working branches.
#### git merge
Without any arguments, `git merge` will merge the corresponding remote tracking branch to the local working branch.
#### git pull
`git fetch` updates remote tracking branches. `git merge` updates the current branch with the corresponding remote tracking branch. Using `git pull`, you get both parts of these updates. But, this means that if you are checked out to `feature` branch and you execute `git pull`, when you checkout to `master`, any new updates will not be included. Whenever you checkout to another branch that may have new changes, it's always a good idea to execute `git pull`.
### git pull in IDEs
Common language in other IDES may not include the word `pull`. If you look out for the words `git pull` but don't see them, look for the word `sync` instead.
### fethcing a remote PR (Pull Request) in to local repo
For purposes of reviewing and such, PRs in remote should be fetched to the local repo. You can use `git fetch` command as follows to achieve this.
`git fetch origin pull/ID/head:BRANCHNAME`
ID is the pull request id and BRANCHNAME is the name of the branch that you want to create. Once the branch has been created you can use `git checkout` to switch to that brach.
### Other Resources on git pull
- <a href='https://git-scm.com/docs/git-pull' target='_blank' rel='nofollow'>git-scm</a>
- <a href='https://help.github.com/articles/fetching-a-remote/#pull' target='_blank' rel='nofollow'>GitHub Help Docs</a>
- <a href='https://services.github.com/on-demand/intro-to-github/create-pull-request' target='_blank' rel='nofollow'>GitHub On Demand Training</a>
- <a href='https://www.atlassian.com/git/tutorials/syncing' target='_blank' rel='nofollow'>Syncing Tutorials</a>
### Other Resources on git in guide.freecodecamp.org
- [Git merge](../git-merge/index.md)
- [Git checkout](../git-checkout/index.md)
- [Git commit](../git-commit/index.md)
- [Git stash](../git-stash/index.md)
- [Git branch](../git-branch/index.md)

63
mock-guide/english/git/git-push/index.md Normal file
View File

@ -0,0 +1,63 @@
---
title: Git Push
---
## Git Push
The `git push` command allows you to send (or *push*) the commits from your local branch in your local Git repository to the remote repository.
To be able to push to your remote repository, you must ensure that **all your changes to the local repository are committed**.
This command's syntax is as follows:
```bash
git push <repo name> <branch name>
```
There are a number of different options you can pass with the command, you can learn more about them in the <a href='https://git-scm.com/docs/git-push#_options_a_id_options_a' target='_blank' rel='nofollow'>Git documentation</a> or run `git push --help`.
### Push to a Specific Remote Repository and Branch
In order to push code, you must first clone a repository to your local machine.
```bash
# Once a repo is cloned, you'll be working inside of the default branch (the default is `master`)
git clone https://github.com/<git-user>/<repo-name> && cd <repo-name>
# make changes and stage your files (repeat the `git add` command for each file, or use `git add .` to stage all)
git add <filename>
# now commit your code
git commit -m "added some changes to my repo!"
# push changes in `master` branch to github
git push origin master
```
To learn more about branches check out the links below:
* [git checkout](https://github.com/renington/guides/blob/master/src/pages/git/git-checkout/index.md)
* [git branch](https://github.com/renington/guides/blob/master/src/pages/git/git-branch/index.md)
### Push to a Specific Remote Repository and All Branches in it
If you want to push all your changes to the remote repository and all branches in it, you can use:
```bash
git push --all <REMOTE-NAME>
```
in which:
- `--all` is the flag that signals that you want to push all branches to the remote repository
- `REMOTE-NAME` is the name of the remote repository you want to push to
### Push to a specific branch with force parameter
If you want to ignore the local changes made to Git repository at Github(Which most of developers do for a hot fix to development server) then you can use --force command to push by ignoring those changs.
```bash
git push --force <REMOTE-NAME> <BRANCH-NAME>
```
in which:
- `REMOTE-NAME` is the name of the remote repository to which you want to push the changes to
- `BRANCH-NAME` is the name of the remote branch you want to push your changes to
### Push ignoring Git's pre-push hook
By default `git push` will trigger the `--verify` toggle. This means that git will execute any client-side pre-push script that may have been configured. If the pre-push scripts fails, so will the git push. (Pre-Push hooks are good for doing things like, checking if commit messages confirm to company standards, run unit tests etc...). Occasionally you may wish to ignore this default behavior e.g. in the scenario where you wish to push your changes to a feature branch for another contributor to pull, but your work-in-progress changes are breaking unit tests. To ignore the hook, simply input your push command and add the flag `--no-verify`
```bash
git push --no-verify
```
### More Information:
- [Git documentation - push](https://git-scm.com/docs/git-push)
- [Git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)

72
mock-guide/english/git/git-rebase/index.md Normal file
View File

@ -0,0 +1,72 @@
---
title: Git Rebase
---
## Git Rebase
Rebasing a branch in Git is a way to move the entirety of a branch to another point in the tree. The simplest example is moving a branch further up in the tree. Say we have a branch that diverged from the master branch at point A:
/o-----o---o--o-----o--------- branch
--o-o--A--o---o---o---o----o--o-o-o--- master
When you rebase you can move it like this:
/o-----o---o--o-----o------ branch
--o-o--A--o---o---o---o----o--o-o-o master
To rebase, make sure you have all the commits you want in the rebase in your master branch. Check out the branch you want to rebase and type `git rebase master` (where master is the branch you want to rebase on).
It is also possible to rebase on a different branch, so that for example a branch that was based on another branch (let's call it feature) is rebased on master:
/---o-o branch
/---o-o-o-o---o--o------ feature
----o--o-o-A----o---o--o-o-o--o--o- master
After `git rebase master branch` or `git rebase master` when you have checked out the branch, you'll get:
/---o-o-o-o---o--o------ feature
----o--o-o-A----o---o--o-o-o--o--o- master
\---o-o branch
### Git rebase interactive in the console
To use `git rebase` in the console with a list of commits you can choose, edit or drop in the rebase:
- Enter `git rebase -i HEAD~5` with the last number being any number of commits from the most recent backwards you want to review.
- In vim, press `esc`, then `i` to start editing the test.
- On the left hand side you can overwrite the `pick` with one of the commands below. If you want to squash a commit into a previous one and discard the commit message, enter `f` in the place of the `pick` of the commit.
```
pick 452b159 <message for this commit>
pick 7fd4192 <message for this commit>
pick c1af3e5 <message for this commit>
pick 5f5e8d3 <message for this commit>
pick 5186a9f <message for this commit>
# Rebase 0617e63..5186a9f onto 0617e63 (30 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
```
- Enter `esc` followed by `:wq` to save and quit.
- If it rebases successfully then you need to force push your changes with `git push -f` to add the rebased version to your github repo.
- If there is a merge conflict, there are a number of ways to fix this, including following the suggestions in [this guide](https://help.github.com/enterprise/2.11/user/articles/resolving-a-merge-conflict-using-the-command-line/). One way is to open the files in a text editor and delete the parts of the code you do not want. Then use `git add <file name>` followed by `git rebase --continue`. You can skip over the conflicted commit by entering `git rebase --skip`, exit the git rebase by entering `git rebase --abort` in your console.
### More Information:
- [Git documentation: rebase](https://git-scm.com/docs/git-rebase)
- [Thoughbot interactive guide to git rebase](https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history)

59
mock-guide/english/git/git-remote/index.md Normal file
View File

@ -0,0 +1,59 @@
---
title: Git Remote
---
## Git Remote
The `git remote` command allows you to manage your Git remote repositories. Remote repositories are references to other Git repositories that operate on the same codebase.
You can
<a href='https://guide.freecodecamp.org/git/git-pull/' target='_blank' rel='nofollow'>pull from</a>
and
<a href='https://guide.freecodecamp.org/git/git-push/' target='_blank' rel='nofollow'>push to</a>
remote repositories.
You can push or pull to either an HTTPS URL, such as `https://github.com/user/repo.git`, or an SSH URL, like `git@github.com:user/repo.git`.
Don't worry, every time you push something, you don't need to type the entire URL. Git associates a remote URL with a name, and the name most people use is `origin`.
### List all configured remote repositories
```bash
git remote -v
```
This command lists all remote repositories alongside their location.
Remote repositories are referred to by name. As noted above, the main repository for a project is usually called `origin`.
When you you use
<a href='https://guide.freecodecamp.org/git/git-clone/' target='_blank' rel='nofollow'>git clone</a>
to obtain a copy of a repository, Git sets up the original location as the *origin* remote repository.
### Add a remote repository
To add a remote repository to your project, you would run the following command:
```bash
git remote add REMOTE-NAME REMOTE-URL
```
The `REMOTE-URL` can be either HTTPS or SSH. You can find the URL on GitHub by clicking the "Clone or download" dropdown in your repository.
For example, if you want to add a remote repository and call it `example`, you would run:
```bash
git remote add example https://example.org/my-repo.git
```
### Update a remote URL
If the URL of a remote repository changes, you can update it with the following command, where `example` is the name of the remote:
```bash
git remote set-url example https://example.org/my-new-repo.git
```
### Deleting Remotes
Deleting remotes is done like so:
```bash
git remote rm REMOTE-NAME
```
You can confirm the remote is gone by viewing the list of your existing remotes:
```bash
git remote -v
```
### More Information:
- [Git remote documentation](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes)

40
mock-guide/english/git/git-reset/index.md Normal file
View File

@ -0,0 +1,40 @@
---
title: Git Reset
---
## Git Reset
The `git reset` command allows you to RESET your current head to a specified state. You can reset the state of specific files as well as an entire branch.
### Reset a file or set of files
The following command lets you selectively choose chunks of content and revert or unstage it.
```shell
git reset (--patch | -p) [tree-ish] [--] [paths]
```
### Unstage a file
If you moved a file into the staging area with `git add`, but no longer want it to be part of a commit, you can use `git reset` to unstage that file:
```shell
git reset HEAD FILE-TO-UNSTAGE
```
The changes you made will still be in the file, this command just removes that file from your staging area.
### Reset a branch to a prior commit
The following command resets your current branch's HEAD to the given `COMMIT` and updates the index. It basically rewinds the state of your branch, then all commits you make going forward write over anything that came after the reset point. If you omit the `MODE`, it defaults to `--mixed`:
```shell
git reset MODE COMMIT
```
The options for `MODE` are:
- `--soft`: does not reset the index file or working tree, but resets HEAD to `commit`. Changes all files to "Changes to be commited"
- `--mixed`: resets the index but not the working tree and reports what has not been updated
- `--hard`: resets the index and working tree. Any changes to tracked files in the working tree since `commit` are discarded
- `--merge`: resets the index and updates the files in the working tree that are different between `commit` and HEAD, but keeps those which are different between the index and working tree
- `--keep`: resets index entries and updates files in the working tree that are different between `commit` and HEAD. If a file that is different between `commit` and HEAD has local changes, the reset is aborted
### More Information:
- [Git reset documentation](https://git-scm.com/docs/git-reset)

68
mock-guide/english/git/git-revert/index.md Normal file
View File

@ -0,0 +1,68 @@
---
title: Git Revert
---
## Git Revert
The `git revert` command undoes a commit, but unlike `git reset`, which removes the commit from the commit history, it appends a new commit with the resulting content. This prevents Git from losing history, which is important for the integrity of your revision history and for reliable collaboration. When you are working on a repository with other developers, using `git reset` is highly dangerous because you alter the history of commits which makes it very difficult to maintain a consistent history of commits with other developers.
### Common options
1.) This is a default option and doesn't need to be specified. This option will open the configured system editor and prompts you to edit the commit message prior to committing the revert.
```shell
-e
--edit
```
2.) This is the inverse of the -e option. The `revert` will not open the editor.
```shell
--no-edit
```
3.) Passing this option will prevent `git revert` from creating a new commit that inverses the target commit. Instead of creating the new commit this option will add the inverse changes to the Staging Index and Working Directory.
```shell
-n
--no-edit
```
### Example.
Let's imagine the following situation.
1.) You are working on a file and you add and commit your changes.
2.) You then work on a few other things, and make some more commits.
3.) Now you realize, three or four commits ago, you did something that you would like to undo - how can you do this?
You might be thinking, just use `git reset`, but this will remove all of the commits after the one you would like to change - `git revert` to the rescue! Let's walk through this example:
```shell
mkdir learn_revert # Create a folder called `learn_revert`
cd learn_revert # `cd` into the folder `learn_revert`
git init # Initialize a git repository
touch first.txt # Create a file called `first.txt`
echo Start >> first.txt # Add the text "Start" to `first.txt`
git add . # Add the `first.txt` file
git commit -m "adding first" # Commit with the message "Adding first.txt"
echo WRONG > wrong.txt # Add the text "WRONG" to `wrong.txt`
git add . # Add the `wrong.txt` file
git commit -m "adding WRONG to wrong.txt" # Commit with the message "Adding WRONG to wrong.txt"
echo More >> first.txt # Add the text "More" to `first.txt`
git add . # Add the `first.txt` file
git commit -m "adding More to first.txt" # Commit with the message "Adding More to first.txt"
echo Even More >> first.txt # Add the text "Even More" to `first.txt`
git add . # Add the `first.txt` file
git commit -m "adding Even More to First.txt" # Commit with the message "Adding More to first.txt"
# OH NO! We want to undo the commit with the text "WRONG" - let's revert! Since this commit was 2 from where we are not we can use git revert HEAD~2 (or we can use git log and find the SHA of that commit)
git revert HEAD~2 # this will put us in a text editor where we can modify the commit message.
ls # wrong.txt is not there any more!
git log --oneline # note that the commit history hasn't been altered, we've just added a new commit reflecting the removal of the `wrong.txt`
```
#### More Information:
- [Git revert documentation](https://git-scm.com/docs/git-revert)
- [Git revert interactive tutorial](https://www.atlassian.com/git/tutorials/undoing-changes/git-revert)

55
mock-guide/english/git/git-show/index.md Normal file
View File

@ -0,0 +1,55 @@
---
title: Git Show
---
## Git Show
The `git show` is a handy command that enables you to see in detail view of a given object (commits, tags, blobs and trees).
This command's syntax is as follows:
```bash
git show [<options>] [<object>…​]
```
For different git objects `git show` gives different outputs.
* commits it shows the commit log message with a diff of changes which were committed.
* For tags, it shows the tag message and the referenced objects.
* For trees, it shows the names
* For plain blobs, it shows the plain contents
The most common usage of `git show` would be in association with git commit object
```bash
git show 3357d63
```
You'd get an output similar to,
commit 3357d63d8f44104940e568a1ba89fa88a16dc753
Author: John Doe <johndoe@acme.com>
Date: Tue Oct 2 00:57:38 2018 +0530
add a section on git commit --amend --author
diff --git a/src/pages/git/git-commit/index.md b/src/pages/git/git-commit/index.md
index fc9f568..8f1c8eb 100644
--- a/src/pages/git/git-commit/index.md
+++ b/src/pages/git/git-commit/index.md
@@ -73,5 +73,11 @@ Premature commits happen all the time in the course of your day-to-day developme
Amended commits are actually entirely new commits and the previous commit will no longer be on your current branch. When you're working with others, you should try to avoid amending commits if the last commit is already pushed into the repository.
+With `--amend`, one of the useful flag you could use is `--author` which enables you to change the author of the last commit you've made. Imagine a situation you haven't properly set up your name or email in git configurations but you already made a commit. With `--author` flag you can simply change them without resetting the last commit.
+
+```
+git commit --amend --author="John Doe <johndoe@email.com>"
+```
+
### More Information:
- Git documentation: [commit](https://git-scm.com/docs/git-commit)
You could just use `git show` and it will display the content of the latest git commit.
### More Information:
- [Git documentation - show](https://git-scm.com/docs/git-show)

92
mock-guide/english/git/git-squash/index.md Normal file
View File

@ -0,0 +1,92 @@
---
title: Git Squash
---
## Git Squash
One of the things that developers hear quite often regarding their pull requests is something like "That looks good to me, please squash and merge". The fun part is that there is no such command like `git squash` (unless you create an [alias](https://guide.freecodecamp.org/git/git-rebase) to it). To `squash` pull request means commonly to compact all the commits in this request into one (rarely to other number) to make it more concise, readable and not to pollute main branch's history. To achieve that developer needs to use **interactive mode** of [Git Rebase](https://guide.freecodecamp.org/git/git-rebase) command.
Quite often when you develop some new feature you end up with several intermittent commits in your history - you develop incrementally after all. That might be just some typos or steps to final solution. Most of the time there is no use in having all these commits in final public version of code, so it's more beneficial to have all of them compacted into one, single and final.
So let's assume you have following commit log in the branch you'd like to merge as part of pull request:
```shell
$ git log --pretty=oneline --abbrev-commit
30374054 Add Jupyter Notebook stub to Data Science Tools
8490f5fc Minor formatting and Punctuation changes
3233cb21 Prototype for Notebook page
```
Clearly we would prefer to have only one commit here, since there is no benefit in knowing what we started on writing and which typos we fixed there later, only final result is of importance.
So what we do is starting interactive rebase session from current **HEAD** (commit **30374054**) to commit **3233cb21**, with intention to combine **3** latest commits into one:
```shell
$ git rebase -i HEAD~3
```
That will open an editor with something like following:
```shell
pick 3233cb21 Prototype for Notebook page
pick 8490f5fc Minor formatting and Punctuation changes
pick 30374054 Add Jupyter Notebook to Data Science Tools
# Rebase
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
```
As always, Git gives us very nice help message where you can see this `squash` option we are looking for.
Currently the instructions for interactive rebase say to `pick` every specified commit **and** preserve corresponding commit message. That is - don't change anything. But we want to have only one commit in the end. Simply edit the text in you editor replacing `pick` with `squash` (or just `s`) next yo every commit we want to get rid of and save/exit the editor. That might look like this:
```shell
s 3233cb21 Prototype for Notebook page
s 8490f5fc Minor formatting and Punctuation changes
pick 30374054 Add Jupyter Notebook to Data Science Tools
```
When you close your editor saving this changes it will be reopened right away suggesting to choose and reword commit messages. Something like
```shell
# This is a combination of 3 commits.
# The first commit's message is:
Prototype for Notebook page
# This is the 2nd commit message:
Minor formatting and Punctuation changes
# This is the 3rd commit message:
Add Jupyter Notebook to Data Science Tools
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
```
At this point you can delete all the messages you don't want to be included in the final commit version, reword them or just write commit message from scratch. Just remember that new version will include all the lines that are not starting with `#` character. Once again, save and exit your editor.
Your terminal now should show a success message including `Successfully rebased and updated <branch name>` and the git log should show nice and compacted history with only one commit. All intermediary commits are gone and we are ready to merge!
### Warning about local and remote commit history mismatch
This operation is slightly dangerous if you have your branch already published in a remote repository - you are modifying commit history after all. So it's best to do squash operation on local branch before you do **push**. Sometimes, it will be already pushed - how would you create pull request after all? In this case you'll have to **force** the changes on remote branch after doing the squashing, since your local history and branch history in the remote repository are different:
``` shell
$ git push origin +my-branch-name
```
Do your best to make sure you are the only one using this remote branch at this point, or you'll make their life harder having history mismatch. But since **squashing** is usually done as the final operation on a branch before getting rid of it, it's usually not so big of a concern.

65
mock-guide/english/git/git-stash/index.md Normal file
View File

@ -0,0 +1,65 @@
---
title: Git Stash
---
## Git Stash
Git has an area called the stash where you can temporarily store a snapshot of your changes without committing them to the repository. It's separate from the working directory, the staging area, or the repository.
This functionality is useful when you've made changes to a branch that you aren't ready to commit, but you need to switch to another branch.
### Stash Changes
To save your changes in the stash, run the command:
```shell
git stash save "optional message for yourself"
```
This saves your changes and reverts the working directory to what it looked like for the latest commit. Stashed changes are available from any branch in that repository.
Note that changes you want to stash need to be on tracked files. If you created a new file and try to stash your changes, you may get the error `No local changes to save`.
### View Stashed Changes
To see what is in your stash, run the command:
```shell
git stash list
```
This returns a list of your saved snapshots in the format `stash@{0}: BRANCH-STASHED-CHANGES-ARE-FOR: MESSAGE`. The `stash@{0}` part is the name of the stash, and the number in the curly braces (`{ }`) is the index of that stash. If you have multiple change sets stashed, each one will have a different index.
If you forgot what changes were made in the stash, you can see a summary of them with `git stash show NAME-OF-STASH`. If you want to see the typical diff-style patch layout (with the +'s and -'s for line-by-line changes), you can include the `-p` (for patch) option. Here's an example:
```shell
git stash show -p stash@{0}
# Example result:
diff --git a/PathToFile/fileA b/PathToFile/fileA
index 2417dd9..b2c9092 100644
--- a/PathToFile/fileA
+++ b/PathToFile/fileA
@@ -1,4 +1,4 @@
-What this line looks like on branch
+What this line looks like with stashed changes
```
### Retrieve Stashed Changes
To retrieve changes out of the stash and apply them to the current branch you're on, you have two options:
1. `git stash apply STASH-NAME` applies the changes and leaves a copy in the stash
2. `git stash pop STASH-NAME` applies the changes and removes the files from the stash
There may be conflicts when you apply changes. You can resolve the conflicts similar to a merge (<a href='https://guide.freecodecamp.org/git/git-merge/' target='_blank' rel='nofollow'>see Git merge for details</a>).
### Delete Stashed Changes
If you want to remove stashed changes without applying them, run the command:
```shell
git stash drop STASH-NAME
```
To clear the entire stash, run the command:
```shell
git stash clear
```
### More Information:
- The `git merge` command: <a href='https://guide.freecodecamp.org/git/git-merge/' target='_blank' rel='nofollow'>fCC Guide</a>
- Git documentation: <a href='https://git-scm.com/docs/git-stash' target='_blank' rel='nofollow'>stash</a>

15
mock-guide/english/git/git-status/index.md Normal file
View File

@ -0,0 +1,15 @@
---
title: Git Status
---
## Git Status
The `git status` commands displays the state of the working directory and the staging area. It displays paths that have differences between the `index` file and the current `HEAD` commit, paths that have differences between the working tree and the `index` file, and paths in the working tree that are not tracked by Git (and are not ignored by [gitignore](https://git-scm.com/docs/gitignore)
`git status` command output does not show you any information regarding the committed project history. For this, you need to use `git log`.
### Usage
```shell
git status
```
List which files are staged, unstaged, and untracked.

17
mock-guide/english/git/git-verifying-commits/index.md Normal file
View File

@ -0,0 +1,17 @@
---
title: Git Verifying Commits
---
## Git Verifying Commits
When you’re building software with people from around the world, sometimes it’s important to validate that commits and tags are coming from an identified source. Git supports signing commits and tags with GPG. GitHub shows when commits and tags are signed.
![Verified Commits](https://cloud.githubusercontent.com/assets/25792/14253743/87b504be-fa41-11e5-9140-6dc8b7203c31.png)
When you view a signed commit or tag, you will see a badge indicating if the signature could be verified using any of the contributor’s GPG keys uploaded to GitHub. You can upload your GPG keys by visiting the keys settings page.
Many open source projects and companies want to be sure that a commit is from a verified source. GPG signature verification on commits and tags makes it easy to see when a commit or tag is signed by a verified key that GitHub knows about.
![Verified Signature](https://cloud.githubusercontent.com/assets/25792/14290042/5b27dab2-fb12-11e5-9ff9-44116a7780ea.png)
### More Information:
- [Signing Your Work](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work)

46
mock-guide/english/git/gitignore/index.md Normal file
View File

@ -0,0 +1,46 @@
---
title: Gitignore
---
## Gitignore
The `.gitignore` file is a text file that tells Git which files or folders to ignore in a project.
A local `.gitignore` file is usually placed in the root directory of a project. You can also create a global `.gitignore` file and any entries in that file will be ignored in all of your Git repositories.
To create a local `.gitignore` file, create a text file and name it `.gitignore` (remember to include the `.` at the beginning). Then edit this file as needed. Each new line should list an additional file or folder that you want Git to ignore.
The entries in this file can also follow a matching pattern.
* `*` is used as a wildcard match
* `/` is used to ignore pathnames relative to the `.gitignore` file
* `#` is used to add comments to a `.gitignore` file
This is an example of what the `.gitignore` file could look like:
```
# Ignore Mac system files
.DS_store
# Ignore node_modules folder
node_modules
# Ignore all text files
*.txt
# Ignore files related to API keys
.env
# Ignore SASS config files
.sass-cache
```
To add or change your global .gitignore file, run the following command:
```bash
git config --global core.excludesfile ~/.gitignore_global
```
This will create the file `~/.gitignore_global`. Now you can edit that file the same way as a local `.gitignore` file. All of your Git repositories will ignore the files and folders listed in the global `.gitignore` file.
### More Information:
- Git documentation: <a href='https://git-scm.com/docs/gitignore' target='_blank' rel='nofollow'>gitignore</a>
- Ignoring files: <a href='https://help.github.com/articles/ignoring-files/' target='_blank' rel='nofollow'>GitHub</a>
- Useful `.gitignore` templates: <a href='https://github.com/github/gitignore' target='_blank' rel='nofollow'>GitHub</a>

15
mock-guide/english/git/gui-options/index.md Normal file
View File

@ -0,0 +1,15 @@
---
title: GUI Options
---
## GUI Options for Git
Most people prefer to use Git as a [CLI (command-line interface)](https://en.wikipedia.org/wiki/Command-line_interface) tool, but there are plenty of [GUI (graphical user interface)](https://en.wikipedia.org/wiki/Graphical_user_interface) tools allowing you to use Git in a graphical way. GUI tools can useful to get a better view of the state of your Git repository, and some might find them easier to use than the CLI. However, knowing how to use the CLI is highly recommended because it will be the same interface on every platform, because it is generally considered to be more efficient, and because it is required as soon as you want to do something even a little bit complex.
## List of Git GUI Based Solutions
* [GitKraken](https://www.gitkraken.com) is a popular Git GUI for Windows, Mac and Linux. It is proprietary but free for non-commercial use.
* [GitHub Desktop](https://desktop.github.com/) is the Git client application provided by GitHub, allowing better integration with GitHub than other solutions. It is available for Windows and Mac, but not yet for Linux. It is free and open source.
* [SourceTree](https://www.sourcetreeapp.com/) is another Git GUI for Windows and Mac by Atlassian. It has many features such as interactive rebase, designed to make using Git easier for beginners.
* [Git Tower](https://www.git-tower.com/mac/) is available for Mac and Windows.
* [TortoiseGit](https://tortoisegit.org/) is a Windows Shell Interface to Git based on TortoiseSVN. It's open source and can be built with freely available software.
* [SmartGit](https://www.syntevo.com/smartgit/) is a Git client free for a non-commercial use for Windows, Mac and Linux.

98
mock-guide/english/git/index.md Normal file
View File

@ -0,0 +1,98 @@
---
title: Git
---
## Git
Git is an open source distributed version control system created in 2005 by Linus Torvalds and others from the Linux development community. Git can work with many types of projects, but it's most commonly used for software source code.
Version control is a system that keeps track of changes to a file or group of files over time. When you have a history of these changes, it lets you find specific versions later, compare changes between versions, recover files you may have deleted, or revert files to previous versions.
A *distributed* version control system means that different users maintain their own repositories of a project, instead of working from one central repository. Users automatically have full file tracking abilities and the project's complete version history without needing access to a central server or network.
When Git is initialized in a project directory, it begins tracking file changes and stores them as "change sets" or "patches." Users working together on a project submit their change sets which are then included (or rejected) in the project.
**Table of Contents**
- [Understand the Three Sections of a Git Project](#understand-the-three-sections-of-a-git-project)
- [Install Git](#install-git)
- [Configure the Git Environment](#configure-the-git-environment)
- [Initialize Git in a Project](#initialize-git-in-a-project)
- [Get Help in Git](#get-help-in-git)
- [Sources](#sources)
- [More Information](#more-information)
### Understand the Three Sections of a Git Project <a name="understand-the-three-sections-of-a-git-project"></a>
A Git project will have the following three main sections:
1. Git directory
2. Working directory (or working tree)
3. Staging area
The **Git directory** (located in `YOUR-PROJECT-PATH/.git/`) is where Git stores everything it needs to accurately track the project. This includes metadata and an object database which includes compressed versions of the project files.
The **working directory** is where a user makes local changes to a project. The working directory pulls the project's files from the Git directory's object database and places them on the user's local machine.
The **staging area** is a file (also called the "index", "stage", or "cache") that stores information about what will go into your next commit. A commit is when you tell Git to save these staged changes. Git takes a snapshot of the files as they are and permanently stores that snapshot in the Git directory.
With three sections, there are three main states that a file can be in at any given time: committed, modified, or staged. You *modify* a file any time you make changes to it in your working directory. Next, it's *staged* when you move it to the staging area. Finally, it's *committed* after a commit.
### Install Git <a name="install-git"></a>
- Ubuntu: `sudo apt-get install git`
- Windows: <a href="https://git-scm.com/download/win" target="_blank">Download</a>
- Mac: <a href="https://git-scm.com/download/mac" target="_blank">Download</a>
### Configure the Git Environment <a name="configure-the-git-environment"></a>
Git has a `git config` tool that allows you to customize your Git environment. You can change the way Git looks and functions by setting certain configuration variables. Run these commands from a command line interface on your machine (Terminal in Mac, Command Prompt or Powershell in Windows).
There are three levels of where these configuration variables are stored:
1. System: located in `/etc/gitconfig`, applies default settings to every user of the computer. To make changes to this file, use the `--system` option with the `git config` command.
2. User: located in `~/.gitconfig` or `~/.config/git/config`, applies settings to a single user. To make changes to this file, use the `--global` option with the `git config` command.
3. Project: located in `YOUR-PROJECT-PATH/.git/config`, applies settings to the project only. To make changes to this file, use the `git config` command.
If there are settings that conflict with each other, the project-level configurations will override the user-level ones, and the user-level configurations will override the system-level ones.
Note for Windows users: Git looks for the user-level configuration file (`.gitconfig`) in your `$HOME` directory (`C:\Users\$USER`). Git also looks for `/etc/gitconfig`, although it's relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. If you are using version 2.x or later of Git for Windows, there is also a system-level config file at `C:\Documents and Settings\All Users\Application Data\Git\config` on Windows XP, and in `C:\ProgramData\Git\config` on Windows Vista and newer. This config file can only be changed by `git config -f FILE` as an admin.
#### Add Your Name and Email
Git includes the user name and email as part of the information in a commit. You'll want to set this up under your user-level configuration file with these commands:
```shell
git config --global user.name "My Name"
git config --global user.email "myemail@example.com"
```
#### Change Your Text Editor
Git automatically uses your default text editor, but you can change this. Here's an example to use the Atom editor instead (the `--wait` option tells the shell to wait for the text editor so you can do your work in it before the program moves on):
```shell
git config --global core.editor "atom --wait"
```
#### Add Color to Git Output
You can configure your shell to add color to Git output with this command:
```shell
git config --global color.ui true
```
To see all your configuration settings, use the command `git config --list`.
### Initialize Git in a Project <a name="initialize-git-in-a-project"></a>
Once Git is installed and configured on your computer, you need to initialize it in your project to start using its version control powers. In the command line, use the `cd` command to navigate to the top-level (or root) folder for your project. Next, run the command `git init`. This installs a Git directory folder with all the files and objects Git needs to track your project.
It's important that the Git directory is installed in the project root folder. Git can track files in subfolders, but it won't track files located in a parent folder relative to the Git directory.
### Get Help in Git <a name="get-help-in-git"></a>
If you forget how any command works in Git, you can access Git help from the command line several ways:
```shell
git help COMMAND
git COMMAND --help
man git-COMMAND
```
This displays the manual page for the command in your shell window. To navigate, scroll with the up and down arrow keys or use the following keyboard shortcuts: <!-- Need to confirm these work in Windows -->
- `f` or `spacebar` to page forward
- `b` to page back
- `q` to quit
### Sources <a name="sources"></a>
This article uses information from the <a href='https://github.com/progit/progit2' target='_blank' rel='nofollow'>Pro Git</a> book, written by Scott Chacon and Ben Straub and published by Apress. The book is displayed in full in the <a href='https://git-scm.com/book/en/v2' target='_blank' rel='nofollow'>Git documentation</a>.
### More Information: <a name="more-information"></a>
- For downloads, documentation, and a browser-based tutorial: <a href='https://git-scm.com/' target='_blank' rel='nofollow'>Git official website</a>
- Most useful commands when you're in bad GIT situation: <a href='http://ohshitgit.com/' target='_blank' rel='nofollow'>Oh shit, git!</a>

218
mock-guide/english/git/tagging-in-git/index.md Normal file
View File

@ -0,0 +1,218 @@
---
title: Tagging in Git
---
Tagging lets developers mark important checkpoints in the course of their projects development. For instance, software release versions can be tagged. (Ex: v1.3.2) It essentially allows you to give a commit a special name(tag).
To view all the created tags in alphabetical order:
```bash
git tag
```
To get more information on a tag:
```bash
git show v1.4
```
There are two types of tags:
1. Annotated
```bash
git tag -a v1.2 -m "my version 1.4"
```
2. Lightweight
```bash
git tag v1.2
```
They differ in the way that they are stored.
These create tags on your current commit.
Incase, you'd like to tag a previous commit specify the commit ID you'd like to tag:
```bash
git tag -a v1.2 9fceb02
```
The tags names may be used instead of commit IDs while checking out and pushing commits to a remote repo.
#### More Information:
- Git documentation: <a href='https://git-scm.com/docs/git-tag' target='_blank' rel='nofollow'>Documentation</a>
- Git Tagging Chapter: <a href='https://git-scm.com/book/en/v2/Git-Basics-Tagging' target='_blank' rel='nofollow'>Book</a>
You can list all available tags in a project with the ```git tag``` command (nate that they will appear in alphabetical order):
```
$ git tag
v1.0
v2.0
v3.0
```
This way of listing tags is great for small projects, but greater projects can have hundreds of tags, so you may need to filter them when searching for an important point in the history. You can find tags containing specific characters adding an ```-l``` to the ```git tag``` command:
```
$ git tag -l "v2.0*"
v2.0.1
v2.0.2
v2.0.3
v2.0.4
```
## Create a tag
You can create two type of tags: annotated and lightweight. They first ones are compete objects in GIT database: they are checksummed, requiere a message (like commits) and store other important data such as name, email and date. On the other hand, lightweight tags don require a mesage or store other data, working just as a pointer to a specific point in the project.
### Create an annotated tag
To create an anotated tag, add ```-a tagname -m "tag message"``` to the ```git tag``` command:
```
$ git tag -a v4.0 -m "release version 4.0"
$ git tag
v1.0
v2.0
v3.0
v4.0
```
As you can see, the ```-a``` specifies that you are creating an annotated tag, after comes the tag name and finally, the ```-m``` followed by the tag message to store in the Git database.
### Create a lightweight tag
Lightweight tags contain only the commit checksum (no other information is stored). To create one, just run the ```git tag``` command without any other options (the -lw characters at the end of the name are used to indicate lightweight tags, but you can mark them as you like):
```
$ git tag v4.1-lw
$ git tag
v1.0
v2.0
v3.0
v4.0
v4.1-lw
```
This time you didn't specify a message or other relevant data, so the tag contains only the refered commit's checksum.
## View tag's data
You can run the ```git show``` command to view the data stored in a tag. In the case of annotated tags, you'll see the tag data and the commit data:
```
$ git show v4.0
tag v4.0
Tagger: John Cash <john@cash.com>
Date: Mon Sat 28 15:00:25 2017 -0700
release version 4.0
commit da43a5fss745av88d47839247990022a98419093
Author: John Cash <john@cash.com>
Date: Fri Feb 20 20:30:05 2015 -0700
finished details
```
If the tag you are watching is a lightweight tag, you'll only see the refered commit data:
```
$ git show v1.4-lw
commit da43a5f7389adcb9201ab0a289c389ed022a910b
Author: John Cash <john@cash.com>
Date: Fri Feb 20 20:30:05 2015 -0700
finished details
```
## Tagging old commits
You can also tag past commits using the git tag commit. In order to do this, you'll need to specify the commit's checksum (or at least a part of it) in the command's line.
First, run git log to find out the required commit's checksum:
```
$ git log --pretty=oneline
ac2998acf289102dba00823821bee04276aad9ca added products section
d09034bdea0097726fd8383c0393faa0072829a7 refactorization
a029ac120245ab012bed1ca771349eb9cca01c0b modified styles
da43a5f7389adcb9201ab0a289c389ed022a910b finished details
0adb03ca013901c1e02174924486a08cea9293a2 small fix in search textarea styles
```
When you have the checksum needed, add it at the end of the tag creation line:
```
$ git tag -a v3.5 a029ac
```
You'll see the tag was correctly added running ```git tag```:
```
$ git tag
v1.0
v2.0
v3.0
v3.5
v4.0
v4.1-lw
```
## Push tags
Git does't push tags by default when you run the git push command. So, to succesfully push a tag to a server you'll have to ```git push origin``` command:
```
$ git push origin v4.0
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (18/18), 3.15 KiB | 0 bytes/s, done.
Total 18 (delta 4), reused 0 (delta 0)
To git@github.com:jcash/gitmanual.git
* [new tag] v4.0 -> v4.0
```
You can also use the ```--tags``` option to add multiple tags at once with the ```git push origin``` command:
```
$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:jcash/gitmanual.git
* [new tag] v4.0 -> v4.0
* [new tag] v4.1-lw -> v4.1-lw
```
## Checking out Tags
You can use ```git checkout``` to checkout to a tag like you would normally do. But you need to keep in mind that this would result a *detached HEAD* state.
```
$ git checkout v0.0.3
Note: checking out 'v0.0.3'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
```
## Deleting a Tag
You may find a situation were you want to delete a certain tag. There's a very useful command for this situations:
```
$ git tag --delete v0.0.2
$ git tag
v0.0.1
v0.0.3
v0.0.4
```
### More Information
* [Git Pro - Tagging Basics](https://git-scm.com/book/en/v2/Git-Basics-Tagging)
* [Git Pro - Documentation](https://git-scm.com/docs/git-tag)
* [Git HowTo](https://githowto.com/tagging_versions)
* [Git tip: Tags](http://alblue.bandlem.com/2011/04/git-tip-of-week-tags.html)
* [Creating a tag](https://www.drupal.org/node/1066342)
### Sources
Git documentation: [tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging)