gitテクニック

git ssh keyの作成と使用
まずgitのuser nameとemailを設定します.

git config --global user.name "xxx" git config --global user.email "[email protected]"

git構成の表示:

git config --list

次にSHHスプーンを生成します.
ssh鍵が既にあるかどうかを確認します:cd~/.ssh鍵がない場合、このフォルダは存在しません.ある場合、バックアップは生存鍵を削除します.

ssh-keygen -t rsa -C "[email protected]"

3つのリターンを押して、パスワードが空です.ここでは鍵は一般的に使用されません.最後に2つのファイルが得られました:id_rsaとid_rsa.pub注意:スプーン生の成果は変更しないでください.もしすでに~/に生成されているならば.sshフォルダを探しに行きます.
git変更項目アドレス

git remote set-url origin git@192.168.6.70:res_dev_group/test.git
git remote -v

ファイルの変更履歴の表示

git log --pretty=oneline     #        git show 356f6def9d3fb7f3b9032ff5aa4b9110d4cca87e #     

git push時報エラーwarning:push.default is unset;
「matching」パラメータはGit 1である.xのデフォルトの動作は、git pushを実行してもブランチが指定されていない場合、pushのローカルブランチをリモートウェアハウスで対応するブランチにすべてブランチすることを意味します.Git 2.xデフォルトはsimpleです.git pushを実行してブランチが指定されていない場合、git pullを使用して取得したコードに現在のブランチのみがpushされます.
ヒントに基づいてgit pushの動作を変更します.

git config --global push.default matching

git pushを再実行して解決します.
git submoduleの使用サブプロジェクトコード
開発の過程で、共通の部分を抽出して別のプロジェクトに提供して使用することを望んでいることがよくありますが、共通コードライブラリのバージョン管理は面倒です.今日はgitのgit submoduleコマンドを何気なく見つけて、前の問題を解決しました.

追加

現在のプロジェクトにsubmoduleを追加します.コマンドは次のとおりです.

git submodule add        

ここで、倉庫アドレスとはサブモジュール倉庫アドレスを指し、パスとはサブモジュールを現在のエンジニアリングの下に配置するパスを指す.注意:パスは/で終わることはできません(変更が無効になります)、既存のプロジェクトの既存のディレクトリではありません(スムーズに閉じることはできません)
コマンドの実行が完了すると、現在のエンジニアリングルートパスの下に「.gitmodules」というファイルが生成され、サブモジュールの情報が記録されます.追加が完了したら、サブモジュールがあるフォルダをプロジェクトに追加します.

削除

submoduleの削除は少し面倒です.まず、「.gitmodules」ファイルから適切な構成情報を削除します.次にgit rm-cachedコマンドを実行して、サブモジュールが存在するファイルをgitから削除します.

ダウンロードされたプロジェクトはsubmodule

付き
git cloneを使用したプロジェクトにsubmoduleが付いている場合、最初はsubmoduleのコンテンツが自動的にダウンロードされません.この場合、次のコマンドを実行するだけです.

git submodule update --init --recursive

サブモジュールのコンテンツをダウンロードしてから、プロジェクトに適切なファイルが欠けないようにします.
git addファイルキャンセル
gitの一般的な使用では、コミットしたくないファイルaddをindexにエラーが検出された後、キャンセルをロールバックしたい場合は、コマンド:git reset HEAD...、同時にgit addが完了するとgitも相応のヒントを与えます.
http://blog.csdn.net/yaoming168/article/details/38777763
gitファイルの削除

ファイルトレースを削除ファイルシステムのファイルfile 1 git rm file 1

を削除

先の削除アクションをコミットし、gitはファイルgit commit

を管理しなくなりました.

削除ファイルトレースファイルシステムのファイルfile 1 git rm--cached file 1

を削除しない

先の削除アクションをコミットし、gitはファイルを管理しません.しかし、ファイルシステムにはfile 1があります.git commit

バージョンのロールバック

バージョンのロールバックは、オンラインシステムで問題が発生した後に古いバージョンを復元するための操作です.

