使用 Git 和 Git 的最佳工作流程吉图布
我正在寻找一些关于如何使用 Git 和 Git 为我的团队正确构建工作流程的建议。 GitHub。
我们是最近的 svn 转换者,对于如何最好地设置我们的日常工作流程有点困惑。
这里有一些背景知识:我对命令行很满意,我的团队对它还很陌生,但可以遵循使用命令。我们都在 3 个环境(开发、登台和生产)的同一个项目上工作。我们是开发人员和开发人员的混合体。设计人员因此有些使用 git GUI,有些使用 CLI。
我们在 svn 中的设置是这样的:
- 我们有一个用于开发、登台和生产的分支。
- 当人们对代码充满信心时,他们会提交代码,然后将其合并到暂存中。
- 服务器会自行更新,在发布日(每周)我们会进行比较并将更改推送到生产服务器。
现在我设置了这些分支并让服务器运行该进程,但实际的工作流程让我感到困惑。
每次有人对文件进行更改时,他们都会创建一个新分支、提交、合并和删除该分支,这似乎有点矫枉过正。根据我所读到的内容,他们将能够在特定提交上执行此操作(使用哈希),我这样做对吗?这是使用 Git 处理事情的可接受方式吗?
任何建议将不胜感激。
I'm looking for some advice on how to properly structure the workflow for my team with Git & GitHub.
We are recent svn converts and it's kind of confusing how we should best set up our day-to-day workflow.
Here is a little background: I'm comfortable with command line and my team is pretty new to it but can follow use commands. We all are working on the same project with 3 environments (development, staging, and production). We are a mix of developers & designers so some use the git GUI and some the CLI.
Our setup in svn went something like this:
- We had a branch for development, staging and production.
- When people were confident with code they would commit and then merge it into the staging.
- The server would update itself and on a release day (weekly) we would do a diff and push the changes to the production server.
Now I set up those branches and got the process with the server running but its the actual workflow that is confusing the hell out of me.
It seems like overkill that every time someone makes a change on a file they would create a new branch, commit, merge, and delete that branch. From what I have read they would be able to do it on a specific commit (using the hash), do I have that right? Is this an acceptable way to go about things with Git?
Any advice would be greatly appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
您可以从 svn 逐字复制您的工作流程。 Git 可以做 svn 能做的一切(但它能做的还不止这些!)。但尽管使用了 CVS,您的工作流程仍然可以得到改进。
如果你想在你描述的工作流程中保持最少的分支数量(如果你是 git 的新手,实际上会简化事情),我建议每个开发人员拥有(而不是一个开发分支)三个分支: devel-john、devel-mary 等:
这很方便:所有开发更改都将被推送到中央存储库(即使对于 git 来说这通常也是一件好事),而不会发生冲突,并且任何愿意/有义务进行合并的人都可以随时进行合并(例如进入 staging 分支)。
You can copy your workflow from svn verbatim. Git can do everything svn can (but it can do more than that!). But your workflow could be improved in spite of CVS used.
If you want to keep number of branches minimal (which in case you're new to git would in fact simplify things) in the workflow you have described I'd suggest to have (instead of one development branch) three per-developer branches: devel-john, devel-mary, etc:
This is convenient: all development changes would be pushed to central repository (which is often a good thing even for git) without conflicts and merged anytime by anyone who's willing/obliged to do the merging (for example into the staging branch).
使用 DVCS 时要记住的想法是:
分发:即使您有一个中央 GitHub,开发人员也不限于仅发布(推送)到 /em> GitHub 存储库。他们可以分叉存储库并发布在他们自己的版本中(同时从官方中央 GitHub 存储库获取 - 称为“上游”)。
优点是他们可以根据需要多次重写历史记录(
reset
、rebase --onto
、rebase -i
...) ,最后,他们将发出拉取请求,允许集成商管理他们的更改。出版物之一:在您自己的本地repo,您可以根据需要设置任意数量的分支(当然,不是为每个文件修改设置一个分支,而是为您需要开发的任何新任务或一组任务设置一个分支)。
但您也可以设置将被推送(“发布”)到远程存储库的公共分支。
请参阅 Git 工作流程 上的问题,以及 JC Hamano 有关远程分支的文章:
o 远程分支的乐趣 (1)
o 远程分支的乐趣 (2)
“当人们对代码有信心时,他们会提交,然后将其合并到暂存阶段”这句话不应该应用于 DVCS:尽早提交,经常提交,但仅在需要时推送(“发布”)。
The ideas to keep in mind when working with a DVCS are:
distribution: even if you have one central GitHub, the developper are not limited to publish (push) only to that GitHub repo. They can fork the repo and publish in their own version (while fetching from the official central GitHub repo -- called "upstream").
The advantage is they can rewrite history (
reset
,rebase --onto
,rebase -i
, ...) as many times as they want, in the end, they will make a pull request, allowing an integrator to manage their changes.one of publication: in your own local repo, you can setup as many branches as you want (not one for every file modification, of course, but one for any new task or set of tasks you need to develop).
But you can also set public branches that will be pushed ("published") to your remote repo.
See this question on Git workflow, and also JC Hamano's articles on remote branches:
o Fun with remote branches (1)
o Fun with remote branches (2)
The phrase "When people were confident with code they would commit and then merge it into the staging" should not apply with a DVCS: commit early, commit often, but push ("publish") only when you want.
关于 GitHub 工作流程的精彩帖子,由 GitHub 创建者 Scott Chacon 和上述文章的作者撰写Pro Git 书籍 :P
Great post on GitHub Workflow by one GitHub creators Scott Chacon and author of mentioned Pro Git book :P
ProGit 书籍中还描述了一些项目工作流程,显示了开发人员将使用的 Git 命令用于每日关注。
http://nvie.com/git-model 描述了一个备受推崇的 Git 分支模型
There are also some project workflows described in the ProGit book that show the Git commands developers will use to follow daily.
There is a well regarded Git branching model described at http://nvie.com/git-model
根据您的工作流程,您可以在中央存储库(即 github 上)上有一些“重要”分支,人们可以在本地克隆这些分支。这些对应于“稳定”、“测试版”、“开发”等。关于可能的分支集的一篇不错的文章是 这个。
完成后,您可以让人们使用自己的策略。我更喜欢为主要项目保留主题分支,并为我需要做的快速事情设置一个名为“快速修复”的分支。如果您有一个团队正在开发一个主要项目,他们希望将其保留在与主存储库隔离的单独分支上,那么您可以让他们在没有任何干预的情况下完成该项目。如果人们喜欢有很多小树枝来尝试等,他们也可以这样做。
至于自动测试并从暂存集成到生产中,您可以配置 git hooks 来执行此操作,也可以运行一个系统来定期为您执行此操作并报告问题。
Depending on your workflow, you can have a few 'important' branches on your central repository (ie. on github) which people can clone locally. These would correspond to 'stable', 'beta', 'development' etc. A nice article on a possible set of branches is this.
Once that's done, you can let people use their own strategy. I prefer to keep topic branches for major projects and have one called 'quick-fixes' for quick things I need to do. If you have a team working on a major project which they want to keep on a separate branch cut off from the main repo, you can let them do it without any intervention. If people prefer having lots of tiny branches to try things out etc, they can do that too.
As for automatically testing and integrating into production from staging, you can either configure the git hooks to do that or have a system running that will do it for you at regular intervals and report issues.