この記事では、Git に関する関連知識をお届けします。主にリモート ウェアハウスに関する関連コンテンツを紹介します。Git には SVN のような中央サーバーがありません。Github の使用について見てみましょう。遠隔倉庫、皆さんのお役に立てれば幸いです。
推奨学習: 「Git 学習チュートリアル 」
Git には SVN のような中央サーバーがありません。
コードを共有したり、Git を通じて他の開発者と共同作業したりする場合、現在使用している Git コマンドはすべてローカルで実行されます。次に、他の開発者が接続できるサーバーにデータを配置する必要があります。
この例では、リモート ウェアハウスとして Github を使用しています。最初に Github の簡潔なチュートリアルをお読みください。
リモート ウェアハウス コマンド
1. 現在のリモート ライブラリを表示します。
2. リモート ウェアハウスを追加します。
git Remote add を実行して、新しいリモート Git リポジトリを指定し、便利な省略形を指定します。 
3. $ git fetch
このコマンドはリモート リポジトリにアクセスし、まだ持っていないデータをすべてプルします。実行が完了すると、そのリモート リポジトリ内のすべてのブランチへの参照が作成され、いつでもマージまたは表示できます。 
オリジンの下にあるすべてのブランチがコピーされます
git fetch コマンドはデータをローカル ウェアハウスにダウンロードするだけであり、現在のデータを自動的にマージしたり変更したりすることはありません。仕事。準備ができたら、ジョブに手動で組み込む必要があります。
git pull コマンドは、リモート ブランチを自動的にフェッチし、現在のブランチにマージします。
デフォルトでは、git clone コマンドは、クローンされたリモート ウェアハウス (またはデフォルト) のマスター ブランチを追跡するようにローカル マスター ブランチを自動的に設定します。別の名前のブランチ) 。 git pull を実行すると、通常、元のクローンサーバーからデータが取得され、現在のブランチへのマージが自動的に試行されます。
3. リモート ウェアハウスへの git Push 
このコマンドは、クローン サーバーに対する書き込み権限があり、これまで誰もプッシュしていない場合にのみ有効になります。他の人と同時にクローンを作成し、その人が最初にアップストリームにプッシュし、次にあなたがアップストリームにプッシュすると、あなたのプッシュは問答無用で拒否されます。プッシュする前に、彼らの作品を取得して自分の作品にマージする必要があります。
4. リモート リポジトリの表示
リモート リポジトリに関する詳細情報を表示したい場合は、git Remote show コマンドを使用できます。 
5. リモート ウェアハウスの名前変更
git Remote rename でリモート ウェアハウスの略語を変更します
6. リモート ウェアハウスの削除
git Remote Remove または git Remote rm
7. タグ: ウェアハウス履歴内のコミットにタグを付けて、その重要性を示すことができます。より代表的なのは、リリース ノードをマークするためにこの関数を使用することです。
1) タグをリストします。
2) git tag -l/list ワイルドカード メソッドを使用してタグをリストします。
3) 軽量タグ (軽量): これは特定のコミットへの単なる参照であり、基本的にコミットのチェックサムをファイルに保存します - 他の情報は保存されません
#
4）附注标签（annotated）：存储在 Git 数据库中的一个完整对象， 它们是可以被校验的，其中包含打标签者的名字、电子邮件地址、日期时间， 此外还有一个标签信息
5）后期打标签：针对历史项目打标签
6）共享标签：git push 命令并不会传送标签到远程仓库服务器上，可以运行 git push origin 。
git push origin --tags：将会把所有不在远程仓库服务器上的标签全部传送到那里。 
7）要删除掉你本地仓库上的标签
git tag -d
注意上述命令并不会从任何远程仓库中移除这个标签，你必须用 git push :refs/tags/ 来更新你的远程仓库：
注意上述命令并不会从任何远程仓库中移除这个标签
必须用第一种变体是 git push :refs/tags/ ：
$ git push origin :refs/tags/v1.4-lw
上面这种操作的含义是，将冒号前面的空值推送到远程标签名，从而高效地删除它。
第二种更直观的删除远程标签的方式是：
$ git push origin --delete
8、git分支管理
注：git branch ，列出当前所有分支，分支前的 * 字符：它代表现在检出的那一个分支
1）git branch testing 创建testing分支
2） git checkout testing 切换分支， 查看当前分支，可以 HEAD 指向即为当前所在的分支
【 git checkout -b 创建并切换分支】
3）舆情测试+testing分支分别提交，head指针会向前移动
两分支的基准都是9623a70fe，分别提交后各自的指针改变
运行 git log --oneline --decorate --graph --all ，它会输出你的提交历史、各个分支的指向以及项目的分支分叉情况。
分叉情况：
分支合并 git merge【舆情分支不做修改，hotfix分支产生新提交情况】–三方合并
hotfix基于舆情测试分支拉取，于hotfix产生提交，查看hotfix分支的提交id为85bb*，切换回舆情分支，执行git merge，发现舆情分支的提交id也推进到hotfix分支产生的85bb*
舆情分支及hotfix分支变化图解：
分支合并 git merge【舆情分支/Testing分支都产生新提交情况】
Test基于舆情测试分支拉取，Test分支/舆情分支分别修改产生提交，在舆情分支合并hotfix分支内容后，切换至Test分支， test分支合并舆情分支时，发现Testing分支直接产生新的提交id41b1*,而舆情分支中的对应的对应的d804和85不会id不会合并过来，此刻新id对应两个父级id，分别是testing的Da4和舆情分支的85b
1）git checkbox Testing
2)git merge 舆情分支
4）git branch -v 查看每个分支的最后一次提交
5）git branch --merged/–no-merged 过滤这个列表中已经合并或尚未合并到当前分支的分支
6)git branch -d
包含了还未合并的工作，尝试使用 git branch -d 命令删除它时会失败,除非用-D
9、远程分支
1） git ls-remote 来显式地获得远程引用的完整列表
通过 git remote show 获得远程分支的更多信息
2)origin/master和master区别
master ： 它代表本地的某个分支名。 origin master 代表着两个概念，前面的 origin 代表远程名，后面的 master 代表远程分支名 origin/master 本地分支，是从远程拉取后，在本地建立的一份拷贝【是用来和远程分支对应的，一般不可见】 举几个例子可能会更加清晰地说明问题： ① 执行 git fetch origin master 时，它的意思是从名为 origin 的远程上拉取名为 master 的分支到本地分支 origin/master 中。既然是拉取代码，当然需要同时指定远程名与分支名，所以分开写。 ②执行 git merge origin/master 时，它的意思是合并名为 origin/master的分支到当前所在分支。既然是分支的合并，当然就与远程名没有直接的关系，所以没有出现远程名。需要指定的是被合并的分支。 ③执行 git push origin master 时， 推送本地的 master 分支到远程origin， ④ 一次性拉取多个分支的代码：git fetch origin master dev1 dev2 ⑤ 一次性合并多个分支的代码：git merge origin/master 分支1 分支2 分支3
2）如果远程仓库有人提交内容，那么远程仓库就会向前移动，而本地origin/master如果不拉取，将还保持不动，如果希望本地同远程保持一致，可以通过git fetch拉取远程仓库数据，
git fetch
3) git push origin 分支名
推送本地的 舆情测试 分支，将其作为远程仓库的 舆情测试 分支
如果并不想让远程仓库 上的分支叫做 舆情测试 ，可以运行 git push origin 舆情测试 :test0421 来将本地的 舆情测试 分支推送到远程仓库上的 test0421 分支。
4)checkout 的操作
通过 git checkout test0421 会把分支切换到test0421分支上
这个操作会处于‘detached Head’ 状态，在这种状态下不会修改origin/test0421上的数据，可以修改并提交做一些实验性的操作，但是切换回test0421分支后，再次从test0421切换回origin/test0421时，之前的改变不会同步，因为origin/test0421 是用户只读的
5）git push origin --delete 分支名 删除远程仓库分支【本地仓库还有数据】
6）rebase变基：使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。
首先找到这两个分支（即当前分支 Test0421、变基操作的目标基底分支 Test0420） 的最近共同祖先 85bb，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件， 然后将当前分支指向目标基底 3467, 最后以此将之前另存为临时文件的修改依序应用
Test0420 使用git merge 合并Test0421内容，结果两个分支完全一致，可以发现提交记录没有出现分拆，而是保持在一条直线上【可以比较前面get merge环节中结果出现分叉】
rebase时一系列提交按照原有次序依次应用，只是当前分支的提交id值改变
merge时多次提交合并成一次，生成新的提交id
总结：无论是通过变基，还是通过三方合并，整合的最终结果所指向的快照始终是一样的，只不过提交历史不同罢了。 变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起。
推荐学习：《Git学习教程》
以上がGit リモート ウェアハウス (Github) のナレッジ ポイントの概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
