V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
song940
V2EX  ›  程序员

What's right way to use Github Workflow .

  •  
  •   song940 ·
    song940 · 2014-06-27 10:09:30 +08:00 · 4554 次点击
    这是一个创建于 3562 天前的主题,其中的信息可能已经有所发展或是发生改变。
    公司通过 Github 上的 Private Repo 进行协同工作 ,

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

    ---

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

    或者.

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

    亦或者全都不对 ?

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

    那我每次是否都需要做一个 Pull Request, 然后等待 Merge ?
    sethverlo
        3
    sethverlo  
       2014-06-27 10:50:19 +08:00   ❤️ 1
    clone 以后开新 branch, commit-push 过去以后也可以开 pull request 的,亲测。
    song940
        4
    song940  
    OP
       2014-06-27 10:57:21 +08:00
    @sethverlo 恩, 但是 Fork 之后的 Repo 就和公司的 Repo 分开了 , 如何继续跟进公司的 Repo ?
    mengzhuo
        5
    mengzhuo  
       2014-06-27 10:59:30 +08:00   ❤️ 1
    git remote add upstream
    git rebase --pull upstream
    @song940
    sethverlo
        6
    sethverlo  
       2014-06-27 11:00:02 +08:00
    @song940 我说的是 clone 不是 fork…再看一遍亲…
    yangqi
        7
    yangqi  
       2014-06-27 11:02:01 +08:00   ❤️ 1
    dongbeta
        8
    dongbeta  
       2014-06-27 11:02:21 +08:00   ❤️ 2
    new branch -> commits -> push -> new pull request -> code review -> merge
    66450146
        9
    66450146  
       2014-06-27 11:04:49 +08:00
    如果你们有 code review,那就用第二种
    song940
        10
    song940  
    OP
       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
        11
    sethverlo  
       2014-06-27 11:11:57 +08:00   ❤️ 1
    @song940 8 楼 @dongbeta 的方法就是我说的,我觉得是 best practice.
    song940
        12
    song940  
    OP
       2014-06-27 11:14:10 +08:00
    @mengzhuo fetch 和 pull 获取 upstream 代码我能理解 , rebase 如何理解 .
    song940
        13
    song940  
    OP
       2014-06-27 11:16:02 +08:00
    @sethverlo OK. 感谢, 我也觉得这应该就是了 .
    wesley
        14
    wesley  
       2014-06-27 11:21:02 +08:00   ❤️ 1
    1 接到任务: fork a new branch
    2 每天从master brach merge 到自己的branch
    3 任务完成: merge 回 master branch
    4 测试通过: close branch
    bsbgong
        15
    bsbgong  
       2014-06-27 14:46:43 +08:00   ❤️ 1
    你们应该由自己定一个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
        16
    dongbeta  
       2014-06-27 15:09:11 +08:00   ❤️ 1
    @song940 我们在当 feature 分支需要 dev 最新的代码的时候才会进行rebase。

    我们是用 JIRA + STASH + CI 自动完成这个工作流的。而且在 merge 之前,CI 会帮我们测试每一个分支,如果测试不过去,是不允许 merge 的。
    finian
        17
    finian  
       2014-06-27 16:05:49 +08:00   ❤️ 2
    现在用得比较多的应该是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简化和统一开发流程。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5291 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 09:32 · PVG 17:32 · LAX 02:32 · JFK 05:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.