tags in git for sane version numbers

The problem

In the svn days, branching was expensive, repositories were centralized ... life was hard. But one thing was easy; each revision had a number and that number went up each time a change was committed to the repository. This made versioning easy: v1, then v2, later v345, finally v1202, anyone can see this and understand.

When switching to git, there is a bit of a learning curve, as each commit is named with an unpronounceable 40 character hexidecimal hash. It's really easy to tell a client, "I just deployed v434, it has all the features we talked about yesterday" Or, "Yeah, you're looking at v57, the new features are in v62" . Its much more difficult to tell a client, "Sorry for the mixup, you are looking at gdac40b3 but the bug is fixed in 616f65bb". I can already see eyes glazing over in confusion.

git has a really handy tags feature. It is perfect for large complicated projects where several commits go into each new release, and the release schedule is on the scale of weeks rather than days. You tag 1.0, then 1.1, 1.1.1 - and so on. These are sane version numbers and are easy to talk about. The problem is that they take work. When you are working on something uncomplicated and the release cycle measures in days or hours, nothing beats the old commit by commit versioning system.

The solution

To get automatic revision numbers in git, we use the native tags, but in a slightly different way. The git describe, command has a handy feature, it can figure out how many commits your repository has after the last tag. What this means is that when you create a tag, say 1.0, 4 commits later git describe will call this "1.0-4-616f65bb". What I propose is to use this feature to our advantage. Rather than tag at the end of a target version, say 1.1.1, we tag at the beginning, and let git to the work. And rather than 1.1.1, we use a meaningful name. So for example, I might use a tag like this:

$ git tag -a 'milestone1' -m 'starting work for milestone 1, due in 2 weeks'
$ git push --tags

From here on out, git will automatically count the commits for us, so we have a sane version number to talk about with clients. If we want to see it, all we need to do is this:

$ git describe
milestone1-34-g4a1e1d4

Which I can then use to tell the client, "Ok, I just deployed milestone1-34, we added the feature to read your thoughts, please check it out and let me know - oh wait ... the software can tell me."

Something that we always do is embed the current revision somewhere into the software so that we know what version the user is seeing. In Rails, I just added this to config/initializers/git_helper.rb

# VERSIONING
git_version_cmd = "git describe"
$revision = `#{git_version_cmd}`
$revision = $revision.strip
puts "starting version: #{$revision}"

I can now put $revision in the footer, or hide it in a comment somewhere on the page. This helps keep everyone in the loop and prevent misunderstandings about what version someone may be looking at.

This is just one way to manage versions in git, we'd love to hear yours!

Posted by adevadeh 22 Dec 2011 at 07:50AM


conflict-when-git-up

When I started to use Git, I felt really pain for it. The problem is that when your team mate told you that he has checked in, and you are willing to see the update right away. So you just 'git up', and then you probably see something like 'you need to commit first before merging'. Oops, but I am just in the middle of modifying something, I am not ready at all to check in.

Well, that's what git up are different from svn up. Here, one tips is:

git stash save   # this will save your local changes to a temporary place, and clean up your workspace
git up                 # here, you could just update to the HEAD of your branch, probably master
git stash pop    # then you could get your local change back, and you probably need to fix the conflicts here

http://lists-archives.org/git/708097-you-have-local-changes-cannot-switch-branches-error-question.html

Posted by Shaokun 22 Dec 2011 at 07:49AM


mysmGit 之Git on Windows快速上手

大家好,本文旨在让Window环境下的Github新用户短时间内快速上手Git,不需要者请就此打住。


目标:看完本文,读者们可以应用在Windows下与Github结合进行项目的创建、添加控制文件、本地提交、远程更新和远程发布等常用的功能。


背景:一个月前,技术总监阿德带领我创建了名字叫“FancyEditor”的迷你型JS开源项目,并用新兴的Git作为版本控制工具,以后我们kudelabs http://github.com/kudelabs/ 上面将会开放更多的源码与网友们分享、学习,共同进步。

刚开始用Git感觉很陌生,走了些弯路,特地写下本文提醒自己别再犯同样的错误,也鼓励下新加入Git的朋友,欢迎你。


一、 本人认为mysmGit目前是相当好用的Windows Git,当前使用的版本是Git-1.5.6.1,大家可以从: http://code.google.com/p/msysgit/ 得到最新的版本。

安装的过程不要管其他东西,一直点击<下一步>到安装结束。

安装完成后,新建一个项目文件夹,单击鼠标右键你会看到选项‘Git GUI Here’ 还有‘Git Bash Here’,请选择‘Git Bash Here,该版本GUI视图给本人感觉实用性不好,先不讲它。


二、 设置SSH公钥,注意:这一步的正确配置非常重要,我们至少得有一个SSH公钥才能连接并操作Github或其他repo点上的项目。


跟着弹出Git窗口,DOS模式也许对于不习惯命令行的广大Windows用户是一种受罪。请咬咬牙忍一忍,因为真正需要用到的命令行并不是很多。

这里我们要配置本地与github.com之间的SSH 公钥

首先,请输入:ssh-keygen -C "你的email地址" -t rsa ,确定回车键连续4次,不管中间要求输入其他东西。该命令将生成一对非对称的\私密钥,默认它们被存储在:

