Git (한국어)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

This article or section needs to be translated.

Notes: Practically only the headings are translated (Discuss in Talk:Git (한국어))

"git이 GitHub의 프론트엔드라고 생각하는 몇몇 사람을 만나보았지만, 그들은 틀렸습니다. git은 AUR의 프론트엔드입니다. [https://public-inbox.org/git/#didyoureallythinklinuswouldsaythat Linus T."

Git is the version control system (VCS) designed and developed by Linus Torvalds, the creator of the Linux kernel. Git is now used to maintain AUR packages, as well as many other projects, including sources for the Linux kernel.

Git은 버전 관리 시스템(VCS, version control system)의 하나로, Linux 커널의 개발자이기도 한 Linus Torvalds에 의하여 설계, 개발되었다. Git은 Linux 커널을 포함하여 여러 다른 프로젝트를 관리하기 위해 사용되며, AUR 패키지의 관리에도 사용된다.

설치

Install the git package. For the development version, install the git-git^AUR package. Check the optional dependencies when using tools such as git svn, git gui and gitk.

git 패키지를 설치하면 된다. 개발 중인 버전을 설치하기를 원한다면, git-git^AUR 패키지를 설치하면 된다. git svn이나 git gui, gitk 등의 도구를 사용하기를 원한다면 선택 의존성을 확인할 것.

그래픽 프론트엔드

git GUI Clients를 참고.

Giggle — GTK 프론트엔드.

https://wiki.gnome.org/Apps/giggle/ || giggle

GitAhead — 빌트인 Merge Tool을 포함하는 그래픽 프론트엔드.

https://gitahead.github.io/gitahead.com/ || gitahead^AUR

Git Cola — Sleek and powerful graphical user interface for Git written in Python.

https://git-cola.github.io/ || git-cola^AUR

Git Extensions — Graphical user interface for Git that allows you to control Git without using the commandline.

https://gitextensions.github.io/ || gitextensions^AUR

gitg — GNOME GUI client to view git repositories.

https://wiki.gnome.org/Apps/Gitg || gitg

git-gui — Tcl/Tk based portable graphical interface to Git.

https://git-scm.com/docs/git-gui || git + tk

참고: To enable spell checking in git-gui, aspell is required, along with the dictionary corresponding to the LC_MESSAGES environment variable. See FS#28181 and the aspell article.

GitHub Desktop — Electron-based graphical user interface built by the GitHub team.

https://github.com/desktop/desktop || github-desktop^AUR github-desktop-bin^AUR

gitk — Tcl/Tk based Git repository browser.

https://git-scm.com/docs/gitk || git + tk

Guitar — Git GUI Client.

https://github.com/soramimi/Guitar || guitar^AUR

QGit — Git GUI viewer to browse revisions history, view patch content and changed files, graphically following different development branches.

https://github.com/tibirna/qgit || qgit

RabbitVCS — Set of graphical tools written to provide simple and straightforward access to the version control systems you use.

http://rabbitvcs.org/ || rabbitvcs^AUR

Sublime Merge — Git Client from the makers of Sublime Text.

https://www.sublimemerge.com/ || sublime-merge^AUR

Tig — ncurses-based text-mode interface for git.

https://jonas.github.io/tig/ || tig

ungit — Brings user friendliness to git without sacrificing the versatility of git.

https://github.com/FredrikNoren/ungit || nodejs-ungit^AUR

설정

In order to use Git you need to set at least a name and email:

$ git config --global user.name  "John Doe"
$ git config --global user.email "johndoe@example.com"

See Getting Started - First-Time Git Setup.

See #팁 for more settings.

사용방법

A Git repository is contained in a .git directory, which holds the revision history and other metadata. The directory tracked by the repository, by default the parent directory, is called the working directory. Changes in the working tree need to be staged before they can be recorded (committed) to the repository. Git also lets you restore, previously committed, working tree files.

See Getting Started - Git Basics.

Getting a Git repository

Initialize a repository

git init, see git-init(1)

Clone an existing repository

git clone repository, see git-clone(1) (also explains the Git URLs)

