What's right way to use Github Workflow .

如果是自己就用第一种吧，团队合作用第二种，粗浅理解

@holy_sin 但是, 我 Fork Repo 后是否就无法跟进公司的 Repo 了(我理解有误?).

那我每次是否都需要做一个 Pull Request, 然后等待 Merge ?

clone 以后开新 branch, commit-push 过去以后也可以开 pull request 的，亲测。

@sethverlo 恩, 但是 Fork 之后的 Repo 就和公司的 Repo 分开了 , 如何继续跟进公司的 Repo ?

git remote add upstream
git rebase --pull upstream
@song940

@song940 我说的是 clone 不是 fork…再看一遍亲…

@song940

git fetch upstream
然后merge

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

new branch -> commits -> push -> new pull request -> code review -> merge

如果你们有 code review，那就用第二种

@dongbeta
@sethverlo sorry.

我目前是

new branch `dev`
add new feature
commit
merge to master
remove branch `dev`
push

@song940 8 楼 @dongbeta 的方法就是我说的，我觉得是 best practice.

@mengzhuo fetch 和 pull 获取 upstream 代码我能理解 , rebase 如何理解 .

@sethverlo OK. 感谢, 我也觉得这应该就是了 .

1 接到任务： fork a new branch
2 每天从master brach merge 到自己的branch
3 任务完成： merge 回 master branch
4 测试通过： close branch

你们应该由自己定一个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

@song940 我们在当 feature 分支需要 dev 最新的代码的时候才会进行rebase。

我们是用 JIRA + STASH + CI 自动完成这个工作流的。而且在 merge 之前，CI 会帮我们测试每一个分支，如果测试不过去，是不允许 merge 的。

现在用得比较多的应该是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简化和统一开发流程。