大家好，感谢邀请，今天来为大家分享一下克隆其他网站怎么复制源码分享的问题，以及和一键克隆网站源代码的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！
Git基本上是开发人员的标配辅助工具，为了让git发挥更大的作用及大家在使用过中遵守统一的标准，所以编写了这份文档给同事开发培训，现在分享出来，喜欢的朋友记得给个关注。
引言
编写的目的
-通过规范化的流程，使得产品、开发与测试等各个部门更高效的协同工作。
-通过规范化的流程使得产品高效稳定运行。
背景
在多组员，多项目等环境进行协同工作时，如果没有统一规范、统一流程，则会导致额外的工作量，甚至会做无用功。所以要减少版本冲突，减轻不必要的工作，就需要规范化的工作流程。
总则
–统一使用Git作为版本控制的主要工具。
–统一使用GitFlow流程管理控制版本。
提交的准则
1.除了源码相关的东西之外，其他build产生的东西（如：maven的target文件夹，.idea文件夹等），均不能提交进入源码仓库，添加到.gitignore文件中忽略掉。
2.撰写规范的提交说明。一份好的提交说明可以帮助协作者更轻松更有效地配合工作。
3.要严格按照我们定的流程切换到指定分支，开发相应的功能。
分支简述
我们使用的分支流程：
主要分支简述
-天蓝色圆点所在的线为我们源码的主线（master）。
-天蓝色方形指向的节点就是每一个发布版本的标签（tag）。
-紫色圆点所在的线为主要分支线（develop）。
-橙色圆点所在的线为新功能开发分支线（feature）。
-绿色圆点所在的线为新版本发布线（release）。
-红色圆点所在的线为发布版本bug修复线（hotfix）。
主分支说明
代替原来的单个主线（master），我们使用两个分支来记录源码轨迹：
1.原来的master分支用来记录官方发布轨迹；
2.新的develop分支是一个集成分支，用来记录开发新功能的轨迹。
Master与Develop分支
除了master主线和develop主分支线，其他的分支都是临时的分支，有一定的生命周期的，其余的工作流程分支都是围绕这两个分支之间的区别进行的。
其他分支说明
1.新功能分支（FeatureBranches）
每一个新的功能都应该创建一个独立的分支，从develop分支中派生出来。当功能完成后，要合并（merged）回develop分支，合并后它的生命周期就结束。新功能分支不会与master分支有直接的交汇。如图：
注意：对于所有意图和目的，新功能分支会合并到develop分支。但是，这个Gitflow工作流不会在此结束。
2.发布分支（ReleaseBranches）
一旦开发的功能已经满足发布条件（或预定发布日期接近），应该合并所有满足发布条件的新功能分支到develop分支中，然后，开出一个发布分支（Release），开始准备一个发布版本。在这个分支上，不能再添加新的功能，只有bug修复和该版本为导向的任务。一旦到了发布日期，Release就要合并回master发布，并且，打出版本标签。另外，还需要合并回develop分支。
使用一个专门的分支来准备发布版本，使得一个团队能对当前版本进行抛光，而另一个团队继续为下一个版本的功能做准备。它还创造了良好定义的发展阶段（例如，很容易说，“本周我们正在准备4.0版”，而且真实地看到它在库中的结构）。
3.维护分支（MaintenanceBranches）
维护分支也就是线上bug修复分支，使用来快速修复生产环境的紧急问题。
这个分支是唯一一个开放过程中直接从master分支派生来的分支。快速的修复问题后，它应该被合并回master和develop（或者当前发布分支），然后，master分支需要打一个版本标签。
一个专门的错误修复开发线，可以让团队在不等待下一个发布周期，导致中断工作流程情况下解决问题。可以将维护分支当做主要的问题修复分支，与master并行。
命名约定
–主分支名称：master
–主开发分支名称：develop
–标签（tag）名称：v*.RELEASE，其中”*“为版本号，“RELEASE”大写，如：v1.0.0.RELEASE
–新功能开发分支名称：feature-*orfeature/*，其中“*”为新功能简述，如：feature-item-activity-list
–发布分支名称：release-*orrelease/*，其中*为版本号，“release”小写，如：release-1.0.0
–master的bug修复分支名称：hotfix-*orhotfix/*，其中*为bug简述，如：hotfix/item-update-bug
工作流程
下面具体演示如何使用工作流来管理版本发布周期。假设我们已经存在或创建了一个源码中央存储仓库。
工作流的基础
1.创建develop分支
-项目负责人在本地master基础上创建一个develop分支，然后，推送到服务器；
gitbranchdevelop
gitpush-uorigindevelop
-其他开发人员，需要克隆develop中央仓库的源码，创建一个develop的轨迹版本；如果，已经克隆过该项目，则，不需要执行以下第一条命令。
gitclonegit@github.org:search-cloud/demo.git
gitcheckout-bdeveloporigin/develop
develop这个分支将包含项目的完整历史记录，而master将包含缩略版本。
假设开始以下所有的流程之前，都已经创建好develop分支。
新功能开发流程
1.新建feature分支
基于develop分支创建新功能分支：
gitcheckout-bfeature/demodevelop
推送到远程仓库，共享：
gitpush
所有开发此新功能的人员，都在此分支上开发提交代码。
gitstatus
gitadd
gitcommit-m&34;
2.完成新功能开发
当确定新功能开发完成，且联调测试通过，并且新功能负责人已经得到合并feature分支到develop分支的允许；这样才能合并feature分支到develop。
gitpullorigindevelop
gitcheckoutdevelop
gitmergefeature/demo
gitpush
gitbranch-dfeature/demo
第一条命令是确保在合并新功能之前，develop分支是最新的。
注意：
–新功能分支，永远不要直接合并到master分支。
–合并可能会有冲突，应该谨慎处理冲突。
3.在测试环境发布develop分支代码
线上版本发布流程
1.从develop中创建准备发布的release分支
当主测试流程完成，源码已经趋近于稳定状态，应该准备一个发布版本，确立版本号：
gitcheckout-brelease-0.1.0develop
推送到远程仓库共享：
gitpush
这个分支是清理准备发布、整体回归测试、更新文档，和做其他任何系统即将发布的事情。
2.继续修改bug
3.release分支合并到master发布
MergeReleasetoMasterandDevelop
一旦已经满足发布条件（或已经到了预定发布日期），应该把release分支合并到master分支和develop分支中，然后，使用master发布新版本。合并release分支到develop分支是很重要的，要让release上修改的东西能在后续的开发分支中生效。
gitcheckoutmaster
gitmergerelease-0.1.0
gitpush
4.release分支合并到develop
gitcheckoutdevelop
gitmergerelease-0.1.0
gitpush
gitbranch-drelease-0.1.0
5.打标签
Release分支在功能开发分支（develop）和公共发布版（master）中，充当一个缓冲的作用。每当有源码合并到master中的时候，应该在master上打一个标签，以便后续跟踪查阅。
gittag-a0.1.0.RELEASE-m&34;master
gitpush–tags
线上Bug修复流程
当终端用户，反馈系统有bug时，为了处理bug，需要从master中创建出保养分支；等到bug修复完成，需要合并回master：
1.创建hotfix分支
gitcheckout-bhotfix-001
gitpush
4.打标签
gittag-a0.1.1.RELEASE-m&34;master
gitpush–tags
5.合并到develop
gitcheckoutdevelop
gitmergehotfix-#001
gitpush
git协作的一些命令
1.开分支
gitbranch新分支名
例如，在master分支下，新开一个开发分支：
5.合并分支
gitbranchdev
2.切换到新分支
gitcheckout分支名
例如，在master分支下，切换到新开的dev：
gitcheckoutdev
3.开分支和切换分支合并到一个命令
gitcheckout-b新分支名
例如，新开一个开发分支，并立即切换到该分支：
gitcheckout-bdev
4.切换回原分支
gitcheckout原分支名
例如，切换回master
gitcheckoutmaster
注意：当前分支有修改，还未commit的时候，会切换失败，应当先commit，但可以不用push
gitmerge需要合并的分支名
例如，刚刚已经切换回master，现在需要合并dev的内容：
gitmergedev
建议在GitLab(或者其他git系统)上面创建mergerequest的形式来进行分支的合并和代码审核。
6.查看本地分支列表
gitbranch-a
前面带remotes/origin的，是远程分支
7.查看远程分支列表
gitbranch-r
8.向远程提交本地新开的分支
gitpushorigin新分支名
例如，刚刚在master下新开的dev分支：
gitpushorigindev
9.删除远程分支
gitpushorigin:远程分支名
例如，删除刚刚提交到远程的dev分支：
gitpushorigin:dev
10.删除本地分支
gitbranch分支名称-d
例如，在master分支下，删除新开的dev分支：
gitbranchdev-d
注意：如果dev的更改，push到远程，在GitLab(或者其他git系统)上面进行了merge操作，但是本地master没有pull最新的代码，会删除不成功，可以先gitpulloriginmaster，或者强制删除
gitbranchdev-D
11.更新分支列表信息
gitfetch-p
喜欢的朋友给个关注~
END，本文到此结束，如果可以帮助到大家，还望关注本站哦！