git实操

一、解决git冲突

1.冲突出现的原因
 step1 员工B先修改了文件，把A修改成了A，B；
 step2 员工B将修改的文件上传到了私有库；
 step3 员工B将私有库的文件PR到了公共库master分支；
 step4 员工A在修改本地库代码时文件还是A，然后把A修改成了A，C；
 step5 员工A将修改的文件上传到了私有库；
 step6 员工A将私有库的文件PR到公共库master分支时出现冲突。

2.制造冲突
原来 master 文件G:\lsm-01376233\0LSM\test.txt   A,C,D,F,H ,J    
员工A 创建分支   (topic/VLSM4.1)
 A修改了文件G:\lsm-01376233\0LSM\test.txt   A,C,D,F,H ,J,O    
员工B 创建分支  (topic/VLSM4.2)
 B修改了文件G:\lsm-01376233\0LSM\test   A,C,D,F,H ,J    

 成功创造了冲突。

3.实战解决冲突
 3.1 员工B在私有库(topic/VLSM3.2)PR到集中库(master)时发生冲突。
 3.2 本地先跳转到(topic/VLSM3.2)分支。(解决冲突原则1，本地切换到冲突所在分支)
 3.3 右键点击pull操作，获取远程master分支，获取本地(topic/VLSM3.2)分支和master分支的差别
   (解决冲突原则2，拉取master分支，找到差异。这里注意要force sync)
 3.4 编辑修改冲突，然后提交四部曲，从本地(topic/VLSM3.2)PR到私有库(topic/VLSM3.2)
   (解决冲突原则3,编辑冲突并提交)
 3.5 提交完之后刷新就可以merge原来的冲突了

二、git基本操作实例

一、初始化过程
1.创建fork私有库(命名规范为：系统名称+工号，比如：LSM-01376233)
 1.1 点击Forks
 1.2 create fork
 1.3 name改成LSM-01376233  一定要点击同步fork syncing
 验证：fork库创建完成。可以通过用户下方的fork私库名确认

2.将fork克隆到本地
 2.1 点击Clone，复制url
 2.2 到本地文件夹G:\，右键Git Clone
 
二、开发过程
3.创建topic分支
 3.1 点击create branch，选择自己的私有库，type为custom类型，创建topic分支。
   规范为(topic/VLSM)
4.切换到topic分支。
 4.1 本地切换到topic/VLSM分支。到本地目录有，右击TortoiseGit->Switch/checkout->...->remote/origin
   点击fetch from获取最新的分支信息。
 验证：本地是否已经切换到topic/VLSM分支。右击查看。 
5.提交四部曲(编辑，add，commit，push)。
 5.1 编辑文件。先创建一个文件夹 /0LSM，在创建一个文件，/0LSM/testLsm.txt。
 5.2 And文件。右击And到暂存区。
 5.3 右击commit到暂存区。ps：不提交的话pr的时候是没有东西的 
 5.4 Push文件。右击Push，将本地文件从本地topic/VLSMpush到远程topic/VLSM。
6.PR(pull request)操作：从私有库topic分支(topic/VLSM)提交到集中库master分支
 6.1 网页登陆私有库，点击create pull request，source选择私有库和开发分支，
   destination选择主库和master分支。
 6.2 审核完PR信息之后就点击merge。

三、测试流程
7.创建release测试分支
 7.1 点击create branch，type选择release，branch name和topic分支name一致都是VLSM
 7.2 集中库master会同步数据到私有库的release/VLSM
 ps:如果没有获取到数据，则fork syncing强制同步然后再fetch。

8.本地切换到release分支
 8.1 本地切换到release/VLSM分支。到本地目录有，右击TortoiseGit->Switch/checkout->...
   - >remote/origin点击fetch from获取最新的分支信息。
 验证：本地是否已经切换到release/VLSM分支。右击查看。

9.提交四部曲(编辑，add，commit，push)。 

10.PR(pull request)操作：从fork库release分支(release/VLSM)提交到集中库release分支(release/V0.0)。

四、提交入基线
11.PR(pull request)操作(集中库release分支(release/V0.0)到集中库production分支(production))

五、回家
12.PR(pull request)操作(集中库release分支(release/V0.0)到集中库master分支(master))
ps:如果没有获取到数据，则fork syncing强制同步。

*********************紧急版本流程******************************************
13.创建hotfix分支：从集中库production(production)分支拉取(hotfix/VLSM.SP1)。

14.本地切换到hotfix分支(hotfix/VLSM.SP1)

15.提交四部曲

16.PR(pull request)操作(从fork私有库的(hotfix/VLSM.SP1)分支提交到集中库hotfix分支(hotfix/V0.618.SP1))
ps:集中库的hotfix/V0.618.SP1应该是组长建的

17.PR(pull request)操作(从集中库的hotfix分支(hotfix/V0.618.SP1)提交到集中库的production分支(production))

18.PR(pull request)操作(从集中库的hotfix分支(hotfix/V0.618.SP1)提交到集中库master分支(master))

 

 

其他版本：

2 提交流程

//先进入到项目目录下，可以使用cd/ls等 跟linux下一致的命令

• 确认自己的修改是在tags2-dev分支下，在该分支下做开发，如果不是，使用git checkout tags2-dev切换分支，然后进行开发
• 提交前，先合并线上的文件，git pull
• 如果有文件冲突，先将冲突文件进行压栈（暂时藏起来）git stash，然后在git pull，然后再把自己修改且有冲突的文件弹栈出来 git pop
• 此时，有红色提醒的文件，会将冲突修改部分都展示，且用>>>  <<<<类似的符号圈出来，修改即可，如果确认线上部分不需要了，删除，保留自己的逻辑即可
• 然后git status，查看一下哪些新增/修改/删除的文件
• 然后git add 添加自己想要提交的对应文件，使用git status再次确认需要提交文件是否都add了，add之后会变绿
• 然后git commit -m “提交记录摘要”
• 然后git push，输入账号密码 提交成功
• 然后通过git checkout tags2-master切换到主分支，将主分支的代码维持在最新是个好习惯
• 先进行git pull合并线上代码
• 然后将dev分支上的代码merge到主分支，git merge tags2-dev即可
• 打完收工，然后习惯性的切回开发分支git checkout tags2-dev，是个好习惯

 

当然，如果喜欢界面化的操作，大可以选择部分可视化交互工具，点点勾勾拖拉拽即可，也能实现，但我等工程狮狗之辈，通过命令代码可以更熟悉里头的逻辑，和过程，墙裂推荐如上流程。