我们正在从SVN过渡到git，有些概念我无法理解。
我们的设置如下：
- 实时服务器，"实时"
- 内部开发服务器，"本地"（git服务器，svn守护进程，所有repo都位于此服务器上）
- 工作站（iMacs）
- 家用电脑（主要是linux电脑）
我已经将我们的源代码转换为git repo，并将其提交给"local"。这一切都很好，当我克隆它时，它会将主分支复制到我的本地环境中，无论我是在家还是在工作。拉入实时服务器也很好，它将主分支更改拉入实时环境。但我想有以下可能性：
-
我希望能够在工作站上进行开发和提交，而无需推送到master分支，但我希望这些更改也能反映在我的家用机器上。换言之，我希望能够进行部分更新或功能，提交，并在家中继续工作，而不会将其拉入任何类型的实时分支。这是通过分支完成的吗？我提交然后推送到特定分支？请注意，用家用电脑跟踪工作站git存储库是不可能的，因为工作站并不总是打开的（任何在Mac上运行过java应用程序的人都知道它最多只能打开几个小时）
-
我希望每个开发人员都能够处理自己的应用程序部分，而不需要我们相互依赖。对每个开发分支这样做明智吗？还是应该对每个特性进行分支？
-
当一个功能的工作完成后，是否建议将分支合并到主回购中，然后将主回购更新拉到活动环境中，或者我们应该有一个单独的"生产"分支来实现这些目的？通常如何通过git进行实时部署？由于我们的发布频率约为每天10次修订（开发周期极快），SVN到目前为止运行得很好，因为我们的实时站点只是对存储库的一次检查，每当更新准备好时，我们只需在实时服务器上对这些文件调用SVN更新。git对此有什么最佳实践吗？
编辑：
我对这一切如何运作的假设的实际例子：假设我们的项目是"项目"，我们有开发人员"dev1"、"dev2"answers"dev3"，每个开发人员都有2台机器。该团队有3项任务："bug"、"功能"answers"协作"。Bug分配给dev1，feature分配给dev2，协作是三者需要共同工作的功能（$REMOTE是我们本地开发服务器上主repo的url，即。user@local：repo.git）：
===========
I。本地工作
由于dev1被分配给"bug"，他将负责处理这个问题。他做以下事情：
$git branch bug
$git checkout bug // switches to bug branch
( // edit some files)
$git commit -a -m 'I fixed the bug!'
$git push $REMOTE bug
这个开发人员现在如何将他的修复程序合并到主回购中，以及一旦合并完成，他如何删除所有机器上的bug分支？我希望错误分支在人们进行更新或获取时消失，以防他们检查或以任何方式检索。
==========
II在本地工作，然后在另一个位置的同一同步分支上继续
"功能"已分配给"dev2"，他这样做：
$git branch feature
$git checkout feature // switches to feature branch
( // edit/add some files etc. )
$git commit -a -m 'I made some updates, will continue at home'
$git push $REMOTE feature
// at home, the developer does the following, right?
$git clone $REMOTE -b feature /some_new_folder // if he didn't clone the whole repo previously
or
cd previously_cloned_repo_master_or_whatever
$git fetch
$git checkout $REMOTE feature
( // right? )
( // edit some files then ... )
$git commit -a m 'I finished!'
$git push
// Same as above, what next? How to merge it into all other branches and safely delete the branch afterwards. What happens when someone is in a branch that has been deleted, and makes a pull?
==========
III一个分支上有许多人，与主分支分离
"协作"是一项共同努力，将由来自所有6个地点的三名开发人员共同完成。它是由dev3创建的。
$git branch collaboration
$git checkout collaboration // switches to needed branch
( // add something, so we have something to commit)
$git commit -a -m 'Initialized new branch'
$git push $REMOTE collaboration
( // The other two devs can then simply call .. )
$git fetch
$git checkout $REMOTE collaboration
( // And they're ready to go, right? )
( // Each dev then makes his own edits on some areas, commits, and pushes. All pushes change the content of the branch, so that if dev2 pushed and dev1 makes $git pull in the root of the project while on this branch, dev1 will get his changes, right? )
==========
此外，是否可以将分支限制为特定的分支创建者？例如，我想看看dev1在删除"bug"之前对它做了什么，但如果我想对它进行一些自己的更改，我不应该被允许这样做，我应该为给定的分支发出一个拉取请求，dev1应该手动接受我的更改-我不应该强迫他这样做。
TL；DR
使用数字流。
它可以消除问题，并使您询问的一些事情自动化。当你熟悉git流和分支等时，你可以很容易地选择不同的方式——或者手动。
更改也将反映在我的家用机器上
在你的imac推/拉到非主机上，在你的家用机器上推/拉从非主机上。
其中"非主"是指你目前正在工作的任何分支机构。
每个开发分支
由您决定，您的工作流程需要帮助而不是阻碍开发。例如，如果两个开发人员在同一任务上合作，你想强迫他们在不同的分支机构工作吗？功能分支可能更有意义，不过拥有用户分支并没有错。
独立的生产分支
不管你怎么做-你的实时应用程序应该从一个已知的稳定标签/分支中提取，通常不要直接推送到master中，因为破坏东西是开发的一部分，但破坏你的实时程序将从中提取的代码是你绝对希望避免的。你应该能够在任何时候都毫无疑问地拉入你的实时安装，你可能会拉入损坏的代码。如果您使用的是Continuous Integration服务器，那么您可以轻松地从开发分支自动合并，以掌握是否所有测试都通过，甚至自动部署。
当分支使用完成时
所有的工作流疑虑都是一样的。分支完成后，将其合并到主分支。
即
$ git branch working-on-this master
$ git add ...
$ git commit ...
$ # rinse and repeat
$ git push --set-upstream $REMOTE working-on-this
时机成熟时：
$ git checkout master
$ git pull
$ git merge working-on-this
$ git push
$ git branch -d working-on-this
$ git push $REMOTE :working-on-this
您不会显式删除其他计算机上的所有分支；然而，任何人在任何时候都可以运行：
$ git branch --merged master
如果一个分支完成了，它将看起来像这样：
$ git branch --merged master
master
working-on-this
$ git branch -d working-on-this
这表明可以安全地删除对此进行的工作。在任何情况下，如果您在执行命令时尝试删除未与所在分支合并的分支，则git branch -d会触发警告并中止。
如果你发现你有多个被认为已经完成的远程分支，你可以用一个命令来清理它们：
$ git remote prune -n origin
-n标志意味着它将只报告要删除的分支——删除该标志将实际删除过时的远程分支
如果你有几个开发人员在同一个分支上工作（协作）沟通是关键不要依赖工作流，在离开你的团队中的一个在（据称）完成的分支工作之前，积极讨论删除内容。
限制分支提交权限
是的，你可以这么做，但你真的想这么做吗？你最好使用沟通和惯例。
一些建议：
- 任何人都可以创建远程分支
- 没有人向master提交/合并（只有首席开发人员这样做）
- 没有人删除远程分支（只有首席开发人员这样做）
- 没有人修剪远程服务器（只有首席开发人员这样做）
任何的人都可以在任何时候执行上述任何操作，但假设你信任整个团队，就没有理由实际限制开发人员来阻止他们这样做——可能会有一些时候他们需要打破等级，而规则阻止了这一点，而惯例则没有。
我希望能够发展和承诺。。
是的，这是通过分支来实现的。最初，你把整个分支机构从工作站推到"本地"，然后如果你想继续在家工作，你可以在家里签出一个跟踪分支机构。
我希望每个开发人员都是…
我建议使用功能分支，而不是开发人员分支。当几个开发人员在一个功能上进行合作时，这更有意义。
当一个功能的工作完成后，建议这样做吗。。
这是个品味问题。我们通常首先创建一个发布分支（我想很多人都这样做了），所以我们在真正的活动内容和需要测试的内容之间有一条缝，当发布分支被认为是稳定的时，我们将该分支合并到master中，然后它就可以上线了。
我不认为有任何最佳实践。这取决于你在做什么，即你正在开发什么样的东西。如果你想保留你的工作流程，git会允许你这样做。而不是"svn-update"，而是"gitpull"。
您可以为分支引入命名约定，让它们都能在local上快乐地生活。例如：
工作中：
work$ git branch -a
master
* user1/my-work
remote/local/master
remote/local/user1/my-work
work$ git push local user1/my-work
在家：
home$ git branch -a
master
* user1/my-work
remote/local/master
remote/local/user1/my-work
home$ git pull local user1/my-work
每个用户都会为其分支分配一个前缀，因此local可以作为某种类型的中央存储服务器。