下载文档原格式
git message 语法全文共四篇示例，供读者参考第一篇示例：Git是目前最流行的分布式版本控制系统之一，为了更好的管理代码版本，保证团队协作的顺畅，Git 提供了强大的命令行工具和一套规范的语法。
在Git的使用过程中，git message 语法是至关重要的一部分，它主要用于规范提交信息的格式，方便他人阅读和理解代码变更的目的和内容。
下面我们将详细介绍Git message语法的规范和最佳实践。
### Git message 的基本格式Git message 通常分为三个部分：标题、内容和注释。
标题通常为单行文字，用于简洁明了地描述代码变更的目的，内容为多行文字，详细描述代码变更的具体内容，而注释则提供了更多的信息和上下文，比如相关的issue 编号、提交者信息等。
### 标题提交信息的标题应该简洁明了，一般不超过50 个字符。
标题的格式可以采用以下几种规范方式：- 动词开头：比如Add、Fix、Update、Remove 等- 使用第一人称：比如I add、I fix 等- 描述变更目的：比如Add feature A、Fix bug B 等### 内容提交信息的内容应该清晰详细，可以包含代码变更的原因、具体内容、影响范围等信息。
内容通常应该空一行，然后开始描述具体内容，每行文本应该不超过72 个字符，以便于在终端窗口中正确显示。
### 注释提交信息的注释是可选的，用于提供更多的信息和上下文。
注释通常应该以# 号开头，可以包含相关的issue 编号、提交者信息、参考文档等信息。
### 示例下面是一个符合Git message 语法规范的提交信息示例：```Add feature A- 在页面上添加了一个新的按钮- 修复了一个点击事件的bug- 关联了issue #123- 提交者：JohnSmith<****************>```### 最佳实践为了更好的遵守Git message语法规范，以下是一些最佳实践建议：- 提交信息应该清晰明了，描述变更的目的和内容- 标题应该简洁准确，不要包含无关内容- 内容应该详细全面，避免模棱两可的描述- 注释应该提供额外的信息和上下文，帮助他人理解代码变更的原因和环境Git message 语法的规范是为了更好地记录和管理代码变更历史，方便团队协作和版本控制。
Git命令详解及常⽤命令整理Git 命令详解及常⽤命令Git作为常⽤的版本控制⼯具，多了解⼀些命令，将能省去很多时间，下⾯这张图是⽐较好的⼀张，贴出了看⼀下：关于git，⾸先需要了解⼏个名词，如下：Workspace //⼯作区Index / Stage //暂存区Repository //仓库区（或本地仓库）Remote //远程仓⼀、新建代码库// 在当前⽬录新建⼀个Git代码库$ git init// 新建⼀个⽬录，将其初始化为Git代码库$ git init [project-name]// 下载⼀个项⽬和它的整个代码历史$ git clone [url]⼆、配置Git的设置⽂件为.gitconfig，它可以在⽤户主⽬录下（全局配置），也可以在项⽬⽬录下（项⽬配置）。
// 显⽰当前的Git配置$ git config --list// 编辑Git配置⽂件$ git config -e [--global]// 设置提交代码时的⽤户信息$ git config [--global] "[name]"$ git config [--global] user.email "[email address]"三、增加/删除⽂件// 添加指定⽂件到暂存区$ git add [file1] [file2] ...// 添加指定⽬录到暂存区，包括⼦⽬录$ git add [dir]// 添加当前⽬录的所有⽂件到暂存区$ git add .// 添加每个变化前，都会要求确认// 对于同⼀个⽂件的多处变化，可以实现分次提交$ git add -p// 删除⼯作区⽂件，并且将这次删除放⼊暂存区$ git rm [file1] [file2]// 停⽌追踪指定⽂件，但该⽂件会保留在⼯作区$ git rm --cached [file]// 改名⽂件，并且将这个改名放⼊暂存区$ git mv [file-original] [file-renamed]四、代码提交// 提交暂存区到仓库区$ git commit -m [message]// 提交暂存区的指定⽂件到仓库区$ git commit [file1] [file2] ... -m [message]// 提交⼯作区⾃上次commit之后的变化，直接到仓库区$ git commit -a// 提交时显⽰所有diff信息$ git commit -v// 使⽤⼀次新的commit，替代上⼀次提交// 如果代码没有任何新变化，则⽤来改写上⼀次commit的提交信息$ git commit --amend -m [message]// 重做上⼀次commit，并包括指定⽂件的新变化$ git commit --amend [file1] [file2]五、分⽀// 列出所有本地分⽀$ git branch// 列出所有远程分⽀$ git branch -r// 列出所有本地分⽀和远程分⽀$ git branch -a// 新建⼀个分⽀，但依然停留在当前分⽀$ git branch [branch-name]// 新建⼀个分⽀，并切换到该分⽀$ git checkout -b [branch]// 新建⼀个分⽀，指向指定commit$ git branch [branch] [commit]// 新建⼀个分⽀，与指定的远程分⽀建⽴追踪关系$ git branch --track [branch] [remote-branch]// 切换到指定分⽀，并更新⼯作区$ git checkout [branch-name]// 切换到上⼀个分⽀$ git checkout -// 建⽴追踪关系，在现有分⽀与指定的远程分⽀之间$ git branch --set-upstream [branch] [remote-branch]// 合并指定分⽀到当前分⽀$ git merge [branch]// 选择⼀个commit，合并进当前分⽀$ git cherry-pick [commit]// 删除分⽀$ git branch -d [branch-name]// 删除远程分⽀$ git push origin --delete [branch-name]$ git branch -dr [remote/branch]六、标签// 列出所有tag$ git tag// 新建⼀个tag在当前commit$ git tag [tag]// 新建⼀个tag在指定commit$ git tag [tag] [commit]// 删除本地tag$ git tag -d [tag]// 删除远程tag$ git push origin :refs/tags/[tagName]// 查看tag信息$ git show [tag]// 提交指定tag$ git push [remote] [tag]// 提交所有tag$ git push [remote] --tags// 新建⼀个分⽀，指向某个tag$ git checkout -b [branch] [tag]七、查看信息// 显⽰有变更的⽂件$ git status// 显⽰当前分⽀的版本历史$ git log// 显⽰commit历史，以及每次commit发⽣变更的⽂件$ git log --stat// 搜索提交历史，根据关键词$ git log -S [keyword]// 显⽰某个commit之后的所有变动，每个commit占据⼀⾏$ git log [tag] HEAD --pretty=format:%s// 显⽰某个commit之后的所有变动，其"提交说明"必须符合搜索条件$ git log [tag] HEAD --grep feature// 显⽰某个⽂件的版本历史，包括⽂件改名$ git log --follow [file]$ git whatchanged [file]// 显⽰指定⽂件相关的每⼀次diff$ git log -p [file]// 显⽰过去5次提交$ git log -5 --pretty --oneline// 显⽰所有提交过的⽤户，按提交次数排序$ git shortlog -sn// 显⽰指定⽂件是什么⼈在什么时间修改过$ git blame [file]// 显⽰暂存区和⼯作区的差异$ git diff// 显⽰暂存区和上⼀个commit的差异$ git diff --cached [file]// 显⽰⼯作区与当前分⽀最新commit之间的差异$ git diff HEAD// 显⽰两次提交之间的差异$ git diff [first-branch]...[second-branch]// 显⽰今天你写了多少⾏代码$ git diff --shortstat "@{0 day ago}"// 显⽰某次提交的元数据和内容变化$ git show [commit]// 显⽰某次提交发⽣变化的⽂件$ git show --name-only [commit]// 显⽰某次提交时，某个⽂件的内容$ git show [commit]:[filename]// 显⽰当前分⽀的最近⼏次提交$ git reflog⼋、远程同步# 下载远程仓库的所有变动$ git fetch [remote]# 显⽰所有远程仓库$ git remote -v# 显⽰某个远程仓库的信息$ git remote show [remote]# 增加⼀个新的远程仓库，并命名$ git remote add [shortname] [url]# 取回远程仓库的变化，并与本地分⽀合并$ git pull [remote] [branch]# 上传本地指定分⽀到远程仓库$ git push [remote] [branch]# 强⾏推送当前分⽀到远程仓库，即使有冲突$ git push [remote] --force# 推送所有分⽀到远程仓库$ git push [remote] --all九、撤销// 恢复暂存区的指定⽂件到⼯作区$ git checkout [file]// 恢复某个commit的指定⽂件到暂存区和⼯作区$ git checkout [commit] [file]// 恢复暂存区的所有⽂件到⼯作区$ git checkout .// 重置暂存区的指定⽂件，与上⼀次commit保持⼀致，但⼯作区不变$ git reset [file]// 重置暂存区与⼯作区，与上⼀次commit保持⼀致$ git reset --hard// 重置当前分⽀的指针为指定commit，同时重置暂存区，但⼯作区不变$ git reset [commit]// 重置当前分⽀的HEAD为指定commit，同时重置暂存区和⼯作区，与指定commit⼀致$ git reset --hard [commit]// 重置当前HEAD为指定commit，但保持暂存区和⼯作区不变$ git reset --keep [commit]// 新建⼀个commit，⽤来撤销指定commit// 后者的所有变化都将被前者抵消，并且应⽤到当前分⽀$ git revert [commit]// 暂时将未提交的变化移除，稍后再移⼊$ git stash$ git stash pop⼗、其他// ⽣成⼀个可供发布的压缩包$ git archive感谢阅读，希望能帮助到⼤家，谢谢⼤家对本站的⽀持！。
Git学习⽂档#########################################################Study Document for Git#########################################################Git 基础Git ⽂件的三种状态：已提交（committed）、已修改（modified）和已暂存（staged）。
Git ⼯作⽬录的状态：已跟踪和未跟踪。
已提交表⽰数据已经安全的保存在本地数据库中。
已修改表⽰修改了⽂件，但还没保存到数据库中。
已暂存表⽰对⼀个已修改⽂件的当前版本做了标记，使之包含在下次提交的快照中。
基本的 Git ⼯作流程如下：1. 在⼯作⽬录中修改⽂件。
2. 暂存⽂件，将⽂件的快照放⼊暂存区域。
3. 提交更新，找到暂存区域的⽂件，将快照永久性存储到 Git 仓库⽬录。
Git 语法设置 Git 的配置git config --listgit config --global ***git config --global user.email @.comgit helpgit help verbgit verb --help克隆远端仓库git clone url检查当前⽂件状态git status列出当前分⽀和⽂件的状态：已跟踪/未跟踪。
[***@*** deployment]$ git status# On branch master# Untracked files:# (use "git add <file>..." to include in what will be committed)## test.mdnothing added to commit but untracked files present (use "git add" to track)跟踪新⽂件git add file[***@*** deployment]$ git add test.md[***@*** deployment]$ git status# On branch master# Changes to be committed:# (use "git reset HEAD file..." to unstage)## new file: test.md#Changes to be committed: 已暂存状态。
git、gerrit的使用方法和规范1、新员工git安装环境准备首先从服务器端ftp://192.168.31.10/Software/Tool/Git/（用户名/密码 paypalm/paypalms）获取软件Git-1.9.4-preview20140929 1、默认安装Git-1.9.4-preview20140929安装完成后打开git bash编辑器生成密钥对：ssh-keygen -t rsa 按三次回车键，默认生成路径如下图将生成的公钥内容在gerrit中进行添加（参考下文gerrit注册使用）每个人不同环境可以添加多个对应的公钥cat ~/.ssh/id_rsa.pub2、gerrit注册使用1、申请账号通过邮件向PPCM@发邮件申请，打开gerrit网站（http://192.168.31.10:8088），登录后在右上角进行setting设置2、公钥添加点击SSH Public Keys》Add Key选项进行公钥添加3、邮箱注册点击Register New Email 进行邮箱注册，注册后有邮件发送至你的邮箱点开链接重新登录3、gerrit主要功能介绍1、常规功能1、登录gerrit》ALL》open状态，此显示为已推送但还没有入库的所有patch，CR状态栏中绿色对勾代表已评审状态，可以根据计划入库2、gerrit》ALL》Merged状态表示所有已经进入项目库的patch3、提交patch后，开发人员可能觉得不太满意会选择放弃，gerrit》ALL》Abandoned 即为已放弃的patch，只有还没有入库的patch才能选择放弃，点击进入patch，橘黄色Abandon即为放弃选项，放弃后的patch依然可以进行还原，如以下操作橘黄色Restore为还原选项4、gerrit》Projects》List状态表示服务器端所有项目列表5、gerrit》People》List Groups状态表示所有组列表2、评审功能1、点击进入待评审的patch，点击add添加Reviews人员进行评审评审人员点击Reply进行评审打分，每一个需要入库的patch必须具备两分+2方可，1分表示自己同意，2分表示完全同意，负分表示不支持此代码入库2、gerrit》My》Changes状态为需要自己给别人进行评审的状态4、git命令使用1、账户名和邮箱设置查看1）、每一个工作环境首先配置在gerrit中注册的账户名和邮箱，请确保一致# git config --global “your-account”# git config --global user.email “your-email”# git config -l2、项目库clone根据gerrit项目列表，查看项目下载地址，选择clone with commit-msg hook&&ssh 选项,请确保正确方式进行项目库下载git clone ssh://your-accout@192.168.31.10:29418/Test3、提交注意事项每一个新clone的库第一次提交都需要执行以下步骤(下载服务端钩子到本地库，以便提交评审形成chang-id)scp -p -P 29418 your-account-name @192.168.31.10:hooks/commit-msg .git/hooks/git config remote.origin.push refs/heads/*:refs/for/*当执行完以上步骤，第一次git push依然会产生missing Change-Id错误，用git commit --amend命令把错误信息中的changed id进行添加，如下图本地工作库中，以最后一次成功push为节点，如果超过两条commit信息也会产生此错误合并多条commit为一条记录，可以用git reset 后跟要回退到最新push成功的版本号，整合多条记录为一条如产生uppack error和changed closed，建议保存工作库中修改文件，并进行强制回退、重新同步最新代码，以修复工作库index。
git message 语法-概述说明以及解释1.引言1.1 概述概述部分内容：引言部分将介绍本文的主题——"git message 语法"。
Git是一种分布式版本控制系统，它允许多人协同开发，并保留了每一个版本的更改记录。
在使用Git进行版本控制时，我们不仅需要关注代码的改动，还要注意良好的提交信息。
Git message（提交信息）是每次代码提交时，对所做更改的简短描述。
良好的Git message具有重要的意义。
首先，它可以使团队成员更清晰地了解自己以及他人所做的更改，避免项目中被遗忘的改动。
其次，良好的Git message可以提高代码的可读性，便于他人对代码进行理解和维护。
此外，当出现问题需要回溯历史版本时，清晰的Git message可以帮助我们快速定位出错地点和原因。
本文将介绍Git message的常用语法规则，包括合理的提交主题、提交内容的格式要求以及对应的时间戳格式等。
我们将详细探讨每个规则的用途和意义，并给出一些写好Git message的建议和提示。
通过学习和遵守这些语法规则，我们可以提高代码版本控制的效率和代码的可维护性。
总之，良好的Git message语法对于团队协作和项目的管理非常重要。
接下来的文章将深入探讨Git message语法规则以及其重要性，并为大家提供一些写好Git message的实用建议。
通过学习和遵循这些规则，我们可以提高我们的代码版本控制能力，提升团队合作效率和项目质量。
1.2 文章结构文章结构部分的内容如下：文章结构是指整篇文章的组织框架和布局，它决定了文章的逻辑顺序和信息的层次性。
一个合理的文章结构可以使读者更好地理解文章的内容，并能更快地获取所需信息。
通常，一篇文章的结构包括引言、正文和结论三个主要部分。
在引言部分，我们会对文章的主题进行概述，并介绍文章的目的和意义。
这部分内容的目的是引起读者的兴趣并让读者了解文章的背景信息。
Git的常⽤命令Git常⽤命令汇总以及其它相关操作⼀、常⽤的git命令--⽂件⽬录操作命令mkdir * 创建⼀个空⽬录 *指⽬录名pwd显⽰当前⽬录的路径。
cat * 查看*⽂件内容git rm * 删除**⽂件--git初始化操作git init 把当前的⽬录变成git仓库，⽣成隐藏.git⽂件。
git remote add origin url 把本地仓库的内容推送到GitHub仓库。
git clone git@url/test.git 从远程库克隆git add * 把x⽂件添加到暂存区去。
git commit –m "*"提交⽂件 –m 后⾯的是注释。
--git 克隆分⽀git clone xxx.git 最简单直接的命令git clone xxx.git "指定⽬录" clone到指定⽬录git clone -b branchname xxx.git clone时创建新的分⽀替代默认Origin HEAD（master）--clone 远程分⽀ git clone 命令默认的只会建⽴master分⽀，如果你想clone指定的某⼀远程分⽀(如：dev)的话，可以如下： 1. 查看所有分⽀(包括隐藏的) git branch -a 显⽰所有分⽀ * masterremotes/origin/HEAD -> origin/masterremotes/origin/devremotes/origin/master2. 在本地新建同名的("dev")分⽀，并切换到该分⽀git checkout -t origin/dev#该命令等同于：git checkout -b dev origin/dev--查看命令git status 查看仓库状态git diff * 查看X⽂件修改了那些内容git log 查看历史记录git reflog 查看历史记录的版本号id（记录你的每⼀次命令,不论是否提交）git log --pretty=oneline 如果信息量太多可以进⾏⽐较好的列表显⽰--版本回退git reset –hard HEAD^ 回退到上⼀个版本git reset --hard HEAD~第⼏个如果想回退到第3个版本，使⽤git reset –hard HEAD~3git reset --hard 057d 回退到某⼀个具体的版本号--撤销修改git checkout file-name 恢复某个已修改的⽂件（撤销未提交的修改）：git revert HEAD 还原最近⼀次提交的修改：git revert commit-id还原指定版本的修改--分⽀管理git branch 查看本地所有的分⽀git branch -a 查看远程所有的分⽀git branch name 创建分⽀git branch –d dev 删除dev分⽀git push origin --delete dev 删除远程的dev分⽀git branch -m dev develop 重命名分⽀git checkout –b dev 创建dev分⽀并切换到dev分⽀上git merge dev 在当前分⽀上合并dev分⽀代git push origin zyf-dev 把当前新增的zyf-dev分⽀推送到远程库(远程仓库没有给分⽀则会新建⽴该分⽀)git checkout — * 把XX⽂件在⼯作区的修改全部撤销。
常⽤git命令以及idea中git的⽤法总结前⾔最近本⼈将⼀些代码放到了github上，顺便总结了⼀下git的⽤法；经过了各种百度，最终形成了以下这篇⽂章。
个⼈感觉追求效率的话，只看最后⼀条git常⽤命令即可。
前⾯的似乎有⽤，⼜似乎没⽤......Git使⽤⽅法简介Git 是⼀个开源的分布式版本控制系统，⽤于敏捷⾼效地处理任何或⼩或⼤的项⽬。
Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发⽽开发的⼀个开放源码的版本控制软件。
Git 与常⽤的版本控制⼯具 CVS, Subversion 等不同，它采⽤了分布式版本库的⽅式，不必服务器端软件⽀持。
安装Git⼯作流程⼀般⼯作流程如下：1.克隆 Git 资源作为⼯作⽬录。
2.在克隆的资源上添加或修改⽂件。
3.如果其他⼈修改了，你可以更新资源。
4.在提交前查看修改。
5.提交修改。
6.在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。
下图展⽰了 Git 的⼯作流程：Git ⼯作区、暂存区和版本库⼯作区：就是你在电脑⾥能看到的⽬录。
暂存区：英⽂叫stage, 或index。
⼀般存放在 ".git⽬录下" 下的index⽂件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。
版本库：⼯作区有⼀个隐藏⽬录.git，这个不算⼯作区，⽽是Git的版本库。
下⾯这个图展⽰了⼯作区、版本库中的暂存区和版本库之间的关系：图中左侧为⼯作区，右侧为版本库。
在版本库中标记为 "index" 的区域是暂存区（stage, index），标记为 "master" 的是 master 分⽀所代表的⽬录树。
图中我们可以看出此时 "HEAD" 实际是指向 master 分⽀的⼀个"游标"。
所以图⽰的命令中出现 HEAD 的地⽅可以⽤ master 来替换。
presented by TOWER ›Version control with Git - made easyGIT CHEAT SHEETCREATEClone an existing repository$ git clone ssh://user@/repo.gitCreate a new local repository$ git initLOCAL CHANGESChanged files in your working directory$ git statusChanges to tracked files$ git diffAdd all current changes to the next commit$ git add .Add some changes in <file> to the next commit$ git add -p <file>Commit all local changes in tracked files$ git commit -aCommit previously staged changes$ git commitChange the last commitDon‘t amend published commits!$ git commit --amend COMMIT HISTORYShow all commits, starting with newest$ git logShow changes over time for a specific file$ git log -p <file>Who changed what and when in <file>$ git blame <file>BRANCHES & TAGSList all existing branches$ git branch -avSwitch HEAD branch$ git checkout <branch>Create a new branch based on your current HEAD$ git branch <new-branch>Create a new tracking branch based ona remote branch$ git checkout --track <remote/bran-ch>Delete a local branch$ git branch -d <branch>Mark the current commit with a tag$ git tag <tag-name>UPDATE & PUBLISHList all currently configured remotes$ git remote -vShow information about a remote$ git remote show <remote>Add new remote repository, named <remote>$ git remote add <shortname> <url>Download all changes from <remote>,b ut don‘t integrate into HEAD $ git fetch <remote>Download changes and directlymerge/integratei nto HEAD $ git pull <remote> <branch>Publish local changes on a remote$ git push <remote> <branch>Delete a branch on the remote$ git branch -dr <remote/branch>Publish your tag s$ git push --tagsMERGE & REBASEMerge <branch> into your current HEAD$ git merge <branch>Rebase your current HEAD onto <branch>Don‘t rebase published commits!$ git rebase <branch>Abort a rebase$ git rebase --abortContinue a rebase after resolving conflicts$ git rebase --continueUse your configured merge tool to solve conflicts$ git mergetoolUse your editor to manually solve conflicts and (after resolving) mark file as resolved$ git add <resolved-file>$ git rm <resolved-file>UNDODiscard all local changes in your working directory$ git reset --hard HEADDiscard local changes in a specific file$ git checkout HEAD <file>Revert a commit (by producing a new commitwith contrary changes)$ git revert <commit>Reset your HEAD pointer to a previous commit …and discard all changes since then$ git reset --hard <commit>…and preserve all changes as unstagedchanges$ git reset <commit>…and preserve uncommitted local changes$ git reset --keep <commit>对于某个文件的修改：时间、地点、人物某个文件的最近一次修改stage所有修改，注意点号其实可用reflog找到并恢复该版本。
把和上个commit之间的修改放回工作区。
跳过git add，不建议修补，而不是revert常用 git commit --amend --no-editBEST PRACTICESVERSION CONTROLCOMMIT RELATED CHANGESA commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for other de-velopers to understand the changes and roll them back if something went wrong.With tools like the staging area and the abi-lity to stage only parts of a file, Git makes it easy to create very granular commits.COMMIT OFTENCommitting often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it‘s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard to solve conflicts.DON‘T COMMIT HALF-DONE WORKYou should only commit code when it‘s completed. This doesn‘t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature‘s implementation into logical chunks and remember to commit early and often. But don‘t commit just to have something in the repository before leaving the office at the end of the day. If you‘re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git‘s «Stash» feature instead.TEST CODE BEFORE YOU COMMITResist the temptation to commit some-thing that you «think» is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). While committing half-baked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing/sharing your code with others.WRITE GOOD COMMIT MESSAGESBegin your message with a short summary of your changes (up to 50 characters as a gui-deline). Separate it from the following body by including a blank line. The body of your message should provide detailed answers to the following questions:› W hat was the motivation for the change? › H ow does it differ from the previousimplementation?Use the imperative, present tense («change»,not «changed» or «changes») to be consistent with generated messages from commandslike git merge.VERSION CONTROL IS NOT A BACKUP SYSTEMHaving your files backed up on a remoteserver is a nice side effect of having a version control system. But you should not use your VCS like it was a backup system. When doing version control, you should pay attention to committing semantically (see «related chan-ges») - you shouldn‘t just cram in files.USE BRANCHESBranching is one of Git‘s most powerful features - and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development. You should use branches extensively in your development workflows: for new features, bug fixes, ideas…AGREE ON A WORKFLOWGit lets you pick from a lot of different work-flows: long-running branches, topic bran-ches, merge or rebase, git-flow… Which oneyou choose depends on a couple of factors: your project, your overall development and deployment workflows and (maybe most importantly) on your and your teammates‘ personal preferences. However you choose to work, just make sure to agree on a common workflow that everyone follows.HELP & DOCUMENTATIONGet help on the command line$ git help <command>FREE ONLINE RESOURCES /learn http://rogerdudler.github.io/git-guide//经常commit，小而多的commit“颗粒化”#不同的修改，使用不同的commit #同一修改，即使涉及不同的文件， 也要放在同一个commit 一些常用的习惯修改完全再commit，修改一半可以stash commit之前测试是或否行得通commit要-m注释，注意格式。
