问题标签 [git-branch]

我们有一个几乎每天都会更新和发布的网络应用程序。我们使用 git 作为我们的 VCS，并且我们当前的分支策略非常简单且被破坏：我们有一个 master 分支，我们检查我们“感觉良好”的更改。这有效，但仅在我们签入重大更改之前。

有没有人喜欢满足以下要求的小型团队的 git 分支策略：

1. 适用于 2 到 3 名开发人员的团队
2. 轻量级，没有太多的过程
3. 允许开发人员轻松隔离错误修复和更大功能的工作
4. 允许我们保持一个稳定的分支（当我们必须让我们的生产服务器工作时，那些“哦，废话”的时刻）

理想情况下，我很乐意看到您为开发人员处理新错误的分步过程

由于各种原因（主要是代码审查），我需要经常从当前的开发分支切换到其他分支。

目前，我使用“git stash”来搁置未提交的更改，签出其他分支，然后切换回来并执行“git stash apply”

但是，有时我会在那里添加一些新添加的文件，这些文件没有被跟踪。不幸的是，存储不会影响它们。在这种情况下，我必须将它们添加到索引和存储中。

我在这里寻找的是一个工作流程，我必须执行最少的操作来切换分支，最好避免将文件添加到索引中。

我有一个带有两个分支的 git 存储库。如果我克隆我的仓库，我只能看到主分支。我的两个分支都是最新的。问题是我不完全理解合并和分支。该死！

我的例子可以在这里看到：

http://github.com/rimian/rimian/network

谁能告诉我如何让它恢复正常？

我有一个想法，通过在 GIT 更新挂钩中设置一个锁定脚本来锁定用户将文件推送到其中的存储库，因为推送只能将用户 ID 识别为参数而不是分支。所以我可以锁定整个 repo，它只是锁定一个目录。

有没有办法锁定 GIT 中的特定分支？

或者有没有一种方法可以让更新挂钩识别用户从哪个分支推送以及代码被推送到哪个分支？

我目前正在研究 ClearCase，现在正在迁移到 GIT。但是我们需要这种迁移方式，所有工作都将在 GIT 中完成，并且数据将同步到 ClearCase 流。我们将在 GIT 和 CC 中拥有相同的分支名称和流名称，因此脚本编写应该不是问题。这里的问题是，

有人可以建议同步 CC 和 GIT 的最佳模型吗

1. 将 CC 中的所有 Vobs 作为 GIT 中的单个 repo，并将 CC 中的主流作为 GIT 中的各个分支。- 单个 GIT 存储库（VOBS）和许多分支（CC 流）。- 这占用的空间更少，因为 VOB 被保存为具有许多分支的单个 repo。

2. 将重要的 CC 分支作为独立的 GIT 存储库，并且每个存储库都具有所有 CC VOB。- 许多 CC 分支的许多 GIT 存储库 - 这将占用大量空间，因为 VOB 将被复制。

您认为哪一种是使其与 ClearCase 保持同步的最佳方式

I have a following scenario:

3 branches:
- Master
- MyBranch branched off Master for the purpose of developing a new feature of the system
- MyBranchLocal branched off MyBranch as my local copy of the branch

MyBranch is being rebased against and pushed to by other developers (who are working on the same feature as I am).

As the owner of the MyBranch branch I want to keep it in sync with Master by rebasing. I also need to merge the changes I make to MyBranchLocal with MyBranch.

What is a good way to do that?

Couple of possible scenarios I tried so far:

I.
1. Commit change to MyBranchLocal
2. Rebase MyBranch against Master
3. Rebase MyBranchLocal against MyBranch
4. Merge MyBranch with MyBranchLocal

II.
1. Commit change to MyBranchLocal
2. Merge MyBranch with MyBranchLocal
3. Rebase MyBranch against Master
4. Rebase MyBranchLocal against MyBranch

III.
1. Commit change to MyBranchLocal
2. Rebase MyBranch against Master
3. Merge MyBranch with MyBranchLocal
4. Rebase MyBranchLocal against MyBranch

I already know that scenario III seems to be messing the commit history up a lot, potentially duplicating commits.

What is your experience? What scenarios do you recommend to minimize the merging effort and keep the history clean?

我查看了 git-new-workdir，但我不希望共享历史记录，因为分支具有发布-主关系。也就是说，发布分支中的更改我想传播到主线，但主线中的更改我不希望在发布线中。

对我来说，一个常见的模式是修复发布行中的错误，将其集成到主行，然后同时在两个分支中开始构建。

有没有办法用 git-new-workdir 做到这一点，我需要克隆，还是有更好的解决方案？

谢谢

我希望能够做到以下几点：

1. 基于其他（远程或本地）分支（通过git branch或git checkout -b）创建本地分支

2. 将本地分支推送到远程存储库（发布），但使其可跟踪git pull并且git push将立即工作。

我怎么做？

我知道--set-upstream在 Git 1.7 中，但这是创建后的操作。我想找到一种在将分支推送到远程存储库时进行类似更改的方法。

如果我有 n 次提交，我如何从 n-3 次提交中分支？

我可以看到每个提交的哈希值。

实际上我正在尝试获取有关合并冲突的报告。我使用 'git blame' 来查看谁更改了哪一行，但我找不到分支和存储库名称信息。

有没有办法从“git blame”或提交ID中找到文件的存储库名称、分支名称和作者姓名，这样每当发生合并冲突时，我都可以向接触过该文件/行的作者发送电子邮件解决它。