返品されたバージョンgit reset--hard 248 cba 8 e 77231601 d 189 e 3576 dc 096 c 8986 ae 51

すべてのファイルをロールバックします.ロールバックを後悔したらgit pullでいいです.

履歴バージョンの比較

ログの表示git log

ある履歴バージョンのコミット内容git show 4 ebd 4 bbbc 3 ed 321 d 01484 a 4 ed 206 f 18 ce 2 ebde 5 caを表示し、ここでバージョンの詳細な修正コードを見ることができます.

異なるバージョンgit diff c 0 f 28 a 2 ec 490236 caa 13 dec 0 e 8 ea 826583 b 49 b 7 a 2 e 476412 c 34 a 63 b 213 b 735 e 5 a 6 d 90 cd 05 b 014 c 33

http://blog.csdn.net/lxlzhn/article/details/9356473
ブランチの意義と管理

ブランチの作成は、コードのコミット後にプライマリブランチに与える影響を回避し、比較的独立した開発環境を実現します.分岐は重要な意味を持つ.

ブランチを作成して切り替え、コードをコミットしてから他のマシンでブランチコードgit checkout-b new_branch

現在のブランチgit branchを表示

マスターブランチgit checkout master

に切り替え

現在のブランチgit merge new_へのブランチのマージbranch、ブランチをマージする操作はnew_からbranchはmasterブランチにマージされ、現在の環境はmasterブランチにあります.

ブランチgit branch-d newを削除branch

git競合ファイル編集
競合するファイルが競合する場所は、次のようになります.

a123 <<<<<<< HEAD
b789 ======= b45678910 >>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dcc c

衝突マーク<<<<<<<<(7個<)と========================>>>>>>>>>の間の内容は他人の修正です.この場合、他のゴミファイルは発生しません.コードを統合してコード提出プロセスを再開する必要があります.
不調なコードコミットプロセス

git push後にエラーが発生したのは、他の人がコードをコミットしたため、ローカルコードライブラリのバージョンが最新ではない可能性があります.

この場合git pullコードを先に確認し、ファイルの競合がないかどうかを確認する必要があります.

ファイル競合がなければ、コードコミットプロセスadd->commit->pushを再実行する必要があります.

ファイルの競合を解決するには、後述します.

gitスムーズなコミットコードプロセス

修正されたファイルgit statusを表示します.

コードgit diffを慎重にチェックするために

変更ファイルgit add dirname 1/filename 1を追加する.py dirname2/filenam2.py、新しく追加したファイルも直接addでいいです.

変更ログgit commit-m「fixed:アップロードファイルの論理を変更しました」

コードgit pushをコミットします.コミットに失敗した可能性があるのは、ローカルコードライブラリのバージョンが最新ではないためです.

githubのpull requestを理解する
Repo Aという倉庫があります.コードに貢献するには、まずForkというRepoを必要とし、Githubアカウントの下にRepo A 2があります.そしてあなたはこのA 2で仕事をして、Commit、pushなど.その後、元の倉庫Repo Aがあなたの仕事を合併することを望んでいます.GithubでPull Requestを開始することができます.つまり、Repo Aの所有者にA 2から分岐を合併するように要求することを意味します.審査に合格し、正式に合併された場合、プロジェクトAに貢献します.
http://zhidao.baidu.com/question/1669154493305991627.html
いくつかのエラー処理
"pathspec 'branch' did not match any file(s) known to git."エラー

git checkout master
git pull
git checkout new_branch

gitを使用して大きなファイルをコミットすると、このエラーが発生する可能性があります.

error: RPC failed; result=22, HTTP code = 411 fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly Everything up-to-date

これでまずgitの転送バイト制限を変更します

git config http.postBuffer 524288000

その後、転送中に別のエラーが発生する可能性があります.

error: RPC failed; result=22, HTTP code = 413 fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly Everything up-to-date

この2つのエラーは似ています.1つは411で、1つは413です.
次のエラーは鍵を追加すればいいです.

まずkey-keygen生成鍵

生成した鍵をgit内の自分のアカウントの下の対応する位置

にコピーする

git push ssh://192.168.64.250/eccp.git branch