Git使用

分布式工作流程

  • 集中式工作流——————–单点协作

    • 两个开发者从中心仓库克隆代码下来，同时作了一些修改，只有第一个开发者可以顺利地把数据推送回共享服务器。第二个开发者在推送修改之前，必须先将第一个人的工作合并进来，这样才不会覆盖第一个人的修改

  • 集成管理工作流

    1. 项目维护者推送到主仓库。
    2. 贡献者克隆此仓库，做出修改。
    3. 贡献者将数据推送到自己的公开仓库。
    4. 贡献者给维护者发送邮件，请求拉取自己的更新。
    5. 维护者在自己本地的仓库中，将贡献者的仓库加为远程仓库并合并修改。
    6. 维护者将合并后的修改推送到主仓库。

  • 司令官与副官工作流——-大型软件：Linux

    1. 普通开发者在自己的特性分支上工作，并根据 master 分支进行变基。 这里是司令官的master分支。

    2. 副官将普通开发者的特性分支合并到自己的 master 分支中。

    3. 司令官将所有副官的 master 分支并入自己的 master 分支中。

    4. 司令官将集成后的 master 分支推送到参考仓库中，以便所有其他开发者以此为基础进行变基。

向项目贡献

  • 影响因素 ： 活跃贡献者的数量，项目的工作流程，提交权限

  • 提交准则

    • git diff --check，它将会找到可能的空白错误并将它们为你列出来
      • 空白错误是指行尾的空格、Tab 制表符，和行首空格后跟 Tab 制表符的行为
    • 每一个提交成为一个逻辑上的独立变更集
      • 不要一次提交解决好多问题
      • 每个提交写清楚，让你的同事工作容易些
    • 有一个优秀的提交信息

  • 私有小团队

    • 私有 ： 只有这几个开发者有仓库的推送权限
    • 主采用SVN
      • 区别：合并发生在客户端这边而不是在提交时发生在服务器那边
    • 工作流程：
      • 你通常在一个特性分支工作一会儿，当它准备好整合时合并回你的 master 分支。 当想要共享工作时，将其合并回你自己的 master 分支，如果有他人改动的话然后抓取并合并 origin/master，最终推送到服务器上的 master 分支

  • 私有管理团队

    • 公司使用了一种整合-管理者工作流程，独立小组的工作只能被特定的工程师整合，主仓库的 master 分支只能被那些工程师更新

    • 所有的工作都是在基于团队的分支上完成的并且稍后会被整合者拉到一起

    • 新建一个分支，与他人一起工作，可以加-u

      • 也要注意 -u 标记；这是 --set-upstream 的简写，该标记会为之后轻松地推送与拉取配置分支

      • $ git push -u origin featureA

  • 公开项目

    • 当你的分支工作完成后准备将其贡献回维护者，去原始项目中然后点击 Fork 按钮，创建一份自己的可写的项目派生仓库。 然后需要添加这个新仓库 URL 为第二个远程仓库，在本例中称作 myfork

      $ git remote add myfork (url)

    • 然后需要推送工作到上面。 相对于合并到主分支再推送上去，推送你正在工作的特性分支到仓库上更简单。 原因是工作如果不被接受或者是被拣选的，就不必回退你的 master 分支

      $ git push -u myfork featureA

    • 当工作已经被推送到你的派生后，你需要通知维护者

      • request-pull 命令接受特性分支拉入的基础分支，以及它们拉入的 Git 仓库 URL，输出请求拉入的所有修改的总结

        $ git request-pull origin/master myfork

还有很多，太复杂看的人难受，之后学习