How are you structuring your Git repository workflow?

╄→尐↘猪︶ㄣ 提交于 2019-11-30 13:40:41

I like the way the Yahoo! User Interface (YUI) team appears to be working. I am not at Yahoo, nor am I on that team, but their git commit logs reveal a lot about their process.

The YUI team maintains a central repository where everyone on the team has commit access. Periodically after commits to this repository (it might be after every push, but I don't think so), the build system fires, rebuilds YUI and pushes a newly tagged commit to github, where the community can fork the code and work on it.

I am in favor of the central repository that represents the "official" status of the project. Certainly, if I want to share code with a co-worker, I can arrange for them to pull a branch from me, and we can collaborate that way.

The "master" repository offers other advantages as well, such as ease of continuous integration, as the push/pull triggers can be configured on the 'master' repository to fire off the unit tests and build system. It also ensures that everyone knows where the most recent 'known good' version of the repository is, so that if the project needs to be built, published, or tested, there can be reasonable assurances that the 'master' repository is ready for that.

Git will support almost any workflow you can think of, but even among a small team, you don't want there to be a question about where the 'official' repository is. The maintenance nightmare that could lead to, particularly as you approach a release, would be unpleasant.

take a look at nice blog http://nvie.com/git-model and comments

Take a look at a workflow github team uses:

http://scottchacon.com/2011/08/31/github-flow.html

It requires using github, but also is pretty straightforward and clean.

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!