"Soft labor practice on the subject" - code management team
1. Your team source code control Where? What is the use the system?
After a code file is checked out, another person can check out the file and modify it? There are several designs, what advantages and disadvantages?
Our team in Github code control, the use of the Windows system.
There are two designs: the ① check out a file, file locking, others can not check out. ② file is not locked, any use.
For both designs, we believe that the first code version control can ensure that the project is more reasonable, there is no similar situation to read "dirty data" appears, but this will take more time, the operation will be a little tedious number; the contrary the second design files are not locked when the easy to modify, suitable for small projects like this we just started, but there will be a certain degree of disorder on the code.
2. How to see the differences and previous versions of this document?
As noted above, we are using a version control Git, so we can use some of these features to help us, for example:
git diff: View is working tree (working directory) difference with the index file (staging area) is.
git diff --cached: a view index file (staging area) and the difference commit (local repository) is.
git diff HEAD: is to see the difference working tree (working directory) and commit (local repository) is.
We can see the details of the differences of these attributes.
3. If a file has been modified by someone else after you check out, so how do you combine different modifications (merge)?
Use Git to help us get this done. In general, after git pull git automatically merges the modified portion Git, automatic Merge. However, there are cases not automatically merge: for example, a place like the same local database and remote database have taken place without modification, then Git can not determine which modifier to choose, so the conflict will occur. However, Git will make a mark in local conflicts! Let us take the example of the Internet to be a model:
<<<<<<< HEAD
test in Local
=======
test in Remote
>>>>>>> 17c805 ... (Commit Hash value)
== parting line of the party is a local database content
== below the dividing line generated content is a particular conflict commit the modified remote database. This is when you need to identify what can be retained, which preserve the contents of the remote database, which preserve the contents of the local database. After the contents of the file merge conflicts, and delete <<<<< =====, >>>>> such a thing, to re-add, commit, push, to complete a manual merge.
This requires us in the allocation of tasks, following one simple rule: try not to let the two tasks overlap on the same file. Everyone scope or other modified files are immobilized, try not to let two people modify the same file. Of course, like most of the time the front and rear will have conflicts when modified, this time we would use another set of mechanisms to help us avoid this: New branch and branch consolidation. (Will be mentioned below)
4. You have 20 files are modified on the same function, how do you ensure that these documents are checked in at the same time successfully (atomicity modified)
First of all, git as a mature source code version management system itself can guarantee atomicity at check in, it is generally in our project development process will encounter is not part can check in, check-in can not be part of the problem.
But if there really encounter this problem, we can create a branch, branch appears, you can make any one developer based in other people's code or environment full available (ie stable version) environment to conduct their own independent development section. The final merger work can be placed within a day, will feature on all merged into a Branch dev branch up. But this is also facing some risk, while simultaneously merging multiple branches if larger conflict, and must be carefully merged. Meanwhile, when a solution of Issue, Issue may create a branch, the Issue resolved, the technique may be used branches merge two or more branches combined.
5. On your PC about three bug changes, but they are not completed, then you have to modify the fourth emergency bug, how to put aside local modifications to ensure modify fourth bug in a clean environment, and check in modified?
在Git里，不能完整地保证commit后整个环境处于可编译或可运行状态下的commit是不好的提交。所以在文件半完工的状态下，我们不可以使用commit来将文件修改的内容留下来。Git为我们提供了一种类似于操作系统里的保存现场的指令，那就是stash。 它可以把当前工作现场"储藏"起来，等以后恢复现场后继续工作，使用方法类似下面：
$ git stash
Saved working directory and index state WIP on master: 5655bdc Merge branch 'mas
ter' of https://github.com/buaase/Phylab-Web
HEAD is now at 5655bdc Merge branch 'master' of https://github.com/buaase/Phylab
-Web
此外，既然需要一个干净的环境，还可以新创建一个本地仓库，从远程仓库clone到新的本地仓库中，进行修改。
6.如何给你的源代码建立分支？
建立分支利用git branch 分支名操作，跳转到相应分支用git check out 操作，分支合并用git merge 操作，在确认了修改以后，进行git commit 操作提交。
7.一个源文件，如何知道它的每一行都是什么时候签入的？
Github上会显示签入者名字和签入的时间
8.如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？
使用git来打标签这件事，在Github中是可以很方便来做这件事。每次发布到一定成果后，就需要发布一个realease版本，但是这样的话，是对commit本身打标签。点击release，然后会发现create a new release，点进去之后填一下就可以了。
9. 你的团队是否能部署自动构建的任务
（自动同步所有文件，自动构建，自动运行单元测试，碰到错误能自动发邮件给团队）
决定采用drone.io来进行自动化单元测试，每次测试都会自动按照预定的脚本运行单元测试，单元测试通过以后可以在Github的ReadMe里体现出来。