변경 사항 기록

Git projects have a staging area, which is an index file in your Git directory, that stores the changes that will go into your next commit. To record a modified file you therefore firstly need to add it to the index (stage it). The git commit command then stores the current index in a new commit.

변경 사항 스테이징 (staging)

Add working tree changes to the index

git add pathspec, see git-add(1)

Remove changes from the index

git reset pathspec, see git-reset(1)

Show changes to be committed, unstaged changes and untracked files

git status, see git-status(1)

You can tell Git to ignore certain untracked files using .gitignore files, see gitignore(5).

Git does not track file movement. Move detection during merges is based only on content similarity. The git mv command is just there for convenience and is equivalent to:

$ mv -i foo bar
$ git reset -- foo
$ git add bar

변경 사항 커밋

The git commit command records the staged changes to the repository, see git-commit(1).

-m – supply the commit message as an argument, instead of composing it in your default text editor
-a – automatically stage files that have been modified or deleted (does not add untracked files)
--amend – redo the last commit, amending the commit message or the committed files

도움말: Always commit small changes frequently and with meaningful messages.

수정된 버전(revision) 선택

Git offers multiple ways to specify revisions, see gitrevisions(7) and Revision Selection.

Many Git commands take revisions as arguments. A commit can be identified by any of the following:

SHA-1 hash of the commit (the first 7 digits are usually sufficient to identify it uniquely)
Any commit label such as a branch or tag name
The label HEAD always refers to the currently checked-out commit (usually the head of the branch, unless you used git checkout to jump back in history to an old commit)
Any of the above plus ~ to refer to previous commits. For example, HEAD~ refers to one commit before HEAD and HEAD~5 refers to five commits before HEAD.

변경 사항 열람

Show differences between commits:

$ git diff HEAD HEAD~3

or between staging area and working tree:

$ git diff

View history of changes (where "-N" is the number of latest commits):

$ git log -p (-N)

되돌리기

git checkout - to restore working tree files, see git-checkout(1)
git reset - reset current HEAD to the specified state, see git-reset(1)
git revert - revert some existing commits, see git-revert(1)

These, along with few others, are further explained at undoing-changes.

For more complex modifications of history, such as git commit --amend and git rebase see, for example, rewriting-history. It is highly advised not to use such rewrites for commits that were collaborated with other users. Or, at the very least, highly coordinate it in advance.

브랜치 만들기

This article or section needs expansion.

Reason: Add links for some common branching models. (Discuss in Talk:Git (한국어))

Fixes and new features are usually tested in branches. When changes are satisfactory they can merged back into the default (master) branch.

Create a branch, whose name accurately reflects its purpose:

$ git branch help-section-addition

List branches:

$ git branch

Switch branches:

$ git checkout branch

Create and switch:

$ git checkout -b branch

Merge a branch back to the master branch:

$ git checkout master
$ git merge branch

The changes will be merged if they do not conflict. Otherwise, Git will print an error message, and annotate files in the working tree to record the conflicts. The annotations can be displayed with git diff. Conflicts are resolved by editing the files to remove the annotations, and committing the final version. See #통합(머지, merge) 기능 사용하기 below.

When done with a branch, delete it with:

$ git branch -d branch

협업

A typical Git work-flow is:

Create a new repository or clone a remote one.
Create a branch to make changes; then commit those changes.
Consolidate commits for better organization/understanding.
Merge commits back into the main branch.
(Optional) Push changes to a remote server.

풀 리퀘스트 (PR)

After making and committing some changes, the contributor can ask the original author to merge them. This is called a pull request.

To pull:

$ git pull location master

The pull command combines both fetching and merging. If there are conflicts (e.g. the original author made changes in the same time span), then it will be necessary to manually fix them.

Alternatively, the original author can pick the changes wanting to be incorporated. Using the fetch option (and log option with a special FETCH_HEAD symbol), the contents of the pull request can be viewed before deciding what to do:

$ git fetch location master
$ git log -p HEAD..FETCH_HEAD
$ git merge location master

원격 저장소 사용하기