XP/2003用户:c:\Documents and Settings\登陆名\.ssh

Vista用户: c:\Users\登陆名\.ssh

.ssh文件夹下面,密钥放在id_rsa文件里面,不用理会它;

SSH公钥放在id_rsa.pub里面,请用文本编辑器打开它,复制里面所有的字符。



假定此时的你已经注册了Github用户,在账号管理account页面,有个大大的SSH Public Keys”栏目,请点击“add another public keyTitle可空(默认值为email)或者任意,直接黏贴刚才复制的字符在Key文本域里面,最后点击Add Key

SSH成功创建后:


三、 创建新的项目/ Create a New Repository,全局设置

Github网站上创建一个新的项目

 

记住你看到的Your Clone URL: git@github.com:git-on-windows/rookies.git

这路径比较统一容易记,git@github.com冒号后面的第一个单词是你的用户名,’/’斜杠号后面是你的项目名称.git

Okay,回到刚才的DOS窗口,我们要设置全局用户名称以及Email以方便Git知道你是谁。

分别输入:


git config --global user.email “你的email地址”

git config --global user.name “你的名称”


其实不严格来说,这一步可忽略,它并不影响以后你对项目的各种操作行为,只是让Git记录是由谁在执行操作。本人愚见认为在多人的团队开发过程中同一个项目用同一个SSH公钥的时候可见效果。

四、简单Git命令实战

依次输入下列命令:

1). git init #系统初始化git目录:

Initialized empty Git repository in D:/git_on_windows/.git/


2). touch READ #touch表示创建文件,文件名称是“READ”


3). git add READ #把文件READ加入git的版本控制


4). git commit -m 'any commit message' #提交新版本至git仓库,后面是提交信息:

Created initial commit b09873d: any commit message

0 files changed, 0 insertions(+), 0 deletions(-)

create mode 100644 READ


5). git remote add mybranch git@github.com:git-on-windows/rookies.git #创建本地与远程服务器的分支mybranch


6). git pull mybranch master #把远程服务器master分支的内容更新至本地mybranch分支


7). git push mybranch master #把本地mybranch分支所有的修改提交至远程git服务器

恭喜,朋友们,到这里我们已经完成了Git入门,请尽情享受Git带来的乐趣吧!


五、最后,顺便提一下刚开始用git命令容易出现的错误以及解决方法:


1).“Permission denied (publickey).”错误,SSH公钥没有设置好,请看本文章第二点:设置SSH公钥。


2).“fatal: Not a git repository”错误,尚未初始化git目录,请用: git init命令。


3).“fatal: 'origin': unable to chdir or not a git archive”错误,不存在分支 ’origin’,这个’origin’可能是本地分支,也可能是远程分支;若是本地分支应该用类似git remote add origin git@github.com:username/projectname.git 的命令来解决,若是远程分支,请注意它的个时是否正确


4). “! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'git@github.com:git-on-windows/rookies.git’ ”错误,执行某git命令前需要更新项目,可用类似命令:git pull yourbranch master 解决


5).” Repository not found. If you've just created it, please try again in a few seconds.”错误,很大原因是没有设置好远程路径,或者路径错误,请记住标准的git路径类似:git@github.com:username/ projectname.git


错误集合待更新中。。。


Posted by Mysen 24 Sep 2008 at 04:53AM


freezing git Rails into your SVN project

While all the cool kids are switching to git (notably Rails itself), we still have several projects that live in svn repositories and we really have no desire to migrate them. We do, however, want to upgrade to the latest Rails version, now managed via git at github.com.

While I have found lots of old tutorials based on svn, or new ones explaining how to freeze rails to your git-based project, I have not seen a good one about freezing git-based rails to an svn-based project. Here are the steps I used:

First, remove your older svn-frozen copy of Rails
$ svn rm vendor/rails
$ svn ci -m 'upgrading rails to the latest git stable version *** this revision is missing rails ***'
Next, get your own local Rails repository
$ cd vendor
$ git clone git://github.com/rails/rails.git
$ cd rails
Now you can add the new version of Rails to your svn project
$ git checkout -b v2.1.1
$ svn add ../rails
$ svn revert --recursive .git
$ cd ../.. # back to your root dir
$ rake rails:update # update the supplemental rails files
$ svn ci -m 'upgrade to rails 2.1.1'

Of course, you can replace 2.1.1 with whatever the current version you are interested in. Later on, when a new version of Rails is released, you can simply update your git repo and switch to a new branch like so:

$ cd vendor/rails
$ git pull origin master
$ git checkout -b v2.2.0
$ svn status
# here you would have to add any deleted files, and add any new files
# this step could easily be automated
$ svn ci -m 'enjoy the latest Rails'

Note: If you are upgrading from 1.2.x -> 2.x.x make sure to add back the plugins that you were using such as will_paginate or acts_as_tree.

$ script/plugin install git://github.com/rails/acts_as_tree.git
$ svn add vendor/plugins/acts_as_tree
$ script/plugin install git://github.com/mislav/will_paginate
$ svn add vendor/plugins/will_paginate

Hope this helps anyone else trying to do the same thing. I am sure there are other ways to accomplish a this task as well. Feel free to put your solution in the comments.

Posted by adevadeh 19 Sep 2008 at 04:51PM