さて、 PJ Hyettによるこの投稿 を見た後、私は最後までスキップして Git で行くことにしました。
だから私が必要としているのはGitの初心者向けの実用的なガイドです。 「初心者」とは、自分のコンパイラの扱い方を知っていて、 Makefile が何であるかをある程度理解し、それをあまりよく理解せずにソース管理に触れた人として定義されます。
この人として定義されている「実用的な」とは、Gitがバックグラウンドで何をしているのかについて詳細に説明することを望まず、配布されていることを気にすること(または知ることすらない)です。あなたの答えは可能性をほのめかしているかもしれませんが、バックアップされ安全な「サーバー」上に「メイン」リポジトリを保ち、単に「クライアント」リソースとして彼らのローカルリポジトリを扱いたい初心者を目指してみてください。
そう:
私は時々エントリを調べてそれらを整頓して、それらが一貫した外観/感触を持ちそしてそれがリストをスキャンするのが簡単である - 簡単な "ヘッダーに従うこと自由に感じなさい - 簡単な説明 - 命令のリスト - 得て「追加情報」テンプレート。上記の箇条書きリストのエントリにもリンクしますので、後で簡単に見つけることができます。
Gitリポジトリは、特別な.git
ディレクトリを含む単なるディレクトリです。
これは、「リポジトリ」がcheckout
の「作業コピー」ディレクトリにあるリモートサーバーでホストされる「集中型」バージョン管理システム(Subversionなど)とは異なります。 gitでは、作業コピーはリポジトリです。
単に、追跡したいファイルを含むディレクトリでgit init
を実行してください。
例えば、
cd ~/code/project001/
git init
これにより、現在のディレクトリに.git
(非表示)フォルダーが作成されます。
新しいプロジェクトを作成するには、追加の引数(作成するディレクトリの名前)を指定してgit init
を実行します。
git init project002
(This is equivalent to: mkdir project002 && cd project002 && git init)
現在の現在のパスがgitリポジトリ内にあるかどうかを確認するには、単にgit status
を実行します-リポジトリでない場合、「fatal:Not a git repository」と報告されます
.git
ディレクトリを一覧表示し、次のようなファイル/ディレクトリが含まれていることを確認することもできます。
$ ls .git
HEAD config hooks/ objects/
branches/ description info/ refs/
何らかの理由でリポジトリを「de-git」したい場合(gitを使用してそのプロジェクトを追跡したくない場合)。リポジトリのベースレベルで.git
ディレクトリを削除するだけです。
cd ~/code/project001/
rm -rf .git/
注意:これは、all改訂履歴を破棄します、allタグ、everythinggitが完了しました。 「現在の」ファイル(現在表示されているファイル)は変更されませんが、以前の変更、削除されたファイルなどは回復できません。
Gitに同梱 - コマンドラインからgit gui
を実行すると、Windowsの msysgit インストーラによってスタートメニューに追加されます。
Git GUIは、あなたがgitでする必要があることの大部分をすることができます。ステージの変更、gitとリポジトリの設定、変更のプッシュ、ブランチの作成/チェックアウト/削除、マージ、その他さまざまなことが含まれます。
私のお気に入りの機能の1つは、右クリックメニューの "stage line"と "stage hunk"ショートカットです。これを使うと、ファイルの特定の部分を確定できます。あなたはgit add -i
を通して同じことを達成することができます、しかし私はそれが使いやすいと思います。
最も美しいアプリケーションではありませんが、ほとんどすべてのプラットフォームで動作します(Tcl/Tkに基づいています)。
Gitにも含まれています。これはgit履歴ビューアであり、リポジトリの履歴(ブランチを含むもの、作成されたもの、マージされたもの)を視覚化することができます。コミットを表示および検索できます。
Git-guiとうまくいっています。
Mac OS Xアプリケーション主にgit log
と同等ですが、 github と一部統合されています( "ネットワークビュー"のように)。
見た目も美しく、Mac OS Xにも適しています。リポジトリを検索できます。 Gitnubの最大の批判は、歴史を直線的に表示することです(一度に1つのブランチ) - ブランチ化とマージを視覚化しません。これは計画的な改善ですが、gitにとって重要なことです。
ダウンロードリンク、変更履歴、スクリーンショットgitリポジトリ
「OS X用gitkクローン」になる予定です。
それは非線形分岐履歴の視覚化、コミットの実行、コミットの表示と検索、そして任意のリビジョンの任意のファイルを「Quicklook」(ファイルリストビューでスペースを押す)、任意のファイルのエクスポートが可能です。 (ドラッグアンドドロップで).
これはgit-gui
/gitk
よりもはるかにOS Xに統合されており、非常に大きなリポジトリでも高速で安定しています。
オリジナルのgitリポジトリ pieter は最近更新されていません(執筆時点で1年以上)。より積極的に保守されたブランチが brotherbard/gitx で利用可能です - それは "サイドバー、フェッチ、プル、プッシュ、リモート追加、マージ、チェリーピック、リベース、クローン、クローン"を追加します
ダウンロード | スクリーンショット | gitリポジトリ | brotherbard fork | laullon fork
ホームページから:
SmartGitは、分散バージョン管理システムGitのフロントエンドで、Windows、Mac OS X、およびLinux上で動作します。 SmartGitは、コマンドラインクライアントよりもグラフィカルユーザーインターフェイスを好む開発者を対象としています。Gitは、現在最も強力なDVCSです。
あなたは 彼らのウェブサイト からそれをダウンロードすることができます。
Windowsユーザ向けのTortoiseSVN Gitバージョン。
TortoiseSVNからTortoiseGitへの移植最新リリース1.2.1.0このリリースではコミット、ログの表示、差分の2つのバージョンの作成、ブランチとタグの作成、パッチの作成などの通常の作業を完了できます。詳細は ReleaseNotes を参照してください。このプロジェクトへようこそ。
QGitはQt/C++上に構築されたgit GUIビューアです。
Qgitを使用すると、さまざまな開発ブランチをグラフィカルに追跡しながら、リビジョン履歴の閲覧、パッチの内容の表示、変更されたファイルの表示ができます。
gitgはgtk +/GNOMEをターゲットにしたgitリポジトリビューアです。その主な目的の1つは、複数のデスクトップにわたるgitフロントエンドに対して、より統一されたユーザーエクスペリエンスを提供することです。これはクロスプラットフォームのアプリケーションを書くのではなく、他のオペレーティングシステム(GitX for OS Xのような)のための同様のクライアントとの密接な共同作業によるものです。
GitboxはGitバージョン管理システム用のMac OS Xグラフィカルインタフェースです。単一のウィンドウに、ブランチ、履歴、そして作業ディレクトリのステータスが表示されます。
日常的な操作は簡単です。チェックボックスを使用してステージングとステージングの変更を行います。ワンクリックでコミット、プル、マージ、プッシュ。 FileMerge.appとの差分を表示するには、変更をダブルクリックします。
GityのWebサイトには多くの情報はありませんが、そこにあるスクリーンショットから、機能豊富なオープンソースのOS X git guiのように見えます。
Meldは視覚的な差分およびマージツールです。 2つか3つのファイルを比較して、その場で編集することができます(差分は動的に更新されます)。 2つまたは3つのフォルダを比較してファイル比較を起動できます。 CVS、Subversion、Bazaar-ng、Mercurialなどの一般的なバージョン管理システムから作業コピーをブラウズおよび表示することができます[ およびGit ]。
Steve DekorteによるOSX用のGit GUI。
一目で、どのリモートブランチがpullに変更され、ローカルリポジトリがpushに変更されたかを確認してください。追加、コミット、プッシュ、プル、タグ付け、リセットといった操作手順がサポートされているほか、ローカルの変更や追加をハイライト表示するプロジェクトの階層の視覚的な差分や視覚的な参照もサポートされています。
1リポジトリ無料、25ドル以上。
Gitを使いやすくすることに焦点を当てています。ネイティブのCocoa(Mac風)UI、高速リポジトリブラウジング、クローン作成、プッシュ/プル、分岐/マージ、ビジュアル差分、リモートブランチ、ターミナルへの簡単なアクセスなどを備えています。
最も一般的に使用されるGitアクションを直感的で実行しやすいものにすることで、Sprout(以前のGitMac)はGitをユーザーフレンドリーにします。ほとんどのGitワークフローと互換性があるSproutは、デザイナーや開発者、チームのコラボレーション、そして上級ユーザーにも初心者ユーザーにも最適です。
Mac OSX用の機能豊富なGit GUI。 30日間の無料トライアル、シングルユーザーライセンスで59ドル。
EGitはGitバージョン管理システム用のEclipse Teamプロバイダーです。 Gitは分散SCMです。つまり、すべての開発者はコードのすべての改訂に関するすべての履歴の完全なコピーを持っているので、履歴に対するクエリは非常に高速で用途が広いのです。
EGitプロジェクトは、GitのJGit Java実装の上にEclipseツールを実装しています。
Windows用オープンソース - Gitで作業するのに必要なものすべてを使いやすい単一のパッケージにインストールします。
Git Extensionsは、Windows上でGitを扱うのをより直感的にするためのツールキットです。シェル拡張はWindowsエクスプローラに統合され、ファイルとディレクトリのコンテキストメニューを表示します。 Visual Studioのgitを使うためのVisual Studioプラグインもあります。
git guiについて詳しく説明してくれた dbr に感謝します。
SourceTreeはGit、Mercurial、SVN向けの free Macクライアントです。 BitBucketの背後にいるAtlassianによって構築されたこのツールは、すべてのプロジェクトで使用するための単一のツールを習得することを可能にするVCシステムと同等に機能するようです。機能満載、そして無料。
初心者と上級者の両方のためのエキスパートレディ&機能満載:
発信チェンジセットと着信チェンジセットを確認します。枝の間でチェリーピック。パッチの取り扱い、リベース、隠し場所/棚など。
さて、あなたが他のリソースへの「単純な」リンクではないとあなたが尋ねたという事実にもかかわらず、本当に良いコミュニティ成長(そして成長)リソースが既に存在するときそれはかなり愚かです: Git Community Book 。真剣に、質問のこの20以上の質問は、簡潔で一貫性のあるもの以外のものになるでしょう。 Git Community BookはHTMLとPDFの両方で入手でき、明確で、よくフォーマットされ、査読された答えで、またすぐにあなたの問題に飛びつくことができるフォーマットであなたの質問の多くに答えます。
残念ながら、私の投稿が本当にあなたを混乱させるのであれば、私はそれを削除します。そう言うだけです。
追跡したくないファイルをgitに無視させる機能は非常に便利です。
ファイルまたはファイルのセットを無視するには、パターンを指定します。 gitのパターン構文はかなり単純ですが強力です。それは私が以下に言及するであろう異なるファイルの3つすべてに適用可能です。
gitignore(5) manページからの優れた例:
$ git status
[...]
# Untracked files:
[...]
# Documentation/foo.html
# Documentation/gitignore.html
# file.o
# lib.a
# src/internal.o
[...]
$ cat .git/info/exclude
# ignore objects and archives, anywhere in the tree.
*.[oa]
$ cat Documentation/.gitignore
# ignore generated html files,
*.html
# except foo.html which is maintained by hand
!foo.html
$ git status
[...]
# Untracked files:
[...]
# Documentation/foo.html
[...]
一般的に、追跡されていないファイルを無視する方法は3つあります。
1)リポジトリのすべてのユーザーを無視します。
作業コピーのルートに .gitignore という名前のファイルを追加します。
.gitignore を編集して、無視するべきではないファイルを選択します。
git add .gitignore
完了したらコミットします。
2)あなたのリポジトリのコピーだけを無視してください:
作業コピーに $ GIT_DIR/info/exclude というファイルを好みのパターンで追加/編集します。
例:私の作業コピーは〜/ src/project1なので 〜//src/project1/.git/info/exclude を編集します。
これで終わりです!
3)あなたのシステム上のすべての状況で無視してください:
あなたのシステムのためのグローバル無視パターンはあなたが今までに欲しいものという名前のファイルに入れることができます。
私の個人的な名前は 〜/ .gitglobalignore です。
次の行を使って 〜/ .gitconfig ファイルを編集することで、gitにこのファイルを知らせることができます。
core.excludesfile = ~/.gitglobalignore
これで終わりです!
私は gitignore manページがより多くの情報のための最良のリソースであると思います。
特定のファイルセットに対して特定のリビジョンセットをどのように「マーク」「タグ」または「リリース」して、後でいつでもそのファイルをプルできるようにするにはどうすればよいですか。
git tag
コマンドを使用します。
現在のリビジョンを単に「タグ付け」するには、単に実行します。
git tag -a thetagname
git tag -a 0.1
git tag -a 2.6.1-rc1 -m 'Released on 01/02/03'
現在のタグを一覧表示するには、引数なしでgit tag
を実行するか、-l
(小文字のL)を実行します。
$ git tag -a thetagname # and enter a message, or use -m 'My tag annotation'
$ git tag -l
thetagname
タグを削除するには、-d
フラグを使います。
$ git tag -d thetagname
Deleted tag 'thetagname'
$ git tag
[no output]
特定の(前の)コミットをタグ付けするには、単に...
git tag [tag name] [revision SHA1 hash]
例えば:
git tag 1.1.1 81b15a68c6c3e71f72e766931df4e6499990385b
注:デフォルトでは、gitは "軽量"タグ(基本的に特定のリビジョンへの参照)を作成します。 「正しい」方法は-a
フラグを使うことです。これにより、エディタが起動してタグメッセージを要求します(コミットメッセージを要求するのと同じです。コマンドラインでタグメッセージを提供するために-m
フラグを使用することもできます)。注釈付きタグを使用すると、独自のID、日付、タグ付け者(作成者)、およびオプションで(-s
タグを使用して)GPG署名を持つオブジェクトが作成されます。 これについてのさらなる情報は、 この記事を参照してください
git tag mytagwithmsg -a -m 'This is a tag, with message'
また、注釈付きのタグを一覧表示するには、-n1
フラグを使用して各タグメッセージの1行を表示します(-n245
は各注釈の最初の245行を表示する、など)。
$ git tag -l -n1
mytagwithmsg This is a tag, with message
詳細については、 git-tag(1)のマニュアルページを参照してください
GITを使用したワークフローの例.
Gitは非常に柔軟性があり、どのワークフローにも適応しますが、特定のワークフローを強制しないと、gitを使用して線形の「バックアップ」ワークフローを超えて何ができるかを理解しにくくなります。 。
この ブログ投稿 はgitを使って設定するのが本当に簡単な、とてもシンプルだが効果的なワークフローをうまく説明しています。
ブログ投稿からの引用:Origin/masterは、HEADのソースコードが常にプロダクションの準備ができている状態を反映しているメインブランチであると考えています。
このワークフローは、このワークフローを実装するプロジェクトを作成するのに十分なほど普及しています。 git-flow
単純なワークフローの良い例です。ここでは、すべての変更を開発中で行い、コードが本番状態にあるときにのみマスターにプッシュします。
それでは、新機能の開発、またはモジュールのリファクタリングの作業を行いたいとしましょう。新しいブランチを作成することもできます。これを「機能」ブランチと呼ぶこともできますが、これにはしばらく時間がかかり、コードが壊れる可能性があります。あなたの機能が「十分に安定」していて、それを「本番」に「近づけ」たい場合は、機能ブランチを開発にマージします。マージ後にすべてのバグが整理され、コードがすべてのテストに合格したら、変更をマスターにプッシュします。
このすべてのプロセスの間に、あなたはひどいセキュリティバグを見つけます、それはすぐに直さなければなりません。あなたはhotfixesと呼ばれるブランチを持つことができ、それは通常の "Develop"ブランチよりも早くプロダクションにプッシュされる変更を行います。
ここでは、この機能/修正プログラム/開発/制作のワークフローがどのようになるかを説明しています(ブログ投稿でよく説明されています。繰り返しますが、ブログ投稿では、プロセス全体について詳しく説明します。
PJ Hyettの投稿は、もうできていません。
Gitは難しいじゃない
2008年11月23日
SubversionよりもGitを使用する理由をユーザーに伝えると、「GitはSubversionよりもSubversionの方が優れていますが、それよりもはるかに優れています」とあります。
「もっとたくさん」はGitを本当に輝かせるものの集まりで構成されていますが、Subversionのような他のSCMから来たものにとってはかなり圧倒的なものになる可能性があります。
そうは言っても、移行中にSubversionを使用するのと同じようにGitを使用することを妨げるものは何もありません。
必要なソフトウェアをインストールし、どこかにリモートリポジトリがあると仮定すると、これがコードを入手してSubversionで変更をプッシュする方法です。
$ svn checkout svn://foo.googlecode.com/svn/trunk foo
# make your changes
$ svn commit -m "my first commit"
そしてGitでどのようにしますか。
$ git clone [email protected]:pjhyett/foo.git
# make your changes
$ git commit -a -m "my first commit"
$ git Push
Gitでそれを実現するためのもう1つのコマンド。この追加のコマンドには大きな意味がありますが、この記事の目的のためには、これが1つの追加のコマンドです。
なるほど、それほど難しいことではありません。
更新: SubversionでGitと比較してローカルコピーを更新するのは、それぞれ
svn update
とgit pull
です。どちらの場合も1つのコマンドだけです。
インストール msysgit
いくつかのダウンロードがあります:
これはCygwin bashシェルもインストールするので、git
をより良いシェル(cmd.exeよりも)で使用でき、git-gui(git gui
コマンドまたはStart > All Programs > Git
メニューからアクセス可能)も含まれます。
git-osx-installer を使用するか、ソースからインストールすることもできます。
ネイティブパッケージマネージャを使ってgit
をインストールします。たとえば、Debian(またはUbuntu)では、次のようになります。
apt-get install git-core
またはMac OS Xでは、 MacPorts を介して。
Sudo port install git-core+bash_completion+doc
…あるいはフィンク:
fink install git
…または 自作 :
brew install git
FedoraなどのRed Hatベースのディストリビューションでは、
yum install git
Cygwinでは、Gitパッケージは "devel"セクションにあります。
Mac OS Xでは、Developer Toolsがインストールされていれば、Gitをソースから非常に簡単にコンパイルできます。 http://git-scm.com/ からGitの最新バージョンを.tar.bz
または.tar.gz
としてダウンロードし、解凍します(Finderをダブルクリック)。
Linux/BSD/etcの場合それはほとんど同じであるはずです。たとえば、Debian(およびUbuntu)では、apt
を介してbuild-essential
パッケージをインストールする必要があります。
次にターミナルで、ファイルを展開した場所へのcd
(cd ~/Downloads/git*/
の実行はうまくいくはずです)、そして次に実行します。
./configure && make && Sudo make install
これはGitをデフォルトの場所にインストールします(/usr/local
- git
は/usr/local/bin/git
に入ります)
パスワードを入力するように促されます(Sudo
の場合)。これは/usr/local/
ディレクトリに書き込むことができるため、 "root"ユーザーのみがアクセスできるため、Sudoが必要です。
別の場所にインストールする場合は(Gitのファイルが他のツールと混在しないように)、configureコマンドで--prefix
を使用します。
./configure --prefix=/usr/local/gitpath
make
Sudo make install
これにより、git
バイナリが/usr/local/bin/gitpath/bin/git
にインストールされます。したがって、毎回入力する必要はありません。次の行を$PATH
に追加して、~/.profile
に追加する必要があります。
export PATH="${PATH}:/usr/local/bin/gitpath/bin/"
Sudoにアクセスできない場合は、--prefix=/Users/myusername/bin
を使用してホームディレクトリにインストールできます。 ~/bin/
を$PATH
に追加することを忘れないでください
スクリプト x-git-update-to-latest-version は、これらの多くを自動化します。
このスクリプトは私のgitリポジトリのローカルクローン(
~/work/track/git
の場所)を更新し、それから設定、インストール(/usr/local/git
-git describe
)そして/usr/local/git
シンボリックリンクを更新します。こうすることで、
PATH
に/usr/local/git/bin
を含めることができ、常に最新バージョンを使用します。このスクリプトの最新版もmanページをインストールします。
/usr/local/git/share/man
ディレクトリを含めるには、MANPATH
を調整する必要があります。
あなたが引っ張って、それをあなたのコードにマージして、あなたがそれを好きではないと決心したとしましょう。 git-logまたはtigを使用して、戻りたい場所(おそらくpull/mergeの前の最後のコミット)のハッシュを見つけて、そのハッシュをコピーしてください。
# Revert to a previous commit by hash:
git-reset --hard <hash>
ハッシュの代わりに、前のコミットのショートカットとして HEAD ^ を使用できます。
# Revert to previous commit:
git-reset --hard HEAD^
normal リポジトリを設定する方法は here - で説明されています - しかし、どのようにして誰もがプル/プッシュできるチームリポジトリを設定するのですか?
たとえば、あなたのチームがすでに使用可能な共有グループメンバーシップを持っているとします。
mkdir /your/share/folder/project.git
cd /your/share/folder/project.git
newgrp yourteamgroup # if necessary
git init --bare --shared
このリポジトリを使い始めるために最も簡単なことはあなたが既に使っているローカルリポジトリから始めることです:
cd your/local/workspace/project
git remote add Origin /your/share/folder/project.git
git Push Origin master
他の人がこれを複製して作業を開始できます。
cd your/local/workspace
git clone /your/share/folder/project.git
ターゲットサーバーにユーザーアカウントを設定します。パスワードのないアカウント、パスワードのあるアカウント、またはauthorized_keys
を使用するかどうかは、実際に必要なセキュリティレベルによって異なります。さらに詳しい情報は SSH経由のGitの設定 を見てください。
すべての開発者がこの共有リポジトリへのアクセスに同じアカウントを使用する場合は、上記のように--shared
オプションを使用する必要はありません。
上記と同じ方法でリポジトリを起動した後、次のように最初のPushを行います。
cd your/local/workspace/project
git remote add Origin user@server:/path/to/project.git
git Push Origin master
上記との類似性は?さらに起こるかもしれない唯一の事はアカウントにパスワードがあるならSSHがパスワードを尋ねることです。パスワードなしのアカウントでこのプロンプトを受け取った場合、SSHサーバーはおそらくPermitEmptyPasswords
を無効にしています。
クローン作成は次のようになりました。
cd your/local/workspace
git clone user@server:/path/to/project.git
git status
はあなたの友人です、頻繁に使用してください。次のような質問に答えるのに適しています。
svn status
とは異なり、git status
は大規模プロジェクトでもすぐに実行されます。何が起こっているのかという私の精神的モデルが正確であることを確かめるために、それを頻繁に使うことをgitが学んでいる間、私はそれが安心できることをしばしば見つけました。現在は、前回のコミット以降に変更したことを思い出させるために使用しています。
明らかに、あなたの.gitignoreが正気に設定されているなら、それははるかに便利です。
ファイルを編集したら、変更をgitにコミットする必要があります。このコマンドを実行すると、コミットメッセージを要求します - これは、あなたが何を変更したのかを全員に伝える単なるテキストです。
$ git commit source/main.c
ディレクトリ./source/にあるファイルmain.cをコミットします。
$ git commit -a # the -a flag pulls in all modified files
すべての変更されたファイルをコミットします(新しいファイルはそうではありません、それらはgit-addでインデックスに追加される必要があります)。特定のファイルだけをコミットしたい場合は、まずそれらをgit-addでステージングしてから-aフラグなしでコミットする必要があります。
コミットしてもローカルリポジトリは変更されますが、リモートリポジトリは変更されません。コミットをリモートリポジトリに送信したい場合は、プッシュを実行する必要があります。
$ git Push <remote> <branch> # Push new commits to the <branch> on the <remote> repository
CVSやSVNから来た人にとっては、セントラルリポジトリへのコミットに2つのステップが必要になるため、これは変更になります。
Gitリポジトリのデフォルトのブランチはmaster
です。
新しいブランチを作るには
git branch <branch-name>
現在のリポジトリタイプのすべてのブランチのリストを表示する
git branch
他のブランチに切り替えたい場合は、
git checkout <branch-name>
新しいブランチを作成してワンステップで切り替えるには
git checkout -b <branch-name>
ブランチを削除するには
git branch -d <branch-name>
現在のブランチからの変更でブランチを作成するには、
git stash
git stash branch <branch-name>
$ git pull <remote> <branch> # fetches the code and merges it into
# your working directory
$ git fetch <remote> <branch> # fetches the code but does not merge
# it into your working directory
$ git pull --tag <remote> <branch> # same as above but fetch tags as well
$ git fetch --tag <remote> <branch> # you get the idea
これで、リモートリポジトリから最新のコードを入手することができます。
Pro Git フリーブックは、特に初心者には間違いなく私のお気に入りです。
Git Magic はあなたが必要とするすべてのものです。保証またはあなたの返金!
私は Git Internals もとても便利であることがわかりました。これはScott Chacon(Pro Gitの作者、そしてGit Community Bookのメンテナ)によって書かれました。 Git Internalsについて私が気に入っているのは 最初に概念に、次にコマンドに焦点を当てています です。
ブランチをマージしたい場合(例えばmaster
からrelease
)、現在のブランチがマージ先のターゲットブランチであることを確認してください(現在のブランチを見るにはgit branch
またはgit status
を使用してください)。
それから使う
git merge master
(master
は現在のブランチとマージしたいブランチの名前です)。
競合がある場合は、次のものを使用できます。
git diff
保留中の競合を確認するには、解決する必要があります。
git log -- filename
自分のローカルリポジトリからクローンを作成したリモートリポジトリがあり、そのリモートリポジトリに「some_branch」という名前のブランチがあると仮定して、ローカルに追跡する方法は次のとおりです。
# list remote branches
git branch -r
# start tracking one remote branch
git branch --track some_branch Origin/some_branch
# change to the branch locally
git checkout some_branch
# make changes and commit them locally
....
# Push your changes to the remote repository:
git Push
Gitがどのように機能するかを理解するための本当に良い論文は The Git Parable です。とてもオススメです!
比較コマンドはgit diff
です。
ファイルの2つのリビジョンを比較するには:
$ git diff <commit1> <commit2> <file_name>
これは、commit1とcommit2を比較したものです。順番を変更した場合、ファイルは逆方向に拡散されます。
現在のステージングファイルをリポジトリと比較するには
$ git diff --staged <file_name>
現在のステージングされていないファイルをリポジトリと比較するには
$ git diff <file_name>
apt-get install tig
Gitリポジトリの中で 'tig'と入力すると、対話的なログを見ることができます。さらに詳しい情報を見るには、任意のログで 'enter'を押してください。 時間 基本的な機能を一覧表示しています。
"Tig"は逆に "Git"です。
ブランチの名前の前に:
を使用してリモートでプッシュを実行します
git Push Origin :mybranchname
Origin
はリモートの名前、mybranchname
は削除しようとしているブランチの名前です。
リモートリポジトリを単一のリモートリポジトリから複製したとします。
# create a new branch locally
git branch name_of_branch
git checkout name_of_branch
# edit/add/remove files
# ...
# Commit your changes locally
git add fileName
git commit -m Message
# Push changes and new branch to remote repository:
git Push Origin name_of_branch:name_of_branch
公式の Gitチュートリアル から始めました。私はそれが初心者には十分実用的だと思います(あなたの定義によれば、私はまだ初心者でした!私はmakefileをほとんど把握していません。私はApache Subversionなどで少し遊んだだけです)。
最初に空のディレクトリに行き、 "git init"を使ってそれをリポジトリにしてから、リモートレポジトリをあなた自身のものにクローンしてください。
git clone [email protected]:/dir/to/repo
あなたが最初にクローンを作成する場所はどこでも "git pull"がデフォルトでプルする場所です。
プッシュアンドプル変更
簡単に言うと、git Push
とgit pull
を実行するだけです。変更はマージされ、衝突がある場合はgitがそれを知らせてくれるので手動で解決できます。
リモートリポジトリに初めてプッシュするときは、git Push Origin master
を実行する必要があります(masterがマスターブランチです)。それ以降はgit Push
を実行するだけです。
タグをgit Push --tags
でプッシュします。
WRT良いGUI /フロントエンド、あなたはまた qgit をチェックアウトしたいかもしれません。これはGit用のクロスプラットフォーム(Linux/Win32)リポジトリビューアであり、最も一般的なGit操作のためのハイレベルフロントエンドとしても使えます。ユーザーがカスタマイズされたアクションを提供できるように、事実はいわゆる「カスタムアクション」によって容易に強化することができます。
本から取られた説明を再参照Gitへの実用的なガイド - Travis Swicegood
第3章
16。リベースによる履歴の書き換え
コミットのリベースは、Gitの1つの概念であり、従来のバージョン管理の世界には対応するものがありません。 git rebaseを使うと、さまざまな方法でリポジトリの履歴を書き換えることができます。これはGitで最も強力なコマンドの1つであり、最も危険なコマンドの1つです。
rebase
は一連のコミット(通常はブランチ)を受け取り、それらを別のコミット(通常は別のブランチの最後のコミット)の先頭で再生します。親コミットが変更され、すべてのコミットIDが再計算されます。 IDが一致しないので、これはあなたのコードを持っている他の開発者にとって問題を引き起こす可能性があります。Git rebaseには簡単な経験則があります。ローカルのコミットで必要なだけ使用してください。いったん他の開発者と変更を共有したら、頭痛は一般的に問題にはなりません。
リソース :絶対にチェックアウトしてください Scott ChaconのGitcasts 、特にRailsconfの話。
Github は素晴らしいし、またいくつかの 役に立つガイドもある 。
Tim's answer / Stack Overflowの投稿 WindowsでのMsysgitを使ったGit Serverのセットアップ で紹介されているリンクを真剣に追加します。
msysgit を使ってWindows上でGitを設定する方法を完璧に教えてくれました。これは非常に詳細な記事です。
この記事 私を始めてもらうのにとても役に立つことがわかりました。私はまだ本や他のリソースを読む必要がありますが、タイトルが「gitを概念的に理解する」というタイトルのようにこの記事は役に立ちました。 RubyLearning で提供されているGit&GitHubコースを受講することもお勧めします。
私がこのリストに含めるべきと私が思うにもう1つの項目。おそらく初心者にはとても便利です。
コミットをした後に、恐らくリベースのような何か怖いことをしたが、今や何か、あるいはすべてが失われているように見えるかもしれません。 git rebase --abort
は非常に役に立ちますが、対話型のリベースで編集を失敗させたことがあると思うことがあります。リベースが終了したら、今度は古いものを取り戻したいと思いますfilter-branch
...)
重要な原則の1つは、コミットしたものが実際には削除されないことです。 ( "何、絶対に?" "いいえ、絶対に!" "What、 決して ?" "まあ、これまでにほとんど実行していません!")git gc
を実行していない場合、 まだそこにあります 。以前の作業を見つけるには多少の手間がかかるかもしれませんが、git commit
sを以前に成功させた場合、たとえば、明らかに難破したリベースエラーによる一連のコミットでさえ、少なくとも1か月はまだ残っています。 (技術的には、「reflogs」が期限切れになるまで)。
各ブランチの名前は「コミットID」にラベルを付ける、またはそれを指すことに注意してください。これらは7cc5272
のようなおかしな数字です。ブランチに新しいコミットを追加するなど、あなたがすることの多くは、ブランチ名が新しい、異なるコミットIDを指すようにします。各コミットIDには、以前のいくつかのコミットIDを指すリンクがあり、これが実際にコミットでいっぱいの「ブランチ」を構成しています。
リベースのエントリでは「履歴の書き換え」とgit filter-branch
のようなコマンドも「履歴の書き換え」について説明していますが、以前の履歴を破棄するのではなく、新しい履歴を追加することで行います。新しい履歴が作成されると、gitは が historyが変更されたように見えるように「ラベルを移動」します。あなたがあなたのfix-nasty-bug
ブランチにいて、git rebase
をして、物事を破壊することをどうにかしているならば、ラベルfix-nasty-bug
は今、残骸を参照します、しかし、元のバージョンはまだそこにあります。特にRebaseは、一時的な(移動しない、分岐しない)ラベルをORIG_HEAD
のスペルで作成して見つけることができます。 filter-branch
コマンドは元の名前もすべて保存します。場合によっては、明確な名前がない場合もありますが、コミットは常に見つかります。必要ならば、自分自身を "git guru"として見つけ、それがあなたがしたことが残骸の原因となったことを説明してください。
(コマンドgit reflog show
は、コミットIDの検索にも役立ちます。)
自分の過去の作品の一部または全部だと思うものが見つかった場合は、次のことを試してください。
git log <commit-ID> # ORIG_HEAD after a bad rebase, for instance
git show <commit-ID> # or some long SHA1 value you can still see in a window
それが正しいか役に立つのなら、それに名前を付けてください:
git branch recover-my-stuff ORIG_HEAD
そしてまた戻ってきた!実際、今ではあなたの悪いリベースとあなたの元の仕事の両方があなたのgitレポジトリに "永遠"に(あるいは少なくともブランチ名 と を削除するまでは数ヶ月経ってからゴミになるまで) -集めました)。回復したコミットには、好きなだけ多くの名前を付けることができます。 (ブランチ名はgit branch
の出力が散らかっていることを除けば事実上自由であり、もちろんコミットもガベージコレクトされるのを防ぎます。もし望むなら、特定のコミットIDにタグをつけることもできます。)
競合とのマージに関する非常に良い投稿 - GitGuys:競合とのマージ - 競合と解決
このブログは実に素晴らしいものです - 例証的でわかりやすい例で理解しやすいものです。確かにチェックする価値があります。