背景资料

我们正在努力从使用 SVN 转向 GIT，我们主要在 magento 商店上工作，并为每个项目配备一个登台服务器和生产服务器。

简单来说这个过程：代码首先在本地机器上开发，在每台开发机器上设置项目，然后将其提交到暂存仓库并由客户和 QA 测试，然后掌握它进入生产和最终测试的位置质量保证。

我们使用 codebase/github 存储库，部署到登台是使用 deployhq 自动进行的，从 master 到生产的部署是由系统管理员使用 deployhq 完成的。

GIT 工作流程是在受到 Internet 上建议的不同工作流程的影响后派生的，并使用了http://nvie.com/posts/a-successful-git-branching-model/和正确使用 Git/GitHub 的方法 - PHP具有开发/测试/生产服务器以及其他服务器的系统，但还包括我认为与此模型一致的命令。

GIT 工作流程

0]在本地建立新的GIT项目

• git clone [path_to_repo] -b [branch_name] [local_dir]
• path_to_repo 可以是远程存储库或分支包 (repo.bundle)

1]在捆绑导入的情况下设置远程路径

• git 远程设置 URL 来源 [path_to_repo]
• path_to_repo 是远程存储库

2]根据分配的任务创建一个新的功能分支。

• git checkout -b [branch_name] // 创建新分支并切换到它
• git push origin [branch_name]

3]所有更改在本地分支本地完成并定期推送到远程分支（分批，而不是单个更改！）如果有人想在同一个分支上工作，他需要从同一个远程分支而不是从主分支中提取数据。

• 日常生活
• git checkout [branch_name] // 切换到分支
• git pull // 从远程拉取最新的更改（例如在我们开始工作之前的早上）
• 对文件进行更改
• 混帐添加。或 git add [folder] // 准备要提交的文件列表或文件/文件夹
• git commit // 提交修改到本地分支
• git pull // 在一天结束时预推送同步以了解任何冲突
• git push // 在一天结束时将更改推送到远程分支

4]一旦远程/本地分支中的更改生效并需要在暂存服务器上进行审查，本地分支将被合并到远程暂存分支中。

• git checkout staging // 如果已经存在切换到它
• git 合并 [remote_branch_to_merge_to_master]
• git 推送

5]如果客户端确认远程分支工作正常并准备部署到实时服务器，则合并到主服务器

• 合并到主
• git checkout [master_branch_name] // 切换到 master
• git pull 原点/主
• git merge [remote_branch_name_to_merge_to_master] // 合并到 master
• git 推送

Master to Production 由系统管理员通过 deployhq 手动完成。

Q] 是否应该有另一个基于 master 的分支生产，并且只从 master 获取立即生效的更改，即始终是最稳定的代码，或者这是多余的。

我们正在寻找有关减少步骤数量的建议，以及工作流程是否与 GIT 中的最佳实践（包括其中提到的命令）一致。

所以我对我当前的 GIT 工作流程（我是新手）的意见很感兴趣，以及如何确定我的哪些更改尚未合并/推送到适当的存储库。首先，我当前的系统如下所示：

对于一个新任务，我会从 remote.master 拉到 local.master，创建一个新分支并检查它。我会在处理任务时进行各种提交，可能会切换到其他任务，然后在准备好后，会从 remote.master 拉到 local.master，将我的分支合并到 local.master，最后推送到 remote.master。

所以 2 个问题：对于一个小团队来说，这是不是矫枉过正？省略本地分支机构是否更有意义？如果是这样，一些建议表明要么存在“快速转发”问题（我理解这会使 remote.master 中的更改无法区分），要么存在大量具有潜在意外时间戳且难以解析的提交。

2、假设上述工作流程：我有时会频繁地在任务之间切换。我想要一个显示我的屏幕：

我可能会忘记各种功能是否已合并，以及合并到何处。我绝对不想逐个分支地尝试通过“git diff”或其他命令来预测这些信息。我目前在 Windows 上使用 Tortoise GIT，但对其他图形替代品持开放态度。我有时确实使用 shell，但更喜欢 UI。有没有办法获取这些信息？

我最近在我的 git 合并策略上犯了一个错误，直到我已经继续在项目上工作并进行了更多提交时才注意到结果错误。为简洁起见，假设我有两个分支，hotfix并且new_feature. 我做了类似以下的事情：

在上述事件之后，其他开发人员也对 Hotfix 分支进行了提交。现在，我们有一个想要推出的修补程序，但不能推出，因为它包含未完成的功能工作。

我已经看到了很多关于这种情况的类似问题，但没有一个是 100% 匹配的（其中大多数涉及在糟糕的拉动之后直接撤消提交，而不是先推动。我更进一步，真的很无聊。

关于如何解决这个问题的任何分步指南？

谢谢！

编辑：许多其他答案都提到git reflog了，所以这是我的修改后的副本。我已经更改了哈希和分支名称以匹配我上面的示例。

在上面的 reflog 中，HEAD@{3}看起来是错误的合并。我在hotfix分支上，并拉入new_feature分支，这产生了合并冲突。我把它们修好，然后推。我该怎么做才能解决这个问题？

我有两个房间，我在其中使用 git 维护一些源代码，一个“开发”房间，其中大多数开发发生在一个“部署”房间，我们实际使用该软件。不可避免地，部署室也会发生一些变化。我希望两个房间在 git 中共享相同的历史记录。

限制：

1. 出于安全原因，这两个房间没有网络连接。
2. 只有文本文件（人类可读）可以离开部署室。

使用 将更改移动到部署室很简单git bundle，并跟踪我们移动到部署室的最后一次提交。由于仅限文本的限制，将更改移出房间更加困难。

