Git的基礎使用

時間  2019-11-30
標籤 git 基礎 使用 欄目 Git 简体版
原文   原文鏈接

Git的基礎使用

1. git初始化

  • 下載git：地址是 git
  • 安裝完成後，在github或者gitlab上覆制http的clone連接，打開Git Bash\

git clone http://xxxx.gitjava

  • 這樣會在本地建立一個以項目名命名的文件夾，clone結束後就能夠看到咱們拉下來的項目了。git

  • 作完 這些之後，還有很重要的一步，就是給你的git添加用戶名和郵箱github

git config --global user.name [username] git config --global user.email [email]框架

  • 若是隻是在咱們公司本身的gitlab上使用git，這些已經夠了，可是在github上使用git的時候，咱們還須要獲取咱們的密鑰，而且保存在github上就能夠了

$ ssh-keygen -t rsa -C "email"ssh

將生成的ssh-key添加到你的github中吧。工具

2. git操做

  • 拉取操做

git pull origin master 拉取主倉庫的origin分支代碼gitlab

  • 合併操做

當你在dev分支想要合併master的代碼，你能夠git merge origin master 若是有衝突的話，命令行會給出提示，按照提示操做，保留或者刪除代碼就能夠了，以後重複提交操做。性能

  • 提交操做

git add . / git add filename 添加你須要提交的文件， .表示全部更改的文件 git commit -m 'any' 添加註釋，跟代碼的註釋同樣，很重要，具體的規範請看下一節git pull origin master在提交前，記得拉取更新，否則可能會報錯，或者覆蓋掉你的代碼git push origin master` 最後一步，提交代碼單元測試

  • 新建倉庫和分支 有時候，咱們clone了項目後，已經有倉庫地址，不須要新建了，可是有時候，咱們還須要新建倉庫，好比下面的操做。

首先，你要清楚倉庫的地址 而後git remote add <name> <url> ，起一個本身喜歡的名字和倉庫地址，這樣一個本地倉庫就建立成功了測試

3. pull request

pull request 是一種主要用於大型項目的提交方法， 在給開源框架貢獻代碼時，必需要用到這個，下面咱們簡稱pr。

  1. 首先咱們要在源項目中，fork這個項目，生成一個屬於你本身的代碼倉庫
  2. 在本地的文件中，pull項目地址，建立本地文件庫。
  3. 此時你能夠修改這個項目，並提交到你本身的倉庫中，可是這個不是咱們最終的需求，咱們要提交到源框架中，這時，咱們須要提交pr
  4. 在git上，建立一個合併請求，操做的話，都有步驟，咱們這裏不贅述。下面主要說一下如何去更新你本地的項目和源項目同步。由於源項目可能會有不少人員參與。
  5. 在本地git倉庫中，添加一個新的地址，地址是源項目地址。
  6. 在每次提交pr以前，你須要先更新本地代碼，合併源項目分支。
  7. git merge 倉庫名 分支 這裏的倉庫和分支是你須要合併的源碼倉庫分支，新建倉庫的方法在以前已經有介紹了

4. Git提交規範

4.1 Git commit日誌基本規範

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
複製代碼

4.2 對格式的說明以下：

  • type表明某次提交的類型，好比是修復一個bug仍是增長一個新的feature。全部的type類型以下：
  • feat： 新增feature
  • fix: 修復bug
  • docs: 僅僅修改了文檔，好比README, CHANGELOG, CONTRIBUTE等等
  • style: 僅僅修改了空格、格式縮進、都好等等，不改變代碼邏輯
  • refactor: 代碼重構，沒有加新功能或者修復bug
  • perf: 優化相關，好比提高性能、體驗
  • test: 測試用例，包括單元測試、集成測試等
  • chore: 改變構建流程、或者增長依賴庫、工具等
  • revert: 回滾到上一個版本

4.3 格式要求：

  • 標題行：50個字符之內，描述主要變動內容
  • 主體內容：更詳細的說明文本，建議72個字符之內。 須要描述的信息包括:
  • 爲何這個變動是必須的? 它多是用來修復一個bug，增長一個feature，提高性能、可靠性、穩定性等等
  • 他如何解決這個問題? 具體描述解決問題的步驟
  • 是否存在反作用、風險?
  • 尾部：若是須要的化能夠添加一個連接到issue地址或者其它文檔，或者關閉某個issue。

4.4 Git分支與版本發佈規範

  • 基本原則：master爲保護分支，不直接在master上進行代碼修改和提交。

  • 開發平常需求或者項目時，從master分支上checkout一個feature分支進行開發或者bugfix分支進行bug修復，功能測試完畢而且項目發佈上線後，將feature分支合併到主幹master，而且打Tag發佈，最後刪除開發分支。分支命名規範:

    • 分支版本命名規則：分支類型 分支發佈時間 分支功能。好比：feature_20170401_fairy_flower
    • 分支類型包括：feature、 bugfix、refactor三種類型，即新功能開發、bug修復和代碼重構
    • 時間使用年月日進行命名，不足2位補0
    • 分支功能命名使用snake case命名法，即下劃線命名。

  • Tag包括3位版本，前綴使用v。好比v1.2.31。Tag命名規範：

    • 新功能開發使用第2位版本號，bug修復使用第3位版本號
    • 核心基礎庫或者Node中間價能夠在大版本發佈請使用灰度版本號，在版本後面加上後綴，用中劃線分隔。alpha或者belta後面加上次數，即第幾回alpha：
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程