ソースコード管理チーム - 対象のソフト労働慣行
（1）あなたのチームのソース管理はどこ？使用は、システムは何ですか？
A：私たちは、マッチしたGitのシステムを使用して、GitHubの上のコントロールを調達します。
コードファイルがチェックアウトされた後、（2）、別の人がファイルをチェックアウトし、それを修正することができますか？
a）はいくつかのデザインがありますが、どのような長所と短所？
：2つのデザインがあります。
①は、後に他の人がチェックアウトすることができない、ファイルがロックされ、ファイルをチェックアウト。
②誰もがファイルをチェックアウトして自由です。
長所と短所：効率を最大にするために、我々はファイルに過度の制限を移動するために外に移動する必要はありませんので、これによって段階での開発のスケールには、比較的小さいです。移動したときの動きは明らかにソースコードの同期が不要な競合とエラーを低減するように変更することができますが、欠点は明らかである、並列性の欠如を確認するために、ファイルをロックし、効率プロジェクトの開発は非常にでした地球が本鎖チームプロジェクトで、その結果、理由はヒューマンエラーの最も可能性が高い極端な場合には、減少しています。それどころか、私たちは、道のうち、旧互恵の長所と短所を移動するために移動するために自由を使用しています。
（3）どのようにこれと以前のバージョンのファイルの違いを表示するには？
：①gitの管理では、ファイルの違いと以前のバージョンを確認するためにGitの差分を使用します。
Gitの差分：ビューは、インデックスファイル（ステージング領域）とツリー（作業ディレクトリ）の違いを働いている
のgit diffは--cached：ビューのインデックスファイル（ステージング領域）との違いは、コミット（ローカルリポジトリ）があります。
Gitの差分HEAD：違い作業ツリー（作業ディレクトリ）を参照し、（ローカルリポジトリ）をコミットすることです。
gitのでは、3つの概念は非常に重要であり、機能の一つは、Gitが作業をコミット、インデックスファイルに作業ディレクトリから追加する追加、変更することであるインデックスファイルから変更することができますコミットするために追加されます。
ビューには2つのバージョンのID変更ログ差を提出します
$ gitのdiffがコミット-ID1がコミット-ID2を
ビューは、それらのファイルを変更する二つのバージョン番号を提出し、あなたが使用することができます
$ gitのdiffをコミット-ID1コミット-ID2 --stat
提交日志显示每个版本的提交主题和具体修改的文件名字
$ git log --name-only
②在Github中，也可以通过可视化的界面来看到每次修改的代码（包括增加，删除）文件与修改的具体位置，修改的具体内容。可以看到每次修改的文件路径、文件的内容、红色代表删除掉的内容，绿色代表添加的内容。
(4) 如果某个文件在你签出之后已经被别人修改，那么你如何合并不同的修改（merge)?
答：我们使用Git来帮助我们完成了这件事。在一般情况下，git pull后git会自动合并Git修改的部分，自动的Merge。但是，也存在无法自动合并的情况：比如远程数据库和本地数据库的同一个地方都发生了修改的情况下，因为Git无法自动判断要选用哪一个修改，所以就会发生冲突。但是，Git会在发生冲突的地方打个标记！这时候我们需要通过一双慧眼来识别哪些都可以保留，哪些保留远程数据库的内容，哪些保留本地数据库的内容。在将文件冲突的内容合并后，删除掉<<<<< 和=====，>>>>>这样的东西，重新add，commit，push，即完成了一次手工合并。不过因为大家都是新手入门，不太会合理地人工合并冲突，所以项目经理本身在分配任务时，遵循了一个原则：尽量不让两个人的任务在同一个文件上产生重叠。每个人修改的文件范围或者其他都是固定的，一般不会存在两个人同时修改同样的文件。当然，前端和后端在修改时大部分时候都会产生冲突，这时候我们就使用了另一套机制来帮我们实现这一点：新建分支与分支合并。
(5) 你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性）
场景： L一个一个地签入20个文件。在签入完10 个 .h 文件之后，他发现一些 .cpp 文件和最新的版本有冲突，他正苦恼如何合并。而此时ANN从客户端同步了所有最新代码，但是编译不成功 。因为有不同步的.h 文件和.cpp 文件！因此，其他组员也开始抱怨这件事
答：git本身就可保证在签入时的原子性，所以在项目开发流程中，我们没有遇到部分修改可以上传而某些部分的修改不能上传的混乱状态。
(6) 你的PC 上有关于三个bug 的修改， 但是都没有完成，这时你要紧急修改第四个bug，如何把本地修改放一边，保证在干净的环境中修改第四个bug, 并签入修改？
答：
在本地新建一个分支，再在新的分支上修复BUG。当前分支的内容就被保存在原来的位置上
(7) 如何给你的源代码建立分支？
场景：团队中有多个人再开发一个项目，另一人在开发一个新的功能，需要一周时间完成，他写了其中的30%还没有写完，如果他提交了这个版本，那么团队中的其它人就不能继续开发了。但是等到他全部写完再全部提交，大家又看不到他的开发进度，也不能继续干活，这如何是好呢？
对于这个问题，我们就可以用分支管理的办法来解决，开发新功能时可以创建一个属于他自己的分支，其它人暂时看不到，他在自己的分支上全部开发完成时，再一次性的合并到开发分支上，这样我们既可知道他的开发进度，又不影响大家干活，是不是很方便呢？
这里讲解Git的分支功能
创建分支：
我们进入到以前的项目里：
git branch
你会看到我们当前所出的分支为master。
git branch #查看当前分支状态
git branch BobBranch #创建名为BobBranch的分支
git checkout BobBranch #切换到BobBranch分支
git checkout -b test2 # 如果我们使用checkout -b 可以直接创建并切换到分支
删除分支
git branch -D test2 #如果处于该分支，会出现删除错误
分支提交
我先删除一个文件
正常add 和commit
git add . git commit -m "Branch delete file and commit test"
创建一个分支提交的别名Bob，通过branch分支提交
git remote add Bob https://github.com/WytheO/gitTest.git git push -u Bob BobBranch
那么结果是这样，因为你在配置git信息的时候，用户名邮箱没有更换，那么分支状态会显示你最新的提交且所处于哪个开发中的分支：
合并分支
当你回到你的主分支时，你会发现有个提示你的代码更新了，被谁谁分支。
主分支合并其他分支
git merge BobBranch #参数就是分支名
git status #查看发现commit有个分支信息的提交
主分支接收合并更新主分支
git push -u Wythe master #直接正常push，将BobBranch的提交push到主分支
可以看到主分支的test.txt也被删除了。
PS:git 创建开发分支，并合并代码
1、更新代码并创建新分支
git pull -r
git checkout -b dev
2、开发，并在本地提交改动
git add -A . git commit -m "some words"
3、返回master 更新代码
git checkout master
git pull -r
4、进入dev分支更新代码
git checkout dev
git rebase master
如果有冲突在开发分支下修改
5、合并分支并提交代码
git merge dev git pull -r git push
(8) 一个源文件，如何知道它的每一行都是什么时候签入的？
场景： 在开发过程中发现某一行代码出现问题而又不敢贸然改动， 这行代码是什么时候，为了什么目的，经过谁签入的呢？ 直接修改的话会不会导致其他问题呢？ 怎么办？
以Github为例：
如果你要查看文件的每个部分是谁修改的，那么 git blame 就可以做到. 只要运行git blame [filename]，你就会得到整个文件的每一行的详细修改信息：包括SHA串，日期和作者。
也可以用"-L"参数在命令(blame)中指定开始和结束行:
$>git blame -L 160,+10 sha1_file.c ace1534d (alsenlululu 2019-05-25 23:56:02 -0700 102)} ace1534d (alsenlululu 2019-05-25 23:58:34 -0700 103) 0fcfd160 (Ann 2019-05-24 13:26:55 -0700 104)/*
(9) 如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？
答：使用git来打标签这件事，在Github中是可以很方便来做这件事。每次发布到一定成果后，就需要发布一个realease版本，但是这样的话，是对commit本身打标签。在git里，标签分为两种类型：轻量标签和附注标签。轻量标签是指向提交对象的引用，附注标签则是仓库中的一个独立对象。想查看tag的话，可以使用git tag来查看，如下：
如果想回到某个标签时某个文件的状态，那么只要使用git checkout tag(标签名) 即可，如下面这个gif所示：
(10) 你的团队是否能部署自动构建的任务
- （自动同步所有文件，自动构建，自动运行单元测试，碰到错误能自动发邮件给团队）
答：我们团队并没有构建自动测试脚本。