git - 简明指南(转)

安装

下载 git OSX 版

下载 git Windows 版

下载 git Linux 版

创建新仓库

创建新文件夹,打开,然后执行  git init 以创建新的 git 仓库。

检出仓库

执行如下命令以创建一个本地仓库的克隆版本: git clone /path/to/repository  如果是远端服务器上的仓库,你的命令会是这个样子: git clone username@host:/path/to/repository

工作流

你的本地仓库由 git 维护的三棵“树”组成。第一个是你的 工作目录,它持有实际文件;第二个是 暂存区(Index),它像个缓存区域,临时保存你的改动;最后是 HEAD,它指向你最后一次提交的结果。

添加和提交

你可以提出更改(把它们添加到暂存区),使用如下命令: git add <filename> git add * 这是 git 基本工作流程的第一步;使用如下命令以实际提交改动: git commit -m "代码提交信息" 现在,你的改动已经提交到了 HEAD,但是还没到你的远端仓库。

推送改动

你的改动现在已经在本地仓库的 HEAD 中了。执行如下命令以将这些改动提交到远端仓库: git push origin master 可以把 master 换成你想要推送的任何分支。 
如果你还没有克隆现有仓库,并欲将你的仓库连接到某个远程服务器,你可以使用如下命令添加: git remote add origin <server> 如此你就能够将你的改动推送到所添加的服务器上去了。

分支

分支是用来将特性开发绝缘开来的。在你创建仓库的时候,master 是“默认的”分支。在其他分支上进行开发,完成后再将它们合并到主分支上。


创建一个叫做“feature_x”的分支,并切换过去: git checkout -b feature_x 切换回主分支: git checkout master 再把新建的分支删掉: git branch -d feature_x 除非你将分支推送到远端仓库,不然该分支就是 不为他人所见的git push origin <branch>

更新与合并

要更新你的本地仓库至最新改动,执行: git pull 以在你的工作目录中 获取(fetch) 并 合并(merge) 远端的改动。 要合并其他分支到你的当前分支(例如 master),执行: git merge <branch> 在这两种情况下,git 都会尝试去自动合并改动。遗憾的是,这可能并非每次都成功,并可能出现冲突(conflicts)。 这时候就需要你修改这些文件来手动合并这些冲突(conflicts)。改完之后,你需要执行如下命令以将它们标记为合并成功: git add <filename> 在合并改动之前,你可以使用如下命令预览差异: git diff <source_branch> <target_branch>

标签

为软件发布创建标签是推荐的。这个概念早已存在,在 SVN 中也有。你可以执行如下命令创建一个叫做 1.0.0 的标签: git tag 1.0.0 1b2e1d63ff 1b2e1d63ff 是你想要标记的提交 ID 的前 10 位字符。可以使用下列命令获取提交 ID: git log 你也可以使用少一点的提交 ID 前几位,只要它的指向具有唯一性。

替换本地改动

假如你操作失误(当然,这最好永远不要发生),你可以使用如下命令替换掉本地改动: git checkout -- <filename> 此命令会使用 HEAD 中的最新内容替换掉你的工作目录中的文件。已添加到暂存区的改动以及新文件都不会受到影响。

假如你想丢弃你在本地的所有改动与提交,可以到服务器上获取最新的版本历史,并将你本地主分支指向它: git fetch origin git reset --hard origin/master

实用小贴士

内建的图形化 git: gitk 彩色的 git 输出: git config color.ui true 显示历史记录时,每个提交的信息只显示一行: git config format.pretty oneline 交互式添加文件到暂存区: git add -i

链接与资源

图形化客户端

 

 

指南和手册

 

http://rogerdudler.github.io/git-guide/index.zh.html

时间: 2024-07-28 14:23:52

git - 简明指南(转)的相关文章

git - 简明指南--很酷的git网址【转】

转自:http://rogerdudler.github.io/git-guide/index.zh.html

Java8简明指南

