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, sincev2.43
tag.tagcurses/
以降、ディレクトリの内容に影響する変更のみを表示します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.mine
masterから新しいブランチをチェックアウトします。 -
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 fromorigin
by default and merges into the current branch.git pull
origin
デフォルトでから取得し、現在のブランチにマージします。 -
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 localremotes/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 tomaster
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
andpu
(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 everythingko/master
has, andnext
should have everythingko/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
andgit 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はログインシェルとして使われているものをリストする必要があります。
-
-
$ 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はリリースマネージャで、バージョンタグを作成してプッシュできる唯一の人です。
-
GIT
Part of the git[1] suite一部のgit [1]スイート
関連記事
- write-tree
- verify-pack
- update-ref
- update-index
- symbolic-ref
- show-ref
- rev-parse
- rev-list
- read-tree
- merge-base
- ls-files
- hash-object
- for-each-ref
- diff-index
- count-objects
- commit-tree
- checkout-index
- check-ignore
- cat-file
- bundle
- archive
- instaweb
- filter-branch
- reflog
- fsck
- gc
- clean
- Workflows
- Tutorial
- Revisions
- gitmodules
- gitignore
- githooks
- Glossary
- gitattributes
- update-server-info
- daemon
- fast-import
- svn
- request-pull
- send-email
- format-patch
- am
- grep
- blame
- bisect
- revert
- rebase
- cherry-pick
- apply
- describe
- shortlog
- show
- submodule
- remote
- push
- pull
- fetch
- worktree
- tag
- stash
- log
- mergetool
- merge
- checkout
- branch
- mv
- rm
- reset
- commit
- diff
- status
- add
- clone
- init
- help
- config
- git
スポンサーリンク