问题标签 [git-workflow]

我对 git 还很陌生，我想弄清楚为什么我的工作流程会删除其他人所做的工作。工作流程如下：

1. 我正在处理本地主分支上的一些错误。（我知道我应该使用不同的分支，但在这种情况下我没有）

2. 提交我为这些错误所做的更改，但仍有其他工作尚未准备好提交

3. 当谈到推动这些错误的修复时，我会做一个隐藏来保存我所有其他的工作，然后从遥控器中提取。（在这个阶段我的假设是我与其他人所做的工作是内联的，并且当前的头部与遥控器是内联的）

4. 然后我应用存储并推送假设只有我提交的更改将被推送

不幸的是，这删除了其他人所做的工作。

所以我的问题是：

1. 如果'stash apply'本质上是一个合并，为什么/如何发生这种情况？'stash apply' 不应该将我的本地更改合并到返回的内容（即其他人的工作）吗？

   2. stash 实际上是存储所有提交的文件还是仅存储已提交的文件？因为如果是这样，我知道我应该做一个变基而不是简单的拉动

下面是相关图表的样子。

这是我们目前遵循的工作流程：

1. 完成一个功能并将其合并到develop分支中
2. 从开发创建一个release分支
3. release在分支上运行构建脚本
4. 创建拉取请求以将release分支合并到master
5. 接受release分支拉取请求并合并
6. master然后可以通过运行 deploy 命令将分支部署到实时服务器

这一切都很好，除了在我的 Git 存储库中，我的分支不同步master现在落后了，develop因为它没有从拉取请求将release分支合并到develop. 但master也领先，develop因为它现在包含来自拉取请求的合并提交，以将release分支放入master

我可以单击 Bit Bucket 中的同步以使所有分支保持最新，但这感觉就像一个奇怪的过程，并且自动保持分支同步会更好。

或者，它们不同步真的不重要吗？

如果您不熟悉，这里是 Git Flow 流程的链接：http: //nvie.com/posts/a-successful-git-branching-model/

谢谢。

我团队的工作流程如下：

• 在任何时候，我们都有不止一个活跃的分支；对于应用程序的两个不同版本（例如，v4对于即将发布的版本，以及v5在遥远的将来发布的版本），开发同时登陆 2 个或更多分支。我们定期合并v4到v5.
• 没有人直接在v4orv5上工作，我们在分支中处理功能分支并创建拉取请求，指向上游v4或v5（使用 Atlassian Stash）

假设我创建了一个新的开发项目。我创建了一个新分支：

git checkout -b SOMETHING_FOR_V4 v4

现在我在SOMETHING_FOR_V4。我提交并推送：

git push -u origin SOMETHING_FOR_V4

我已经设置了远程跟踪分支，-u所以下次我更新某些东西时，我可以git push不指定分支，Git 会知道推送到哪里。

然而时间已经过去了，我想重新定位。

我需要明确告诉git rebase origin/v4

相反，我可以origin/v4在创建分支时设置到我的跟踪分支，但是当我推送时，我必须git push origin SOMETHING_FOR_V4每次都说。

我想要的是让 Git 足够聪明，可以知道在哪个基础上进行变基。如果我只是git rebase在做之后说git push -u，它会走我推送时指定的远程跟踪分支，这不是我想要的。

基本上我想有一个单独的跟踪分支用于git push（我第一次推送的那个）和一个单独的用于git rebase（在我开始[1]的顶部v4或v5从哪个开始）。

有可能得到这种行为吗？

或者，我将使用什么命令来确定自己是否“更接近”v4或v5（我正在考虑在别名中自动获取和重新设置基准）？

[1] 在这种情况下，它可以重新建立在我开始的基础之上，或者说它v4的远程基础origin/v4。假设我可以自己处理保持v4和origin/v4同步。

我们有一位新的初级开发人员加入团队并希望为项目做出贡献。问题是，由于缺乏经验，我们预计会有很多垃圾提交，并且我们需要在开始时对每个提交进行代码审查。

在这种情况下，什么是合适的 git 工作流程？我们不希望他的垃圾历史污染我们的主分支。

我非常了解 GIT 工作流程。我有一个master分支，然后我签出一个develop分支。之后，我检查了一个feature分支。在feature分支上，我编辑了一个文件。当我结帐回到develop分行时。我看到该文件已被编辑。我开始不明白，因为我认为当你对一个分支上的文件做某事时，它不会影响另一个分支上的同一个文件，直到你合并两个分支。develop当我在分支上编辑该文件时，有人可以解释为什么它会影响分支上的同一个文件feature吗？谢谢！