Java8简明指南 欢迎来到Java8简明指南.本教程将一步一步指导你通过所有新语言特性.由短而简单的代码示例,带你了解如何使用默认接口方法,lambda表达式,方法引用和可重复注解.本文的最后你会熟悉最新的API的变化如Stream,Fcuntional,Map API扩展和新的日期API.   接口的默认方法 在Java8中,利用default关键字使我们能够添加非抽象方法实现的接口.此功能也被称为扩展方法,这里是我们的第一个例子: interface Formula { double ca

Java8系列 - Java8简明指南

Java8简明指南 欢迎来到Java8简明指南.本教程将一步一步指导你通过所有新语言特性.由短而简单的代码示例,带你了解如何使用默认接口方法,lambda表达式,方法引用和可重复注解.本文的最后你会熟悉最新的API的变化如Stream,Fcuntional,Map API扩展和新的日期API. 接口的默认方法 在Java8中,利用default关键字使我们能够添加非抽象方法实现的接口.此功能也被称为扩展方法,这里是我们的第一个例子: interface Formula { double calc

git - 简易指南

git - 简易指南   ---   原文很漂亮,点击跳转 助你开始使用 git 的简易指南,木有高深内容,;). Tweet 作者:罗杰·杜德勒 感谢:@tfnico, @fhd and Namics 其他语言 english, deutsch, español, français, italiano, nederlands, português, русский, türkçe, မြန်မာ, 日本語, 한국어 如有纰漏,请到 github 填报 安装 下载 git OSX 版 下载 gi

git使用指南

下载代码库 git clone git@gitlab.alibaba-inc.com:snsgalxy-dev/snsgalaxy.git 创建分支 git checkout -b <new_branch> -t <remote_branch> 以上命令用于创建名字为<new_branch>的分支, 然后切换到这个分支, 同时让这个分支track远程代码库中的<remote_branch>分支.适用于创建一个用于指向远程代码库中已经存在的分支的情况.执行这个

Linux服务器安全简明指南

现在让我们强化你的服务器以防止未授权访问. 经常升级系统 保持最新的软件是你可以在任何操作系统上采取的最大的安全预防措施.软件更新的范围从关键漏洞补丁到小 bug 的修复,许多软件漏洞实际上是在它们被公开的时候得到修补的. 自动安全更新 有一些用于服务器上自动更新的参数.Fedora 的 Wiki 上有一篇很棒的剖析自动更新的利弊的文章,但是如果你把它限制到安全更新上,自动更新的风险将是最小的. 自动更新的可行性必须你自己判断,因为它归结为你在你的服务器上做什么.请记住,自动更新仅适用于来自仓库

快速安装Ruby on Rails的简明指南_ruby专题

对于新入门的开发者,如何安装 Ruby, Ruby Gems 和 Rails 的运行环境可能会是个问题,本页主要介绍如何用一条靠谱的路子快速安装 Ruby 开发环境. 次安装方法同样适用于产品环境!系统需求 首先确定操作系统环境,不建议在 Windows 上面搞,所以你需要用:     Mac OS X     任意 Linux 发行版本(Ubuntu,CentOS, Redhat, ArchLinux ...)     强烈新手使用 Ubuntu 省掉不必要的麻烦! 以下代码区域,带有 $ 打

《Git学习指南》——导读

** 前言 **Git的背后有着一个非常精彩的成功故事.2005年4月,Linus Torvalds因不满当时任何一个可用的开源版本控制系统,就亲自着手实现了Git.时至今日,如果我们在Google中搜索"git version control"这几个关键词,都会看到数以百万计的返回结果.Git已经俨然成为了新型开源项目的一个标准.许多大型的开源项目都已经或正在计划迁移到Git上来. 下面,我们来看一下这么多人之所以会选择Git的原因. Git允许我们利用分支来开展工作:在一个由多个开

《Git学习指南》——第1章 基本概念 1.1分布式版本控制,有何过人之处

第1章 基本概念 在本章中,我们将介绍一个分布式版本控制系统的设计思路,以及它与集中式版本控制系统的不同之处.除此之外,我们还将带你了解分布式版本库的具体工作方式,以及为什么我们会说,在Git中创建分支和合并分支不是个大不了的问题. 1.1 分布式版本控制,有何过人之处 在具体探讨分布式版本控制的概念之前,让我们先来快速回顾一下传统的集中式版本控制架构. 图1.1中所显示的就是一个集中式版本控制系统(例如CVS或Subversion)的典型布局.每个开发者都在他或她自己的计算机上有一个包含所有项