この記事では、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:将会把所有不在远程仓库服务器上的标签全部传送到那里。 ![Git リモート ウェアハウス (Github) のナレッジ ポイントの概要](https://img-blog.csdnimg.cn/498567ecae294ae9af392a975334650f.png)
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 サイトの他の関連記事を参照してください。