Remotes are aliases for tracked remote repositories. A label is created defining a location. These labels are used to identify frequently accessed repositories.

Create a remote:

$ git remote add label location

Fetch a remote:

$ git fetch label

Show differences between master and a remote master:

$ git log -p master..label/master

View remotes for the current repository:

$ git remote -v

When defining a remote that is a parent of the fork (the project lead), it is defined as upstream.

저장소에 푸시하기

After being given rights from the original authors, push changes with:

$ git push location branch

When git clone is performed, it records the original location and gives it a remote name of origin.

So what typically is done is this:

$ git push origin master

If the -u (--set-upstream) option is used, the location is recorded so the next time just a git push is necessary.

통합(머지, merge) 기능 사용하기

See Basic Merge Conflicts in the Git Book for a detailed explanation on how to resolve merge conflicts. Merges are generally reversible. If wanting to back out of a merge one can usually use the --abort command (e.g. git merge --abort or git pull --abort).

히스토리와 버전

히스토리 검색하기

git log will give the history with a commit checksum, author, date, and the short message. The checksum is the "object name" of a commit object, typically a 40-character SHA-1 hash.

For history with a long message (where the "checksum" can be truncated, as long as it is unique):

$ git show (checksum)

Search for pattern in tracked files:

$ git grep pattern

Search in .c and .h files:

$ git grep pattern -- '*.[ch]'

태그 기능 사용하기

Tag commits for versioning:

$ git tag 2.14 checksum

Tagging is generally done for releasing/versioning but it can be any string. Generally annotated tags are used, because they get added to the Git database.

Tag the current commit with:

$ git tag -a 2.14 -m "Version 2.14"

List tags:

$ git tag -l

Delete a tag:

$ git tag -d 2.08

Update remote tags:

$ git push --tags

커밋 정리하기

Before submitting a pull request it may be desirable to consolidate/organize the commits. This is done with the git rebase --interactive option:

$ git rebase -i checksum

This will open the editor with a summary of all the commits in the range specified; in this case including the newest (HEAD) back to, but excluding, commit checksum. Or to use a number notation, use for example HEAD~3, which will rebase the last three commits:

pick d146cc7 Mountpoint test.
pick 4f47712 Explain -o option in readme.
pick 8a4d479 Rename documentation.

Editing the action in the first column will dictate how the rebase will be done. The options are:

pick — Apply this commit as is (the default).
edit — Edit files and/or commit message.
reword — Edit commit message.
squash — Merge/fold into previous commit.
fixup — Merge/fold into previous commit discarding its message.

The commits can be re-ordered or erased from the history (but be very careful with these). After editing the file, Git will perform the specified actions; if prompted to resolve merge problems, fix them and continue with git rebase --continue or back out with the git rebase --abort command.

참고: Squashing commits is only used for local commits, it will cause troubles on a repository that is shared by other people.

팁

git-config 사용하기

Git reads its configuration from four INI-type configuration files:

/etc/gitconfig for system-wide defaults
~/.gitconfig and ~/.config/git/config (since 1.7.12) for user-specific configuration
.git/config for repository-specific configuration

These files can be edited directly, but the usual method is to use git config, as shown in the examples below.

List the currently set variables:

$ git config {--local,--global,--system} --list

Set the default editor from vim to nano:

$ git config --global core.editor "nano -w"

Set the default push action:

$ git config --global push.default simple

Set a different tool for git difftool (meld by default):

$ git config --global diff.tool vimdiff

See git-config(1) and Git Configuration for more information.

에티켓 존중하기

When considering contributing to an existing project, read and understand its license, as it may excessively limit your ability to change the code. Some licenses can generate disputes over the ownership of the code.
Think about the project's community and how well you can fit into it. To get a feeling of the direction of the project, read any documentation and even the log of the repository.
When requesting to pull a commit, or submit a patch, keep it small and well documented; this will help the maintainers understand your changes and decide whether to merge them or ask you to make some amendments.
If a contribution is rejected, do not get discouraged, it is their project after all. If it is important, discuss the reasoning for the contribution as clearly and as patiently as possible: with such an approach a resolution may eventually be possible.

