Git

Git

Git is a distributed version management system based on snapshot streams to track changes in computer files
and coordinate the work of those files among multiple users.

basis

Git has several basis, it is important to know their concepts.

repository:
This represents the storage stored on a project-by-project basis.
A repository is a “container” that tracks all changes to a project file.

commit:
This is a record of updates to the code.
It is separated by the hash value.

branch:
A split it during shape management.
If you are working temporarily for updates
or tests with other purposes, create and apply new ones.

info

Web: https://github.com, https://about.gitlab.com

Documentation: https://git-scm.com/docs/git

Author’s: https://github.com/how2flow

Status

Git has four file status.

- untracked
- staged
- commited
- modified

Untracked

New files with no record in the repository.
The git add command puts it in a staged state, and after the commit is registered,
it becomes trakable.

staged

This is the state that is in the stage before it is reflected in the commit.
The git add command puts it in the stage state.
he ‘git restore –staged’ command allows you to revert to the Untracked state.

commited

Staged files are in the state where commit was created with the git commit command.

modified

Status of files modified from the current commit.
You must perform a stage to reflect the changes in the next commit.

git-add

It is a command to add untracked or modified files in a stage state that can be registered to the commit.

$ git add <target>

git-restore

Restore the modified files to the criteria currently stored in the commit.

$ git restore <target>

Functions

The Git supports several functions. It writes some of the most common uses.

- clone
- commit
- fetch
- merge
- push
- pull
- rebase
- rebase --interactive
- cherry-pick

clone

Replicate the git repository on the server to the local environment.

$ git clone <url>

commit

You can make files in a staged state into a commit.

$ git commit

fetch

Download objects and refs from another repository

$ git fetch <remote-name|url>

It is often used for tasks such as merging or rebasing from other repositories.
Only the information on the repository was downloaded,
It will be in a traceable state.

All kinds of locally performed mergers must have information about the target
(that is, fetch is required )

case 1. Merging between different branches of the same repository
There is no problem if you clone all-things.
But in other cases,
For example, if you cloned with the options such as –single-branch option or the –depth 1 option,
If there is only a fraction of a clone that does not have a complete clone,
you must fetch if the target is not currently in your local environment.

merge

Literally used to merge modifications with existing code.

$ git merge <target-branch|target-commit>

When you merge between branches, the merged commit is created separately.
It is called 3-way-merge .

Merging in the same brenches or
between different brenches but with no branched history is
fast-forward merging.

I don’t prefer Merge because it usually messes up the history.

push

Push the locally updated repository to the server repository.

$ git push <remote-name> <branch>

The push can be done in the unit of the brenches.

pull

It’s fetch + merge together.

$ git pull <remote-name> <branch>

Download the target repository object and refs stored on the server, and at the same time merge it.
If the local history is linked to the server’s history, it is fast-forward merge ,
and if not, it is 3-way-merge .

rebase

It does the same thing as merge, which is used to merge brenches or commits,
but the method is different.

Rebase aligns and merges the order between commitments.

$ git rebase <to-be-parents-branch|to-be-parents-commit>

The difference from merge is that request is the commit to be one’s own parent, not the target to merge.
Merging commits using the rebase cleans up the history.

rebase –interactive

You can proceed with the rebase in multiple options at once.

$ git rebase -i <target-commit>

From the head commit to the child commit of the target commit, it is subject to rebase.
The target commit may use a hash like other commands that receive the commit as a parameter,
or may use any representation method that may specify the commit, such as a branch name, tag name, and location from HEAD.

There are several options that are supported when performing interactive.
edit/e : Modifying the contents of the commit operation
exec/x : Commands that allow you to enter shell commands to run during the database
pick/p : Use the commit as it is. You can also rearrange or delete the commit
reword/r : Commands to modify commit messages
squash/s : Commands that combine that commit with the previous commit

cherry-pick

take a commit you want and stack it over the current HEAD.
Again, the local environment must have the corresponding commit information.

$ git cherry-pick <target-branch|target-commit>

Others

Refer to Documentation