Currently i have a workflow of 2 levels (local<->online), but i would like to have a 3 level workflow by getting a demo server in the middle (local<->demo<->online). I will describe in details how it is set up currently, and what in details i would like to achieve eventually.

What i have now -

• multiple local repositories of the same project (my PC and colluegues PCs)
• online site server (where the site is available to public use, me or other devs from the team may push their ready parts of work from their localhost repositories to here, and pull from here, this is a bare repository added to the local ones over origin master, once pushed up online a hook automatically deploys the pushed changes).

What i would like to have -

• multiple local repositories of the same project (my PC and colluegues PCs)
• demo server where all devs can push and pull from to their local repositories. There should be automatic deployment. Once tested on demo the project should go up online. ( i am in doubt how to incorporate all this part...)
• online bare repository where, we push and pull from the demo server repository. If pushed from demo, it should be auto deployed.

What is the best way to organize this kind of workflow?

我们有这个问题可能由merge工作流引发，因此我们正在考虑使用rebase工作流。

一个问题是rebase远程存储库会导致历史记录的重写。但我认为这可以通过

1. 在要变基的分支上标记一个tag（可以是时间戳的名称）branch_rebaseXXXXXXXXXXXXXXXX
2. 推tag
3. 申请rebase
4. 推

Git 可能会阻止您rebase远程操作，即使您按照上述方法保存历史记录也是如此。除了git push --forcehack，我们可以做

1. branch_new在上面创建一个新分支branch
2. 如上标记一个标签
3. 重新设置新分支
4. 推送新分支和标签
5. 删除旧的本地和远程branch
6. 重命名branch_new为branch
7. 推送分支名称变更

当应用这种方法并且rebase不merge严格从一开始就使用时，虽然生成的提交历史不会是线性的，但由于不会有合并，它将有效地形成一个树状图，其中每个叶节点都是活动节点的尖端分支，或由标签标记。就个人而言，我将这些标签称为“墓碑”。

由于上述方法尚未在实践中使用，这种方法的优缺点是什么？特别是，如果有人检查了一个分支，在它上面工作，然后另一个人在那个分支上标记了一块墓碑，会发生什么？

我目前正在开展一个项目，我们正在迁移到 Git。我们正在尝试找出要使用的工作流程。我们非常热衷于 git-flow，但有一个问题。

据我了解 git-flow，开发人员创建feature分支develop，一旦完成特定feature分支，代码就会合并到develop. 当我们要释放住时，develop再合并到master. 在我们的例子中，develop将是当前部署到我们的开发环境的内容，而master将是当前Live的内容。这一切都很好。

事情

问题是我们需要在Live之前部署另一个环境，即。测试。我们希望有一个test始终代表当前部署到Test的分支。

这就是我们设想的工作方式：

1. 开发人员在feature分支中工作，这些分支合并到develop中，然后部署到Dev。
2. 当我们准备好升级到Test时，develop被合并到testTest中。
3. 一旦在Test中签收所有内容，我们就会合并test到Live中。master

我的问题

1. 这对 git-flow 是否可行，如果可以，如何？
2. 我们甚至应该这样做吗？
3. 还有什么办法可以做到这一点？

据我了解，GIT wokflow 的描述方式如下：http: //nvie.com/posts/a-successful-git-branching-model/

我有一个与此工作流程中的旧分支错误修复有关的问题。

鉴于我们有很多旧版本分支合并到主分支中。我们的上一个版本是 2.6 版。我们需要修复在某个旧版本分支中发现的一些错误，比如 1.5。我们从与 1.5 版相关的主分支状态创建一个分支，修复它，部署它，就可以了。但是现在仍然存在一个问题：我们如何才能将这种更改存储并传播到所有较新的版本？

我们不能只是将此修复合并到主文件中。因为我们正在修复的类可能会在版本 2.3 中被删除，例如。它只是可能在 master 分支的 HEAD 中不存在。

不确定我们是否可以将其合并到 master 的历史记录中。我无法想象它应该如何改变所有的提交。

所以看起来在修补程序之后所有主分支的下一次提交都已过时并且无法使用。如果我们在 1.9 版本中有一些错误，那么我们唯一的选择就是从 master 的 1.9 提交中创建一个分支，以某种方式将它与那个 1.5 修补程序合并，然后继续..

我的理解正确吗？

我有一个客户有一个网站，该网站的设计根据季节（夏季/冬季）切换。所以基本上它是相同的功能，但是模板相关文件的两个版本（css、JS、图像等）我想知道在这种情况下通常的 git 工作流是什么？我想我需要两个分支，每个设计一个，但是如何保持其他文件相同？我需要创建子模块吗？如果没有，当我更改某些内容并且需要将更改提交到两个分支时，如何同时编辑两个分支上的小文件？