인증

You may wish to avoid the hassle of authenticating interactively at every push to the Git server.

If you are authenticating with SSH keys, use an SSH agent. See also OpenSSH#Speeding up SSH and OpenSSH#Keep alive.
If you are authenticating with username and password, switch to SSH keys if the server supports SSH, otherwise try git-credential-cache or git-credential-store.

프로토콜 기본값

If you are running a multiplexed SSH connection as shown above, Git over SSH might be faster than HTTPS. Also, some servers (like the AUR) only allow pushing via SSH. For example, the following config will set Git over SSH for any repository hosted on the AUR.

~/.gitconfig

[url "ssh://aur@aur.archlinux.org/"]
	insteadOf = https://aur.archlinux.org/
	insteadOf = http://aur.archlinux.org/
	insteadOf = git://aur.archlinux.org/

bash 자동완성

In order to enable Bash completion, source /usr/share/git/completion/git-completion.bash in a Bash startup file. Alternatively, install bash-completion.

Git 프롬프트

The Git package comes with a prompt script. To enable it, source the /usr/share/git/completion/git-prompt.sh and set a custom prompt with the %s parameter:

For Bash: PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
For zsh: setopt PROMPT_SUBST ; PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ '

Note that the command substitution must be escaped, see Bash/Prompt customization#Embedding commands for details. See Command-line shell#Configuration files for persistent configuration.

When changing to a directory of a Git repository, the prompt will change to show the branch name. Extra details can be set to be shown by the prompt:


Shell variable	Information
GIT_PS1_SHOWDIRTYSTATE	+ for staged, * if unstaged.
GIT_PS1_SHOWSTASHSTATE	$ if something is stashed.
GIT_PS1_SHOWUNTRACKEDFILES	% if there are untracked files.
GIT_PS1_SHOWUPSTREAM	<,>,<> behind, ahead, or diverged from upstream.

GIT_PS1_SHOWUPSTREAM will need to be set to auto for changes to take effect.

참고: If you experience that $(__git_ps1) returns ((unknown)), then there is a .git folder in your current directory which does not contain any repository, and therefore Git does not recognize it. This can, for example, happen if you mistake Git's configuration file to be ~/.git/config instead of ~/.gitconfig.

Alternatively, you can use one of git shell prompt customization packages from AUR such as bash-git-prompt^AUR or gittify^AUR.

시각 효과

To get an idea of the amount of work done:

$ git diff --stat

git log with forking representation:

$ git log --graph --oneline --decorate

git log graph alias (i.e. git graph will show a decorated version):

$ git config --global alias.graph 'log --graph --oneline --decorate'

커밋에 관한 팁

Reset to previous commit (very dangerous, erases everything to specified commit):

$ git reset --hard HEAD^

If a repository address gets changed, its remote location will need to be updated:

$ git remote set-url origin git@address:user/repo.git

Signed-off-by line append (a name-email signature is added to the commit which is required by some projects):

$ git commit -s

Signed-off-by automatically append to patches (when using git format-patch commit):

$ git config --local format.signoff true

Commit specific parts of files that have changed. This is useful if there are a large number of changes made that would be best split into several commits:

$ git add -p

커밋 서명하기

Git allows commits and tags to be signed using GnuPG, see Signing Your Work.

참고: To use pinentry curses for GPG signing make sure to export GPG_TTY=$(tty) (alternatively use pinentry-tty) otherwise the signing step will fail if GPG is currently in a locked state (since it cannot prompt for pin).

To configure Git to automatically sign commits:

$ git config --global commit.gpgSign true

master 브랜치가 아닌 브랜치에서 작업하기

Occasionally a maintainer will ask that work be done on a branch. These branches are often called devel or testing. Begin by cloning the repository.

To enter another branch beside master (git clone only shows master branch but others still exist, git branch -a to show):

$ git checkout -b branch origin/branch

Now edit normally; however to keep the repository tree in sync be sure to use both:

$ git pull --all
$ git push --all

