What's right way to use Github Workflow .

2014-06-27 10:09:30 +08:00
 song940
公司通过 Github 上的 Private Repo 进行协同工作 ,

那么我作为其中一个 Member , 如何参与 ?

---

直接 Clone 代码, 然后添加新的 Feature (是否需要 Branch ?)之后 Pull & Commit & Push ?

或者.

Fork Repo , 然后在自己的 Repo 上添加 Feature (是否需要 Branch ?) 之后 Pull & Commit & Push 然后做 Pull Request .

亦或者全都不对 ?

各位来说说你们的方式 .
4761 次点击
所在节点    程序员
17 条回复
holy_sin
2014-06-27 10:15:47 +08:00
如果是自己就用第一种吧,团队合作用第二种,粗浅理解
song940
2014-06-27 10:30:37 +08:00
@holy_sin 但是, 我 Fork Repo 后是否就无法跟进公司的 Repo 了(我理解有误?).

那我每次是否都需要做一个 Pull Request, 然后等待 Merge ?
sethverlo
2014-06-27 10:50:19 +08:00
clone 以后开新 branch, commit-push 过去以后也可以开 pull request 的,亲测。
song940
2014-06-27 10:57:21 +08:00
@sethverlo 恩, 但是 Fork 之后的 Repo 就和公司的 Repo 分开了 , 如何继续跟进公司的 Repo ?
mengzhuo
2014-06-27 10:59:30 +08:00
git remote add upstream
git rebase --pull upstream
@song940
sethverlo
2014-06-27 11:00:02 +08:00
@song940 我说的是 clone 不是 fork…再看一遍亲…
yangqi
2014-06-27 11:02:01 +08:00
dongbeta
2014-06-27 11:02:21 +08:00
new branch -> commits -> push -> new pull request -> code review -> merge
66450146
2014-06-27 11:04:49 +08:00
如果你们有 code review,那就用第二种
song940
2014-06-27 11:09:37 +08:00
@dongbeta
@sethverlo sorry.

我目前是

new branch `dev`
add new feature
commit
merge to master
remove branch `dev`
push
sethverlo
2014-06-27 11:11:57 +08:00
@song940 8 楼 @dongbeta 的方法就是我说的,我觉得是 best practice.
song940
2014-06-27 11:14:10 +08:00
@mengzhuo fetch 和 pull 获取 upstream 代码我能理解 , rebase 如何理解 .
song940
2014-06-27 11:16:02 +08:00
@sethverlo OK. 感谢, 我也觉得这应该就是了 .
wesley
2014-06-27 11:21:02 +08:00
1 接到任务: fork a new branch
2 每天从master brach merge 到自己的branch
3 任务完成: merge 回 master branch
4 测试通过: close branch
bsbgong
2014-06-27 14:46:43 +08:00
你们应该由自己定一个github流程。 github用法有很多种,没有一个绝对的最优workflow,得看项目性质和工作方法,自己的队伍是怎么用的。
给一个我们现在用的workflow(不使用fork)。
假定你已经git clone了,每次接到任务之后:
1. git checkout master && git pull
2. git checkout -b feature_branch
3. git push origin feature_branch
4. git branch --set-upstream origin/feature_branch
5. // do your work, create some commits
6. git checkout master && git pull && git checkout feature_branch && git merge
7. git rebase -i (编辑即将Push的commit记录)
8. git push origin feature_branch
然后上github,打开你的branch,compare&&Pull Request
然后号召大家来review, 有comment的话你就修改再提交
直到大家确认没问题了,由某人来git merge feature_branch
最后删除的你branch
dongbeta
2014-06-27 15:09:11 +08:00
@song940 我们在当 feature 分支需要 dev 最新的代码的时候才会进行rebase。

我们是用 JIRA + STASH + CI 自动完成这个工作流的。而且在 merge 之前,CI 会帮我们测试每一个分支,如果测试不过去,是不允许 merge 的。
finian
2014-06-27 16:05:49 +08:00
现在用得比较多的应该是Vincent Driessen的git workflow模型吧。
下面这两篇文章解释得比较直观:
http://danielkummer.github.io/git-flow-cheatsheet/
https://www.atlassian.com/git/workflows#!workflow-gitflow

简单来说,就是设置两个主分支master和develop,还有feature, release, hotfix等辅助分支。

master上的每个commit点都是可部署的,对应产品的每个发布版本。开发在develop分支上进行。每开发一个新功能或者bug修复,就从develop上开个feature分支,开发完成验证通过后merge回develop。发布新版本时,从develop开个release分支,完成后merge回develop和master(中间还有类似打tag, dump版本等工作,可以通过脚本完成)。修复已发布版本的bug就从master拉个hotfix分支,修复完验证通过后merge回master(创建hotfix版本)和develop分支。

具体来说,以自部署的gitlab、开发某个版本的新功能为例:
0. git clone工程
1. 从develop拉功能分支:git checkout -b feature/xxx develop
2. 开发功能、commit,中途若要保持与develop代码同步,则可以merge或rebase
3. 开发完成经过验证后将功能分支push到gitlab:git push origin feature/xxx
4. 到gitlab网页上面发起merge request
5. 等待code review审核后功能分支被merge进develop
6. 删除功能分支:git branch -d feature/xxx

可以使用git-flow插件或SourceTree简化和统一开发流程。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/119778

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX