1.【git】关于push或merge发生冲突的问题

关于git，push或者merge发生冲突的时候，解决方法一般都是
从远程库pull到本地仓库，再根据实际情况，进行修改，然后add+commit+push。
如果远程库的版本和本地库的版本差别很大，以哪个版本为准是个问题，那修改起来工作量相对来说也不小。
等修改完之后，再次push，又发生冲突的话，无疑是一件很崩溃的事。
所以，我的疑问是在实际的项目管理中，有没有比较好的方法来避免上述问题？

回答：
一般开发团队协作的时候，都是PR或者MR模式，PR(pull request)就是fork仓库到自己的账号下，然后clone自己的仓库，同时把原先的仓库作为自己的upstream（具体含义可以自行查一下）。MR(merge request)就是直接clone仓库。然后开发新功能的时候，从master切换出一个新分支，完成代码编写后提MR或者PR。但是当还没开发完成或者你的PR、MR还没有被合并到master上的时候，别人也在提代码，当别人的代码合并到master分支，可能和你的冲突了。这种情况就需要git merge origin/master(MR时)，或者直接在github页面上操作merge到最新的master(PR时我一般这样操作)，最后处理冲突。
其实没有什么以哪个版本为准的问题，一般是以远程的master分支为准（当然有些小团队不使用MR或者PR在此不提了）。

2. 有关tag的问题

对于git的第6题
在/test/目录下取 tag1.0，看看 readme 和 hello_world.c 都是什么内容，理解 tag 的 含义

使用优秀答案的方式用git checkout 1.0 时确实内容都是1.0
在网页版用tag 1.0查看内容也确实都是1.0

但为什么用git clone —branch 1.0 时克隆下来文件的内容都是2.0呢？
我的理解是：
checkout的tag标记的是一次commit，
clone时的tag是一种跟随这个文件的标记，不管文件怎么改动这个文件都有1.0的tag。
（但好像跟网页版查看tag 1.0但内容还是1.0相矛盾了，或者网页版实际也是查看一次commit的情况，很困惑）

实际生产环境中是对文件打了tag后都不改动了吗？一改动就要打个新tag 1.1这样吗？（学生没有接触过）

回答：
在实际开发场景中，一段时间（比如一个月）项目会发布一个小版本（计划的功能开发完成，测试完成），然后打包部署到服务器上。这个时候打个tag就是对这个版本的代码做一次快照，做个标记。如果别人想要使用指定版本的此服务，或者要这特定版本上做一些测试等工作，就可以直接checkout 到这个tag了。打tag是为了方便版本管理，什么时候打tag看项目管理。
如果对clone下来的内容有版本的疑问，可以使用git log — work/readme查看单个文件的commit历史，git show [commit_id]查看此commit修改的内容。