메일링 리스트에 직접 패치 보내기

If you want to send patches directly to a mailing list, you have to install the following packages: perl-authen-sasl, perl-net-smtp-ssl and perl-mime-tools.

Make sure you have configured your username and e-mail address, see #설정.

Configure your e-mail settings:

$ git config --global sendemail.smtpserver smtp.example.com
$ git config --global sendemail.smtpserverport 587
$ git config --global sendemail.smtpencryption tls
$ git config --global sendemail.smtpuser foobar@example.com

Now you should be able to send the patch to the mailing list (see also OpenEmbedded:How to submit a patch to OpenEmbedded#Sending patches):

$ git add filename
$ git commit -s
$ git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1

원격 저장소의 크기가 큰 경우

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Reason: Uses informal language, contractions, HTML tags instead of code templates and does not use interwiki links. (Discuss in Talk:Git (한국어))

When the remote repo is huge, the following solutions can be used. The examples are taken from the linux kernel.

간단한 방법: 전체 저장소 불러오기

You can get the entire repository by

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

This download takes long - "git clone" can not be resumed once it's stopped, as of Aug 2018 - and it will cost some hard drive space.

You can update your repo by git pull.

부분 불러오기

Probably you want to limit your local repository smaller, say after v4.14 to bisect a bug. Then do:

$ git clone --shallow-exclude v4.13   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git # You will get v4.14 and later, but not v4.13 and older.

Or maybe you only want the latest snapshot, ignoring all history. (If a tarball is available and it suffices, choose that. Getting a git repo costs more.) You can do it by:

$ git clone --depth 1 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

You can later obtain older commits, by e.g.

$ git fetch --tags --shallow-exclude v4.1 # Get the commits after v4.1.
$ git fetch --tags --shallow-since 2016-01-01

Without --tags, tags will not be fetched.

다른 브랜치 불러오기

Your local repo tracks, in the above example, only the mainline kernel, i.e. in which the latest development is done. Suppose you want the latest LTS, for example the up-to-date 4.14 branch. You can get it by:

$ git remote set-branches --add origin linux-4.17.y
$ git fetch
$ git branch --track linux-4.17.y origin/linux-4.17.y

The last line is not mandatory, but probably you want it. (To know the name of the branch you want, sorry, there is no general rule. You can guess one by seeing the "ref" link in the gitweb interface.)

If you want the snapshot of linux-4.17.y, do

$ git checkout -b linux-4.17.y

Or to extract it in another directory,

$ mkdir /foo/bar/src-4.17; cd /foo/bar/src-4.17
$ git clone --no-local --depth 1 -b linux-4.17.y  ../linux-stable

As usual, do git pull to update your snapshot.

대체재

Git Virtual Filesystem (GVFS), developed by Microsoft, allows you to access git repositories without a local one. (See this Microsoft blog or the Wikipedia article.) It's not available in Linux yet.

Anyway it is not for the above examples of the Linux kernel, though.

민감한 정보 가리기

Occasionally, software may keep plain-text passwords in configuration files, as opposed to hooking into a keyring. In these cases, git clean-filters may be handy to avoid accidentally commiting confidential information. E. g., the following file assigns a filter to the file “some-dotfile”:

.gitattributes

some-dotfile filter=remove-pass

Whenever the file “some-dotfile” is checked into git, git will invoke the filter “remove-pass” on the file before checking it in. The filter must be defined in the git-configuration file, e. g.:

.git/config

[filter "remove-pass"]
clean = "sed -e 's/^password=.*/#password=TODO/'"

HTML 도움말 파일

The git help documentation is also available in HTML form by installing git-htmldocs^AUR. After installing, the HTML docs can be accessed by passing the -w flag. For example:

$ git help -w merge

The HTML documentation can be loaded by default by setting a git config option:

$ git config --global help.format html

확장

You can use gitflow to easily manage a repository using Vincent Driessen's branching model.

gitflow-avh — Extend git with Vincent Driessen's branching model. The AVH Edition adds more functionality.

https://github.com/petervanderdoes/gitflow/ || gitflow-avh^AUR