What's right way to use Github Workflow .

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 3834 天前的主题，其中的信息可能已经有所发展或是发生改变。

公司通过 Github 上的 Private Repo 进行协同工作 ,

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

---

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

或者.

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

亦或者全都不对 ?

各位来说说你们的方式 .

GitHub

repo

branch

17 条回复 • 2014-06-27 16:05:49 +08:00

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

@song940

git fetch upstream
然后merge

https://help.github.com/articles/syncing-a-fork

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简化和统一开发流程。