Everyday Git

NAME名

giteveryday - A useful minimum set of commands for Everyday Gitgiteveryday - Everyday Gitに役立つ最小限のコマンドセット

SYNOPSIS概要

Everyday Git With 20 Commands Or So毎日20のコマンドでGit

DESCRIPTION説明

Git users can broadly be grouped into four categories for the purposes of describing here a small set of useful command for everyday Git.Gitユーザーは、ここで日常のGitに役立つ一連の便利なコマンドを説明するために、大きく4つのカテゴリに分類できます。

Individual Developer (Standalone) commands are essential for anybody who makes a commit, even for somebody who works alone.個々の開発者（スタンドアロン）コマンドは、一人で作業する誰かにとってさえ、コミットをする人にとっては不可欠です。
If you work with other people, you will need commands listed in the Individual Developer (Participant) section as well.他の人と仕事をする場合は、個人開発者（参加者）セクションにもリストされているコマンドが必要になります。
People who play the Integrator role need to learn some more commands in addition to the above.インテグレータの役割を果たす人々は、上記に加えてさらにいくつかのコマンドを学ぶ必要があります。
Repository Administration commands are for system administrators who are responsible for the care and feeding of Git repositories.リポジトリ管理コマンドは、Gitリポジトリの管理とフィードを担当するシステム管理者向けです。

Individual Developer (Standalone)個別開発者（スタンドアロン）

A standalone individual developer does not exchange patches with other people, and works alone in a single repository, using the following commands.スタンドアロンの個々の開発者は、他の人とパッチを交換することはなく、次のコマンドを使用して単一のリポジトリ内で単独で動作します。

git-init[1] to create a new repository.git-init [1]で新しいリポジトリを作成します。
git-log[1] to see what happened.何が起こったのかを見るにはgit-log [1]を見てください。
git-checkout[1] and git-branch[1] to switch branches.git-checkout [1]とgit-branch [1]で分岐を切り替えます。
git-add[1] to manage the index file.インデックスファイルを管理するためのgit-add [1]。
git-diff[1] and git-status[1] to see what you are in the middle of doing.git-diff [1]とgit-status [1]を実行して、作業中の状況を確認してください。
git-commit[1] to advance the current branch.git-commit [1]を実行して現在のブランチを進めます。
git-reset[1] and git-checkout[1] (with pathname parameters) to undo changes.変更を取り消すには、git-reset [1]およびgit-checkout [1]（パス名パラメーター付き）。
git-merge[1] to merge between local branches.ローカルブランチ間でマージするにはgit-merge [1]。
git-rebase[1] to maintain topic branches.トピックブランチを管理するためのgit-rebase [1]
git-tag[1] to mark a known point.既知の点をマークするにはgit-tag [1]を使ってください。

Examples例

Use a tarball as a starting point for a new repository. 新しいリポジトリの出発点としてtarballを使用してください。

$ tar zxf frotz.tar.gz
$ cd frotz
$ git init
$ git add . (1)
$ git commit -m "import of frotz source tree."
$ git tag v2.43 (2)

add everything under the current directory.現在のディレクトリの下にすべてを追加します。
make a lightweight, unannotated tag.注釈のない軽量のタグを作成します。

Create a topic branch and develop. トピックブランチを作成して開発します。

$ git checkout -b alsa-audio (1)
$ edit/compile/test
$ git checkout -- curses/ux_audio_oss.c (2)
$ git add curses/ux_audio_alsa.c (3)
$ edit/compile/test
$ git diff HEAD (4)
$ git commit -a -s (5)
$ edit/compile/test
$ git diff HEAD^ (6)
$ git commit -a --amend (7)
$ git checkout master (8)
$ git merge alsa-audio (9)
$ git log --since='3 days ago' (10)
$ git log v2.43.. curses/ (11)

