这种方式费时费力，后端人员需要手动比较文件，再将修改"拆分"到项目里面，严重影响修改项目的效率。
现在的协作方式是这样：
新建一个单独的前端分支(dev_frontend)，前端人员可以直接push所有的修改到这个分支，在测试服，只需要手动切换到这个分支下，前端人员就能实时查看到所有的修改。等修改完成之后，将这些修改merge到dev分支，在测试服再进行一次切换(切换回dev)，市场部门的同事即可进行在线测试。
备注：需要前端开发人员对项目的文件结构具有大致的了解，同时需要掌握必要的git和linux服务器操作指令。
// 2018.04.17更新
开发过程中发现：在测试服为前端开发人员建立专有分支的方法仍然存在问题，如下：
1、测试服权限开放给前端开发人员存在安全隐患，比如文件被误删(linux系统恢复已经删除的文件过程繁琐并且不一定能成功)；
2、后端人员和前端人员同时需要在测试服上修改文件做测试时，必然会引发冲突；
3、前端人员每次做一些微小的改动，想要看实际的页面渲染效果，都要在本地和测试服上做分支管理费时费力，并且多次的分支操作，也容易引发版本管理混乱的问题。
鉴于目前前后端开发人员人数不多的情况，继续调整前后端协作的方式，如下：
1) 简化分支：每个项目仅有两个分支master和dev，master运行在正式服(被保护，非master角色无法进行push和merge操作)，dev运行在测试服(非被保护，developer和master都有修改、提交和push的权限)；
2) 前后端人员现在都直接在dev上做开发，每次开发前务必先pull一下本地的代码(因为可能其他人做了push操作)，pull的过程中如果提示有冲突，用下面的方式来解决：
$git stash (将本地文件的最新修改暂存起来，基于本地远程代码库中的最新的提交版本号)
$git pull (直接将远端最新的代码拉取下来)
$git stash pop(将自己做的已修改的代码"恢复"到当前的本地代码库中)
最后这一步(stash pop)这里，如果提示有冲突，应该立即修改相应的冲突文件，继续做后面的开发或者进行提交和push的操作。stash pop之后，如果你并不打算提交当前修改的版本，只需要将冲突的文件修改好(去除冲突提示的代码，并且手工做一下代码"合并"，因为可能有部分代码其他同事做了开发并且提交到了版本库)；如果你打算立即推送当前本地的修改到远程库中，执行正常的push流程操作即可(add，commit，push)。
3) 所有开发者都在本地部署一个运行站点的环境，这样所有开发人员都可以实时查看最新改动的代码效果，不仅不用占用测试服的环境，还能大大提高本地开发和测试的效率，同时也可以有效地控制push的节奏，极大地简化了分支上的日志列表。
目前是前端人员本机都安装了wampserver，并且做了相关的配置，未来会考虑统一使用Docker。
遵循上面的流程，可以极大地提高前后端的协作效率，happy coding ~
参考资料：
1) https://blog.csdn.net/wh_19910525/article/details/7784901， (git stash和stash pop)
2) 远程代码库均删除了dev-frontend分支, 使用 git remote update origin --prune 命令即可更新本地的远程分支列表。
3) 如果git stash之后，并不想再stash pop回来，可以使用git stash drop删除所有的暂存修改，这里存在一种情况：错误地执行了stash drop，想要恢复回来，该如何操作？这篇文章有详细的讲解：如何恢复丢弃的 git stash 数据 - Linux中国的文章 - 知乎http://zhuanlan.zhihu.com/p/28948567
// 2019.03.06更新
本文阐述的内容，仅提出了一种可行的代码更新流程，实际操作过程中如果版本发布频率比较大尤其是部署过程中包含代码编译等其他关联性的动作时，需要考虑采用可持续集成的方案。
================ RESTART ================