让知识连接你我
投稿赚钱
当前位置: 首页 > 工具资源 > 开发人员工作中大概的Git操作流程-代码管理篇
  • 101
  • 微信分享

    扫一扫,在手机上查看

开发人员工作中大概的Git操作流程-代码管理篇

2019.09.18 10:00 253 浏览 举报

  代码管理Git

  有关Git Workflow的探讨许多,最有名的应属Vincent Driessen的那篇博客A successful Git branching model。Vincent的工作流的构造挺不错,首要有2个关键分支,master 和 develop,各自是主分支和开发设计分支。随后也有3类次分支,他们将会数量许多,而且不容易好长时间具有,各自是开发新作用用的feature,发表用的release和修复bug用的hotfix。大概的Git操作流程能够掌握为那样:

# create branch
git checkout -b develop master
git checkout -b feature develop
# commit something
git add widget.js
git commit -m "add a function"
# merge to develop
git checkout develop
git merge --no-ff feature
# delete branch
git branch -d feature

  首要构建开发设计分支 develop ,随后再从开发设计分支构建一个次分支,紧接着递交源代码并注解递交,并入会开发设计分支 develop ,最终删去这些暂时的次分支。--no-ff的含义是不操作流程迅速并入。其余开发设计步骤中都是不尽相同,release分支也有hotfix分支将会需要在核实一切正常时并入到develop和master两个分支中随后删去。

  但是这些工作流是充分考虑团队开发设计而布置的,很规范简洁,但细致缺乏。而Benjamin Sandofsky的稿子Understanding the Git Workflow则变得趋近对commit的管控,或许不可算做工作流,必须可算一种观念。他注重一定要留存还有一个私人的分支只具有于当地,随后在并入到主分支时清除本来的commit log。这边会运用一个 merge 命令的参数 --squash 那样并入后不容易带给任何commit log。

  # create brach
  git checkout -b private master
  # commit something
  git add widget.js
  git commit -m "add a function"
  # merge brach but don't commit
  git checkout master
  git merge --squash private
  # commit once
  git commit -m "only this commit"

  但我觉得Git工作流和其余所有工程步骤一样,找不到银弹。但是这类并入的方法能够变成一种不错的操作流程流来进行归属于任何人自身的工作流。此外从这二种差异特点的Git工作流中或许能选出一些有意思的点。以下就是我的观点:

  •   主分支数由开发设计步骤复杂度决策,而开发设计步骤复杂度应当由项目主管依据项目规模确认,因此项目规模决策了主分支数,除去develop或许还需要test、build这些。

  •   次分支数由人员和具体情况决策,bug数会决策hotfix的数量,或许产品经理会决策feature的数量,多个差异版本的同行业也将会会增加release的数量。假如项目规模充足大时,几个小组彻底解决一个难题时也会产生多个暂时分支。

  •   多人合作及其好长时间开发设计都将会导致日志错乱没法管控,操作流程squash参数协助暂时分支能够清理对旁人不必的commit信息。

  •   应使用--no-ff可以避免快速合并,使每次合并等于一次提交,记录在log中,保持分支健康。

  因此,在实际开发的工作流中应该按照实际情况创建分支,但应按照以上规范合并分支。

  Github

  Github不止是每个Coder的FaceBook,还是一个非常棒的远程Git仓库,有很多小组将正式项目托管在上面。其实Github上和Git没有太多差别,只是多了一个远程仓库Remote的操作,另外相信每个初入Github的新手都为私钥公钥头疼了好久,下文将会讨论Github的仓库创建和日常操作两部分。

  首先需要在本地建立与Github帐户的联系,在shell中安装SSH,然后像这样使用SSH安装SSH密钥(帮助文档):

  ssh-keygen -t rsa -C "your_email@example.com"
  # Creates a new ssh key, using the provided email as a label
  # Generating public/private rsa key pair.
  # Enter file in which to save the key (/c/Users/you/.ssh/id_rsa): [Press enter]
  ssh-add id_rsa

  然后会让你输入一个密码,随意输入就可以了,接着就会生成一个公钥一个私钥。在用户文件夹下的 .ssh 文件夹中找到id_rsa.pub,这个文件里就是公钥,复制里面的内容,然后在Github的Account Settings中的SSH Key页面,点击Add SSH Key按钮,输入一个用于说明的title,接着粘贴公钥到Key中就可以了。

  然后必须在Github上点击 Create a new repo 按钮来创建一个空项目。当然如果选择适当的选项就可以自动生成README文件、Git忽略文件和版权分享声明文件。之后该项目会有一个仓库的地址,可以使用HTTPS和SSH,甚至还有SVN地址:

  https://github.com/<username>/<reponame>.git
  git@github.com:<username>/<reponame>.git
  https://github.com/<username>/<reponame>

  以我的一个对话框jQ插件为例,首先在项目中初始化git,然后添加一个远程仓库,然后就可以往上面提交代码了。

  git remote add myGithub https://github.com/tychio/dialog.git
  git push myGithub master

  因为我使用的HTTPS方式提交,之后会需要输入用户名和密码,如果使用SSH方式则使用公钥然后会在链接时使用生成密钥时的密码。使用HTTPS纯属为了记住Github的密码,每天都在敲就不会忘记了。

  总结

  工作流应该是一个人最习惯和熟悉的流程,而不应该是照猫画虎,邯郸学步。还是那句话,不存在银弹,所以不会有万用的工作流,只能从中汲取有用的实践,完善改进自己的工作流,达到提高工作效率的目的。

  和学习其他技术一样,应用于工作流之中的工具有无数种,但真正需要和适合的只有自己知道,发现问题,带着问题寻找工具才能真的改进工作流。如果仅仅为了使用前沿的工具而使用,只会使自己的工作效率大打折扣。记得两年前我还在疯狂的复制代码,每当我意识到不能再这样下去的时候,工作流就会自己进化,合适的工具近在眼前,工作效率逐渐提升。我发现问题实在是很好的老师,可以让一个人快速的成长,解决它就可以获得一次提升。

  永远有人有跟你相同的问题,永远有能解决你当前问题的工具,善于使用问题来选择它们就能打造更完善的工作流。如果遇到没有工具能解决的问题,那说明造轮子的时机到了。

  我的前端开发工作流 系列文章:

  •   环境篇

  •   自动化篇

  •   工具篇

  •   代码管理篇


本文首次发布于开创者素材 ,转载请注明出处,谢谢合作!

相关文章推荐