create a new topic branch.新しいトピックブランチを作成します。
revert your botched changes in curses/ux_audio_oss.c.の変更を元に戻しますcurses/ux_audio_oss.c。
you need to tell Git if you added a new file; removal and modification will be caught if you do git commit -a later.新しいファイルを追加した場合はGitに伝える必要があります。git commit -a後で削除したり変更したりするとキャッチされます。
to see what changes you are committing.どの変更をコミットしているかを確認するため。
commit everything, as you have tested, with your sign-off.あなたがテストしたように、あなたのサインオフですべてをコミットしなさい。
look at all your changes including the previous commit.前回のコミットを含め、すべての変更を見てください。
amend the previous commit, adding all your new changes, using your original message.元のメッセージを使用して、前のコミットを修正し、新しい変更をすべて追加します。
switch to the master branch.マスターブランチに切り替えます。
merge a topic branch into your master branch.トピックブランチをマスターブランチにマージします。
review commit logs; other forms to limit output can be combined and include -10 (to show up to 10 commits), --until=2005-12-10, etc.コミットログを確認します。出力を制限する他の形式を組み合わせて含めることができます-10（最大10コミットまで表示する--until=2005-12-10など）など
view only the changes that touch what’s in curses/ directory, since v2.43 tag.tag curses/以降、ディレクトリの内容に影響する変更のみを表示しますv2.43。

Individual Developer (Participant)個別開発者（参加者）

A developer working as a participant in a group project needs to learn how to communicate with others, and uses these commands in addition to the ones needed by a standalone developer.グループプロジェクトに参加する開発者は、他の人とコミュニケーションをとる方法を学ぶ必要があり、これらのコマンドをスタンドアロン開発者が必要とするものに加えて使用します。

git-clone[1] from the upstream to prime your local repository.あなたのローカルリポジトリを準備するために上流からgit-clone [1]。
git-pull[1] and git-fetch[1] from "origin" to keep up-to-date with the upstream.git-pull [1]とgit-fetch [1]を "origin"から最新のものに更新します。
git-push[1] to shared repository, if you adopt CVS style shared repository workflow.CVSスタイルの共有リポジトリワークフローを採??用している場合は、git-push [1]を共有リポジトリへ。
git-format-patch[1] to prepare e-mail submission, if you adopt Linux kernel-style public forum workflow.Linuxカーネル形式のパブリックフォーラムワークフローを採??用している場合、git-format-patch [1]で電子メール送信を準備します。
git-send-email[1] to send your e-mail submission without corruption by your MUA.あなたのMUAによる破損なしにあなたのEメール投稿を送るためのgit-send-email [1]。
git-request-pull[1] to create a summary of changes for your upstream to pull.上流へのプルの変更の要約を作成するにはgit-request-pull [1]。

Examples例

Clone the upstream and work on it. Feed changes to upstream. 上流のクローンを作成して作業します。上流への変更をフィードします。

$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
$ cd my2.6
$ git checkout -b mine master (1)
$ edit/compile/test; git commit -a -s (2)
$ git format-patch master (3)
$ git send-email --to="person <email@example.com>" 00*.patch (4)
$ git checkout master (5)
$ git pull (6)
$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 (7)
$ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git (8)
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL (9)
$ git reset --hard ORIG_HEAD (10)
$ git gc (11)

checkout a new branch mine from master.minemasterから新しいブランチをチェックアウトします。
repeat as needed.必要に応じて繰り返してください。
extract patches from your branch, relative to master,あなたのブランチからmasterを基準にしてパッチを抽出します。
and email them.そしてそれらを電子メールで送ってください。
return to master, ready to see what’s newに戻ってmaster、何が新しいのか見てみましょう
git pull fetches from origin by default and merges into the current branch.git pulloriginデフォルトでから取得し、現在のブランチにマージします。
immediately after pulling, look at the changes done upstream since last time we checked, only in the area we are interested in.引っ張った直後に、最後に確認してから上流で行われた変更を確認します。関心のある領域でのみ確認してください。
check the branch names in an external repository (if not known).（未知の場合）外部リポジトリのブランチ名を確認してください。
fetch from a specific branch ALL from a specific repository and merge it.ALL特定のリポジトリから特定のブランチから取得してマージします。
revert the pull.引きを元に戻します。
garbage collect leftover objects from reverted pull.残ったオブジェクトを元の状態に戻した後のガベージコレクション。

Push into another repository. 別のリポジトリにプッシュします。

