发表更新开发 / Git / Git Flow

一个成功的 Git 分支模型

原文地址: 介绍一个成功的 Git 分支模型
英文原文地址: A successful Git branching model
在这篇文章中，我提出一个开发模型。我已经将这个开发模型引入到我所有的项目里（无论在工作还是私人）已经一年有余，并且它被证明是非常成功的。我打算写这些已经很久了，但我一直找不到时间来做，现在终于有时间了。我不会讲任何项目的具体细节，仅是关于分支策略和释放管理相关内容。

它主要体现了 Git 对我们源代码版本的管理。
为何是 Git？
对于 Git 与其他集中式代码管理工具相比的优缺点的全面讨论，请参见这里。这样的争论总是喋喋不休。作为一个开发者，与现今的其他开发工具相比较，我更喜欢 Git。Git 真得改变了开发者对于合并和分支的思考。我曾经使用经典的 CVS/Subversion，然而每次的合并/分支和其他行为总让人担惊受怕（“小心合并里的冲突，简直要命！”）。
但是对于 Git 来说，这些行为非常简单和搞笑，它们被认为是_日常_工作中的核心部分。例如，在很多 CVS/Subversion书里，分支与合并总是在后面的章节中被讨论（对于高级用户使用），然而在每个 Git书中，在第 3 章就已经完全涵盖了（作为基础）。
简单和重复的特性带来的结果是：分支与合并不再是什么可以害怕的东西。分支/合并被认为对于版本管理工具比其他功能更重要。
关于工具，不再多说，让我们直接看开发模型吧。这个模型并不是如下模型：在管理软件开发进度方面，面对每个开发过程，每个队员必须按一定次序开发。
分布式而非集中式
对于这种分支模型，我们设置了一个版本库，它运转良好，这是一个”事实上” 版本库。不过请注意，这个版本库只是被_认为_是中心版本库（因为 Git 是一个分布式版本管理系统，从技术上来讲，并没有一个中心版本库）。我们将把这个版本库称为原始库，这个名字对所有的 Git 用户来说都很容易理解。

每个开发者都对 origin 库拉代码和提交代码。但是除了集中式的存取代码关系，每个开发者也可以从子团队的其他队友那里获得代码版本变更。例如，对于 2 个或多个开发者一起完成的大版本变更，为了防止过早地向 origin 库提交工作内容，这种机制就变得非常有用。在上述途中，有如下子团队：Alice 和 Bob，Alice 和 David，Clair 和 David。
从技术上将，这意味着，Alice 创建了一个 Git 的远程节点，而对于 Bob，该节点指向了 Bob 的版本库，反之亦然。

阅读更多
发表更新开发 / Git / Git Flow

Git-Flow 工作规范流程

当在团队开发中使用版本控制系统时，确定一个统一的工作流程是至关重要的。如果在团队中还没有能形成一个特定有效的工作流程，那么混乱就将是不可避免的。

阅读更多
发表更新开发 / Git

git 代码自动化部署 shell 脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<!-- more -->
#!/bin/bash
_FILES=/data/web/ixdcw_dev/
_times=`date +%Y%m%d`
log=/data/web/log.log
string=`cat $log |awk {'print $1'}`
#echo $PWD
cd $_FILES
#chown -R daemon:daemon $_FILES
#chmod 744 -R $_FILES
#echo 'chown the own of ixdcw_ixdcw files !'
#echo $PWD
#cd $_FILES
/usr/bin/git checkout 1.3.0
echo "git branch  to dev and git pulling now ..."
/usr/bin/git pull origin 1.3.0 >$log
if [ "$string" == "Already" ];then
        echo $string
else
        /usr/bin/git fetch -f
        /usr/bin/git reset --hard
        /usr/bin/git pull origin 1.3.0
        echo "GIT RESET ORIGIN DEV HEAD"
fi
#Already up-to-date.
echo $_times >pull_branch_dev.log

语雀镜像 : git 代码自动化部署 shell 脚本 ,点此 提问

发表更新开发 / Git

Git 常用命令清单(Cheet-Sheet)

一般来说，日常使用只要记住下图6个命令即可。但是熟练使用，恐怕要记住60～100个命令。

下面是我整理的常用 Git 命令清单。几个专用名词的译名如下。

  • Workspace：工作区
  • Index / Stage：暂存区(已修改未提交的文件)
  • Repository：本地仓库
  • Remote：远程仓库
阅读更多
发表更新开发 / Git

[转] github issue是做什么的？

GitHub 的 issue 功能，对个人而言，就如同 TODO list 。

你可以把所有想要在下一步完成的工作，如 feature 添加、bug 修复等，都写成一个个的 issue ，放在上面。既可以作为提醒，也可以统一管理。
另外，每一次 commit 都可以选择性的与某个 issue 关联。比如在 message 中添加 #n，就可以与第 n 个 issue 进行关联。

阅读更多
发表更新开发 / Git

Git 使用 subtree 管理多个项目代码

对于多项目来说, 使用一个项目来管理多个包是最为方便的, 但是每个包单独弄一个 git 地址去做代码的提交是非常累人的

在一个项目中管理所有包, 为每个不同的文件夹设定不同的地址并共享主项目的提交记录, 然后进行包的提交无疑是最方便的.

例如上面 poppy project 为一个项目, 其他几个为不同的包, 每个包有唯一的 git 仓库地址

一开始使用子树的方式去进行提交

阅读更多
发表更新开发 / Git

Git : AutoCRLF与SafeCRLF换行符问题

Windows在换行的时候，同时使用了回车符(carriage-return character)和换行符(linefeed character)；而Mac和Linux系统(很老的mac系统才是CR，可以参见wiki)，此时，仅仅使用了换行符(linefeed character)。同时呢，Windows的许多编辑器还悄悄滴将LF修改成了CRLF格式的行结束符，或者在你敲回车的时候，CRLF格式的行结束符就产生了。

Git有一个针对性的功能：当添加到暂存区时，自动将CRLF转换成LF；反之，当检出时，自动将LF转换成CRLF。

可以通过设置core.autocrlf来开启这个功能。

阅读更多
发表更新开发 / Git

Git Commit 使用规范流程

原文地址 : Git 使用规范流程

团队开发中，遵循一个合理、清晰的 Git使用流程，是非常重要的。

否则，每个人都提交一堆杂乱无章的commit，项目很快就会变得难以协调和维护。

下面是ThoughtBot 的Git使用规范流程。我从中学到了很多，推荐你也这样使用Git。

阅读更多
发表更新开发 / Git

Git .gitignore 文件规则和示例

一、文件规则

gitignore其实就是在glob匹配的基础上添加了路径匹配和!、#语法。

基本规范：

  • 所有空行或者以注释符号#开头的行都会被 Git 忽略。
  • 匹配模式最后跟反斜杠/说明要忽略的是目录
  • 要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号!取反
  • 可以使用标准的 glob 模式匹配

所谓的 glob 模式是指 shell 所使用的简化了的正则表达式：

  • 星号*匹配零个或多个任意字符
  • 问号?只匹配一个任意字符
  • 方括号[]匹配任何一个列在方括号中的字符
  • 如果在方括号中使用短划线-分隔两个字符，表示所有在这两个字符范围内的都可以匹配，如[0-9]表示匹配所有 0 到 9 的数字

! 取消忽略说明

!*-ui就是重新匹配当前目录下的以‘-ui’结尾的文件夹。这里需要注意，如果父级目录被忽略了，子集目录是无法取消忽略的。例：

阅读更多

链接

归档