目标：在我的两个未连接的房间之间来回移动提交，就好像git pull发生了一样，即两个房间中的 SHA1 哈希值相同。

至今：

• 我试图git format-patch将更改从部署移回开发，但这不会记录合并，因此需要为每个连续的更改集生成不同的补丁集以及如何重现确切的合并提交的一些记录发生在两者之间。有一些关于为合并提交制作差异的讨论，但这似乎并没有捕捉到实际的祖先，只有变化。看起来补丁可能不是一种足够丰富的格式来提供必要的信息。

• 一些捆绑到文本的脚本可用于将捆绑转换为非压缩和人类可读（ish）格式，（然后在下载后再次返回），但我没有发现存在这样一个脚本的证据。

• 也许可以编写一个脚本来将历史从某个共同的祖先走到最新的提交，然后 a) 制作补丁或 b) 重新创建一些众所周知的 ref 的合并。

回退： 我总是可以将来自部署室的提交压缩到一个原始补丁中并破坏历史记录，但是从 dev->deploy 进一步下载会破坏任何现有的工作副本。不理想。

更新： 我相信git fast-export可以做我需要的，尽管大多数例子都适用于整个存储库而不是部分历史，如git bundle. 我有一个工作玩具示例，我可以在其中将部分历史记录导出到过时的克隆中，但它需要我手动编辑快速导出输出，以便我from <sha1>在第一次提交中添加一个。如果不进行此修改，导入会创建不同的 sha1，然后使用Not updating refs/heads/master (new tip <hash> does not contain <master's hash>).

Update2： 我的git fast-export解决方案确实有效，但存在带宽问题，因为它通过提供全新文件而不是与以前文件的差异来工作。这是不可接受的，因为我实际上必须阅读所有这些额外的行。

有没有办法在 gitweb 界面中列出已删除的分支？

我刚刚在 git 中创建了一个新分支，并且在 gitweb 界面中也有同样的反映，但是当我删除该分支时，它没有在 gitweb 界面中列出，理想情况下它应该在 gitweb 界面中列出一条消息 Branch deleted

请让我知道它是否可能！

I'm liking a lot "a simple git branching model". It keeps the master clean, history nicely formatted and informative, you can do code reviews on feature pushes, etc. But I'm confused with one aspect of it - why rebase on top of the pushed feature branch, what goal does it serve? If the branch is pushed for review, you will not have any commits to it so no reason to rebase. If the branch is used for collaboration, you would be probably better off just merging in other participant changes and rebasing on origin/master only. What I am missing?

P.S. Bonus question - if you use branches for pull requests, but you need to collaborate on the branches with other people, what is the best practice here? Is it common to have pull requests for branches?

我有一个开发分支和几个功能分支。我在 Atlassian 上找到了这个 git 工作流程。这个想法是 dev 分支将只读给除版主之外的所有开发人员。所有开发人员都只能在功能分支之外工作。但问题来了——

开发人员 A 开始在功能分支 A (FB-A) 上工作。与此同时，Dev 分支将取得进展。开发人员 A 完成了他在 FB-A 上的工作并提交并将代码推送到 FB-A（提交 #1）。然后，他将从 Dev 拉到 FB-A 以获取最新信息。来自 Dev 的所有更改都将添加/修改到 FB-A。然后他将提交这些文件并将其推送到 FB-A（提交 #2）。现在，文件已准备好合并到 dev 分支。当我尝试这样做时，它会提交 Commit #1 和 Commit #2。这是正常的做法吗？

是否可以仅将第一个提交合并到 Dev，因为它具有开发人员的实际更改？我在这里错过了什么吗？

我正在寻找一种简单的方法来确保一个本地功能分支完全 1:1 替换远程部署分支，而部署分支只不过是部署的工具。

设置

偏僻的

master：部署到生产
阶段：部署到登台

本地开发商

主 -> 远程主
功能 A
功能 B

本地开发商 b

主 -> 远程主
功能 C
功能 D

问题

现在假设开发人员 A 想向老板展示他的功能 A。因此他需要将它部署在登台服务器上，为此他将他的功能 A 合并到舞台中，并推送和部署。但是如果现在开发人员 A 想要显示功能 B 或开发人员 B 想要显示功能 C 或 D 怎么办。为了确保没有干扰，必须保证服务器上只有一个功能，而不是两个或三个。

我现在知道的唯一方法是恢复部署分支阶段，直到它类似于 master，然后可以将另一个功能合并到其中进行部署。或者可以“简单地”删除分支阶段，然后从 master 重新创建它。

那么如何轻松实现呢？这实际上是强制推动吗？

干杯！

我想从存储库中提取，并且我相信该存储库中与我的冲突的任何更改集都是更好的选择。

如何使拉取自动化，这样我就不必处理任何合并冲突，并且我从中拉取的存储库总是能赢得战斗？

查看命令行选项，我不确定是否git pull --squash是我正在寻找的，或者我是否必须应用某种合并策略。我不知道我会传递给什么

或者

如果那确实是我应该使用的标志之一。

我们有一个存储库，它只有一个分支：master。

我和我的朋友在我们的本地机器git clone上掌握。每当我们有更改时，我们都会git commit在git pushmaster 上进行更新git pull。

现在，我们购买了一个 VPS 作为我们的 staging （稍后将投入生产），并且我们还在我们的域上设置了一个子域：

http://dev.domain.com/ => /var/www/project_dev

http://domain.com/ => /var/www/project_prod

现在我很困惑我应该怎么做才能在两个目录上都有一个 git 副本。我是否应该创建一个开发分支并将我们的本地更改推送到那里，那/var/www/project_dev将是克隆的地方？那么主分支是我应该克隆的地方/var/www/project_prod？能否请您赐教。