satellite$ git clone mothership:frotz frotz (1)
satellite$ cd frotz
satellite$ git config --get-regexp '^(remote|branch)\.' (2)
remote.origin.url mothership:frotz
remote.origin.fetch refs/heads/*:refs/remotes/origin/*
branch.master.remote origin
branch.master.merge refs/heads/master
satellite$ git config remote.origin.push \
	   +refs/heads/*:refs/remotes/satellite/* (3)
satellite$ edit/compile/test/commit
satellite$ git push origin (4)
mothership$ cd frotz
mothership$ git checkout master
mothership$ git merge satellite/master (5)

mothership machine has a frotz repository under your home directory; clone from it to start a repository on the satellite machine.mothership machineはあなたのホームディレクトリの下にfrotzリポジトリを持っています。そこからクローンを作成して、サテライトマシンのリポジトリを起動します。
clone sets these configuration variables by default. It arranges git pull to fetch and store the branches of mothership machine to local remotes/origin/* remote-tracking branches.cloneはデフォルトでこれらの設定変数を設定します。これはgit pull、マザーシップマシンのブランチをローカルのremotes/origin/*リモートトラッキングブランチに取得して保存するように手配します。
arrange git push to push all local branches to their corresponding branch of the mothership machine.git pushすべてのローカルブランチをマザーシップマシンの対応するブランチにプッシュするように手配する。
push will stash all our work away on remotes/satellite/* remote-tracking branches on the mothership machine. You could use this as a back-up method. Likewise, you can pretend that mothership "fetched" from you (useful when access is one sided).pushはremotes/satellite/*、マザーシップマシン上のリモートトラッキングブランチに対する私たちのすべての作業を妨げるでしょう。あなたはこれをバックアップ方法として使うことができます。同様に、あなたはその母性があなたから「取った」ふりをすることができます（アクセスが一方的な場合に役立ちます）。
on mothership machine, merge the work done on the satellite machine into the master branch.マザーシップマシンでは、サテライトマシンで行われた作業をマスターブランチにマージします。

Branch off of a specific tag. 特定のタグから分岐します。

$ git checkout -b private2.6.14 v2.6.14 (1)
$ edit/compile/test; git commit -a
$ git checkout master
$ git cherry-pick v2.6.14..private2.6.14 (2)

create a private branch based on a well known (but somewhat behind) tag.よく知られている（しかしやや遅れている）タグに基づいてプライベートブランチを作成します。
forward port all changes in private2.6.14 branch to master branch without a formal "merging". Or longhand
git format-patch -k -m --stdout v2.6.14..private2.6.14 | git am -3 -k正式な「マージ」を行わずに、ブランチ内のすべての変更をprivate2.6.14ブランチに転送しますmaster。または速記
git format-patch -k -m --stdout v2.6.14..private2.6.14 | git am -3 -k

An alternate participant submission mechanism is using the git request-pull or pull-request mechanisms (e.g as used on GitHub (www.github.com) to notify your upstream of your contribution.代替の参加者提出メカニズムはgit request-pull、あなたの貢献をあなたの上流に通知するために、（またはGitHub（www.github.com）で使用されるような）プルまたはプル要求メカニズムを使用しています。

Integratorインテグレータ

A fairly central person acting as the integrator in a group project receives changes made by others, reviews and integrates them and publishes the result for others to use, using these commands in addition to the ones needed by participants.グループプロジェクトでインテグレータとして機能するかなり中心的な人が、他の人が加えた変更を受け取り、それらをレビューして統合し、他の人が使用できるように結果を公開します。

This section can also be used by those who respond to git request-pull or pull-request on GitHub (www.github.com) to integrate the work of others into their history. A sub-area lieutenant for a repository will act both as a participant and as an integrator.このセクションはgit request-pull、GitHub（www.github.com）に返信したり、GitHubでプルリクエストしたりして、他の人の仕事を自分の歴史に統合するためにも使用できます。リポジトリのサブエリアの中尉は、参加者としてもインテグレータとしても行動するでしょう。

git-am[1] to apply patches e-mailed in from your contributors.あなたの貢献者から電子メールで送られてきたパッチを適用するためのgit-am [1]。
git-pull[1] to merge from your trusted lieutenants.git-pull [1]してあなたの信頼できる中尉からマージしてください。
git-format-patch[1] to prepare and send suggested alternative to contributors.git-format-patch [1]は提案された代替案を作成し貢献者に送るためのものです。
git-revert[1] to undo botched commits.コミットされたコミットを元に戻すにはgit-revert [1]。
git-push[1] to publish the bleeding edge.最先端を公表するためにgit-push [1]。

Examples例

A typical integrator’s Git day. 典型的なインテグレータのGitの日。

$ git status (1)
$ git branch --no-merged master (2)
$ mailx (3)
& s 2 3 4 5 ./+to-apply
& s 7 8 ./+hold-linus
& q
$ git checkout -b topic/one master
$ git am -3 -i -s ./+to-apply (4)
$ compile/test
$ git checkout -b hold/linus && git am -3 -i -s ./+hold-linus (5)
$ git checkout topic/one && git rebase master (6)
$ git checkout pu && git reset --hard next (7)
$ git merge topic/one topic/two && git merge hold/linus (8)
$ git checkout maint
$ git cherry-pick master~4 (9)
$ compile/test
$ git tag -s -m "GIT 0.99.9x" v0.99.9x (10)
$ git fetch ko && for branch in master maint next pu (11)
    do
	git show-branch ko/$branch $branch (12)
    done
$ git push --follow-tags ko (13)

see what you were in the middle of doing, if anything.何かしているのなら、あなたがやっている途中のことを見てください。
see which branches haven’t been merged into master yet. Likewise for any other integration branches e.g. maint, next and pu (potential updates).どのブランチがmasterまだマージされていないかを確認します。同様に、他の統合支店などのためmaint、nextおよびpu（潜在的な更新）。
read mails, save ones that are applicable, and save others that are not quite ready (other mail readers are available).メールを読み、適切なものを保存し、そしてまだ準備ができていないものを保存します（他のメールリーダーが利用可能です）。
apply them, interactively, with your sign-offs.あなたのサインオフで、インタラクティブにそれらを適用します。
create topic branch as needed and apply, again with sign-offs.必要に応じてトピックブランチを作成し、再度サインオフして適用します。
rebase internal topic branch that has not been merged to the master or exposed as a part of a stable branch.マスターにマージされていない、または安定版ブランチの一部として公開されていない内部トピックブランチをリベースします。
restart pu every time from the next.pu次回から毎回再起動します。
and bundle topic branches still cooking.トピックの枝はまだ調理中です。
backport a critical fix.重要な修正をバックポートする。
create a signed tag.署名付きタグを作成します。
make sure master was not accidentally rewound beyond that already pushed out.マスターが誤ってすでに押し出された範囲を超えて巻き戻されていないことを確認してください。
In the output from git show-branch, master should have everything ko/master has, and next should have everything ko/next has, etc.からの出力ではgit show-branch、masterすべてko/masterが持っているnext必要がko/nextあり、すべてが持っている必要があります、など
push out the bleeding edge, together with new tags that point into the pushed history.プッシュされた履歴を指す新しいタグとともに、最先端を押し出します。

In this example, the ko shorthand points at the Git maintainer’s repository at kernel.org, and looks like this:この例では、ko省略形はkernel.orgにあるGitメンテナのリポジトリを指しています。

(in .git/config)
[remote "ko"]
	url = kernel.org:/pub/scm/git/git.git
	fetch = refs/heads/*:refs/remotes/ko/*
	push = refs/heads/master
	push = refs/heads/next
	push = +refs/heads/pu
	push = refs/heads/maint

Repository Administrationリポジトリ管理

A repository administrator uses the following tools to set up and maintain access to the repository by developers.リポジトリ管理者は次のツールを使用して、開発者によるリポジトリへのアクセスを設定および管理します。

git-daemon[1] to allow anonymous download from repository.リポジトリからの匿名ダウンロードを許可するgit-daemon [1]。
git-shell[1] can be used as a restricted login shell for shared central repository users.git-shell [1]は、共有中央リポジトリユーザーのための制限付きログインシェルとして使うことができます。
git-http-backend[1] provides a server side implementation of Git-over-HTTP ("Smart http") allowing both fetch and push services.git-http-backend [1]は、フェッチサービスとプッシュサービスの両方を可能にするGit-over-HTTP（ "Smart http"）のサーバー側の実装を提供します。
gitweb[1] provides a web front-end to Git repositories, which can be set-up using the git-instaweb[1] script.gitweb [1]はGitリポジトリへのWebフロントエンドを提供します。これはgit-instaweb [1]スクリプトを使用して設定できます。

update hook howto has a good example of managing a shared central repository.update hook howtoは共有中央リポジトリを管理する良い例です。

In addition there are a number of other widely deployed hosting, browsing and reviewing solutions such as:その他にも、次のような、広く普及しているホスティング、ブラウズ、およびレビューのためのソリューションが多数あります。

gitolite, gerrit code review, cgit and others.gitolite、gerritコードレビュー、cgitなど。

Examples例

We assume the following in /etc/services / etc / servicesを以下とします

$ grep 9418 /etc/services
git		9418/tcp		# Git Version Control System

Run git-daemon to serve /pub/scm from inetd. inetdから/ pub / scmを提供するためにgit-daemonを実行します。

$ grep git /etc/inetd.conf
git	stream	tcp	nowait	nobody \
  /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm

The actual configuration line should be on one line.実際の設定行は1行にする必要があります。

Run git-daemon to serve /pub/scm from xinetd. xinetdから/ pub / scmを提供するためにgit-daemonを実行します。

$ cat /etc/xinetd.d/git-daemon
# default: off
# description: The Git server offers access to Git repositories
service git
{
	disable = no
	type            = UNLISTED
	port            = 9418
	socket_type     = stream
	wait            = no
	user            = nobody
	server          = /usr/bin/git-daemon
	server_args     = --inetd --export-all --base-path=/pub/scm
	log_on_failure  += USERID
}

Check your xinetd(8) documentation and setup, this is from a Fedora system. Others might be different.xinetd（8）のドキュメントと設定を確認してください。これはFedoraシステムからのものです。他の人は違うかもしれません。

Give push/pull only access to developers using git-over-ssh. git-over-sshを使用している開発者だけにpush / pullアクセスを与えてください。

e.g. those using: $ git push/pull ssh://host.xz/pub/scm/project例： $ git push/pull ssh://host.xz/pub/scm/project

$ grep git /etc/passwd (1)
alice:x:1000:1000::/home/alice:/usr/bin/git-shell
bob:x:1001:1001::/home/bob:/usr/bin/git-shell
cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
david:x:1003:1003::/home/david:/usr/bin/git-shell
$ grep git /etc/shells (2)
/usr/bin/git-shell

log-in shell is set to /usr/bin/git-shell, which does not allow anything but git push and git pull. The users require ssh access to the machine.ログインシェルは何でも許可していないの/ usr / binに/ gitのシェルに設定されているgit pushとしますgit pull。ユーザーはマシンへのSSHアクセスを必要とします。
in many distributions /etc/shells needs to list what is used as the login shell.多くのディストリビューションで、/ etc / shellsはログインシェルとして使われているものをリストする必要があります。

CVS-style shared repository. CVSスタイルの共有リポジトリ

$ grep git /etc/group (1)
git:x:9418:alice,bob,cindy,david
$ cd /home/devo.git
$ ls -l (2)
  lrwxrwxrwx   1 david git    17 Dec  4 22:40 HEAD -> refs/heads/master
  drwxrwsr-x   2 david git  4096 Dec  4 22:40 branches
  -rw-rw-r--   1 david git    84 Dec  4 22:40 config
  -rw-rw-r--   1 david git    58 Dec  4 22:40 description
  drwxrwsr-x   2 david git  4096 Dec  4 22:40 hooks
  -rw-rw-r--   1 david git 37504 Dec  4 22:40 index
  drwxrwsr-x   2 david git  4096 Dec  4 22:40 info
  drwxrwsr-x   4 david git  4096 Dec  4 22:40 objects
  drwxrwsr-x   4 david git  4096 Nov  7 14:58 refs
  drwxrwsr-x   2 david git  4096 Dec  4 22:40 remotes
$ ls -l hooks/update (3)
  -r-xr-xr-x   1 david git  3536 Dec  4 22:40 update
$ cat info/allowed-users (4)
refs/heads/master	alice\|cindy
refs/heads/doc-update	bob
refs/tags/v[0-9]*	david

place the developers into the same git group.開発者を同じgitグループに入れます。
and make the shared repository writable by the group.そして共有リポジトリをグループから書き込み可能にします。
use update-hook example by Carl from Documentation/howto/ for branch policy control.ブランチポリシーの制御には、Documentation / howto /のCarlによるupdate-hookの例を使用してください。
alice and cindy can push into master, only bob can push into doc-update. david is the release manager and is the only person who can create and push version tags.アリスとシンディーはマスターにプッシュすることができます、ボブだけがdoc-updateにプッシュすることができます。davidはリリースマネージャで、バージョンタグを作成してプッシュできる唯一の人です。