Git标签管理标签04标签05

创建

--克隆现有存储库
$git clone ssh://user@domain.com/repo.git
--创建新的本地存储库
$git init

局部变化

--工作目录中已更改的文件
$git status
--对跟踪文件的更改
$git diff
--将所有当前更改添加到下一次提交
$git add .
--将<file>中的一些更改添加到下一次提交
$git add-p<file>
--提交跟踪文件中的所有本地更改
$git commit-a
--提交以前暂存的更改
$git commit
--更改上次提交
--不要修改已发布的文档！
$git commit--amend-

提交历史记录

--显示所有提交，从最新开始
$git log
--显示特定文件随时间的变化
$git log-p<file>
--谁在<file>做更改
$git<file>

分支和标记

--列出所有现有分支
$git blame-av
--开关头分支
$git  branch<branch>
--根据您当前的头创建一个新分支
$git branch<new-branch>
--基于远程分支创建新的跟踪分支
$git checkout—track<remote/branch>
--删除本地分支
$git branch-d<branch>
--用标记标记当前提交
$git tag<tag name>

更新和发布

--列出所有当前配置的远程设备
$git remote -v
--显示有关遥控器的信息
$git remote show<remote>
--添加名为<remote>
$git remote add<shortname><url>
--从<remote>下载所有更改，但不要集成到HEAD中
$git fetch<remote>
--下载更改并直接合并/集成到HEAD中
$git pull<remote><branch>
--在远程服务器上发布本地更改
$git push<remote><branch>
--删除远程服务器上的分支
$git branch-dr<remote/branch>
--发布您的标签
$git push--标签

合并和重设基础

--将<branch>合并到当前的头中
$git merge<branch>
--将当前的头重新定位到<branch>
--不要重新设置已发布提交的基础！
$git rebase<branch>
--中止重新基准
$git rebase—abort
--解决冲突后继续重设基础
$git rebase--continue
--使用配置的合并工具解决冲突
$git mergetool
--使用编辑器手动解决冲突，并（在解决后）将文件标记为已解决
$git add<resolved file>
$git rm<resolved>

撤消

--放弃工作目录中的所有本地更改
$git reset—hard
--放弃特定文件中的本地更改
$git checkout HEAD<file>
--恢复提交（通过生成具有相反更改的新提交）
$git revert<commit>
--将头指针重置为上一个提交
--…并放弃此后的所有更改
$git reset—hard<commit>
--…并将所有更改保留为未暂存的更改
$git reset<commit>
--…并保留未提交的本地更改
$git reset—keep<commit>

提交相关更改

提交应该是相关更改的包装器。例如，修复两个不同的bug应该会产生两个单独的提交。小的提交使其他开发人员更容易理解更改，并在出现问题时回滚更改。有了像暂存区域这样的工具和只暂存部分文件的能力，Git使得创建非常精细的提交变得非常容易。

经常承诺

提交通常会使您的提交变小，并且再次帮助您只提交相关的更改。此外，它允许您更频繁地与他人共享代码。这样，每个人都可以更容易地定期集成更改并避免合并冲突。相反，很少有大的承诺，很少分享，这使得解决冲突变得困难。

不要半途而废

您应该只在代码完成时提交它。这并不意味着您必须在提交之前完成一个完整的、大的特性。恰恰相反：将特性的实现分成逻辑块，并记住尽早和经常提交。但不要只承诺在一天结束离开办公室之前在存储库中保存一些东西。如果仅仅因为需要一个干净的工作副本（签出分支、拉入更改等）而试图提交，那么可以考虑改用Git的«Stash»特性。

提交前测试代码

抵制诱惑去做你认为已经完成的事情。彻底测试它，以确保它真的是完整的，没有副作用（据一个人所知）。虽然在本地存储库中提交半生不熟的东西只需要你原谅自己，但在与他人推送/共享代码时，测试代码更为重要。

编写好的提交消息

以简短的更改摘要开始您的邮件（最多50个字符作为准则）。通过包含一个空行将其与下一正文分开。邮件正文应详细回答以下问题：
›改变的动机是什么？
›它与以前的实施有何不同？
使用命令式现在时（«change»，not«changed»或«changes»）与git merge等命令生成的消息保持一致。

版本控制不是备份系统

在远程服务器上备份文件是版本控制系统的一个很好的副作用。但你不应该像使用备份系统一样使用风投。在进行版本控制时，您应该注意语义上的提交（请参阅«相关更改»）-您不应该只是塞进文件。

使用分支

分支是Git最强大的特性之一——这并不是偶然的：快速简单的分支是Git第一天的核心要求。分支是帮助您避免混淆不同开发线的完美工具。您应该在开发工作流程中广泛使用分支：新特性、错误修复、想法…

商定工作流程

Git允许您从许多不同的工作流中进行选择：长时间运行的分支、主题分支、合并或重基、Git流……您选择哪一个取决于几个因素：您的项目、总体开发和部署工作流，以及（可能最重要的）您和您的团队成员的个人偏好。不管你选择什么样的工作方式，只要确保每个人都遵循一个共同的工作流程。

帮助和文档

在命令行上获取帮助
$git help

免费在线资源

http://www.git-tower.com/learn
http://rogerdudler.github.io/git-guide/
http://www.git-scm.org/

• 本文作者：GeekPower - Felix Sun
• 版权声明： 本博客所有文章除特别声明外，均采用 MIT 许可协议。转载请注明出处！