Git: Your branch is ahead of the tracked remote branch

明年今日 — Fri, 24 Feb 2012 09:07:00 GMT

Problem

When moving to a local branch, git says I'm "ahead of the tracked remote branch", but a git push doesn't update the remote branch.

$ git checkout mybranch 

Your branch is ahead of the tracked remote branch 'origin/remotebranch' by 1 commit. 

$ git push Everything up-to-date

Solution 1. Pushing mybranch to remotebranch

$ git push origin mybranch:remotebranch

or for later pushes with just git push origin you can put this in .git/config with this command:

$ git config remote.origin.push mybranch:remotebranch

Solution 2. Reset mybranch to state of remotebranch

NOTE: Careful! You will loose commits made to mybranch!

$ git reset --hard origin/remotebranch

Problem: You cann't push to git://github.com/username/repo.git

There should be something wrong with your remote configuration, set like the follow:


$ git remote rm origin 

$ git remote add origin 

$ git remote add origin git@github.com:tualatrix/gentoo.git 

$ git push origin

Problem: Permission denied (publickey)

Generate a new SSH key.

To generate a new SSH key, enter the code below. We want the default settings so when asked to enter a file in which to save the key, just press enter.

$ ssh-keygen -t rsa -C "your_email@youremail.com"Creates a new ssh key using the provided emailGenerating public/private rsa key pair.Enter file in which to save the key (/Users/your_user_directory/.ssh/id_rsa):

Now you need to enter a passphrase.

Why do passphrases matter?

Enter passphrase (empty for no passphrase):Enter same passphrase again:

Which should give you something like this:

Your identification has been saved in /Users/your_user_directory/.ssh/id_rsa.Your public key has been saved in /Users/your_user_directory/.ssh/id_rsa.pub.The key fingerprint is:01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db user_name@username.comThe key's randomart image is:+--[ RSA 2048]----+|     .+   +      ||       = o O .   ||        = * *    ||       o = +     ||      o S .      ||     o o =       ||      o . E      ||                 ||                 |+-----------------+

Add your SSH key to GitHub.
On the GitHub site Click “Account Settings” > Click “SSH Public Keys” > Click “Add another public key”
Open the id_rsa.pub file with a text editor (Notepad, TextEdit, or gedit will do just fine). This is your public SSH key. You may need to turn on “view hidden files” to find it because the.ssh directory is hidden. It’s important you copy your SSH key exactly as it is written without adding any newlines or whitespace. Now paste it into the “Key” field.

Problem: Delete file on remote repo

$ git add . -A
$ git commit -m "remove some file"

$ git add . -A
$ git commit -m "remove some file"

明年今日 2012-02-24 17:07 发表评论

User Story in Scrum

明年今日 — Tue, 21 Feb 2012 03:03:00 GMT

对于Scrum开发来说，User Story是开发的基础，它不同于传统的UDD开发方式，而是把原本需求拆成最小粒度的Story，以方便Scrum小组拆分Task，估计开发

时间，领取开发任务。

User Story不需要太过于详细，只有在正式开发时，做详细设计时在进入Detail阶段，如果初期时间估算不准确，实际工作量增多时，Sprint Chart需要适当的

Burn-up。

User Story可以遵循以下模板：

As a

I want to

So that I can

例如：作为一个病人，我可以预约一个医生，让他给我看病。

User Story应遵循INVEST规则：

Independent 独立性，避免与其他Story的依赖性。

Negotiable 可谈判性，Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细，开发人员可以给出适当的建议。

Valueable 有价值性， Story需要体现出对于用户的价值

Estimable 可估计性，Story应可以估计出Task的开发时间。

Sized Right 合理的尺寸， Stories应该尽量小，并且使得团队尽量在1个sprint(2 weeks)中完成。

Testable 可测试性， User Story应该是可以测试的，最好有界面可以测试和自动化测试。每个任务都应有Junit Test.

经验：

1. 永远不要在User Story中使用And和Or，因为这是些分支词就表示分支任务，把它们拆成两个Story.

2. 数据整理：通常情况下1个sprint(2周一次迭代)可以做4～5个Story，极端大的Story不可大于1个sprint。

3. 数据整理：通常情况下1个sprint(2周一次迭代)可以做50个左右的Task。

4. User Story用于描述用户故事，不要包括任何的技术，框架等内容。Task可以包括框架，技术等内容。

我们通常用User Story来描述Backlog里的各个Backlog项，User Story是从用户的角度对系统的某个功能模块所作的简短描述。一个User Story描述了项目中的一个小功能，以及>这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。

User Story要由Stakeholder（利益相关者）来编写。User Story的形式很简单，人们可以很容易地掌握编写User Story的方法。这样就可以保证是由与项目相关领域专家们来

编写User Story，而不是开发人员。

我们通常把User Story写在一张小卡片上，同时在卡片上标明它的优先级和预计完成时间，以便开发人员根据任务的优先级来制定Sprint Backlog。而且，Stakeholder可以随时更改一个Story的优先级，那么此时开发人员就应该相应地调整Story的开发次序。

一个User Story的大小和复杂度应该在一个Sprint中开发完毕为宜。如果User Story太大，可能会导致对它的开发横跨几个Sprint。这种情况是需要避免的。此时就应该将这个User Story分解。

为了能及时、高效地完成每个Story，Scrum团队会把每个Story分解成若干个Task。每个Task都是可以在明确的时间内完成的，而且时间是以小时为计量单位的。特别提示：每个Task的时间最好不要超过8小时，就是要保证1个工作日内完成，如果做计划时发现有些Task的时间超过了8小时，就说明Task的划分有问题，需要特别注意。

明年今日 2012-02-21 11:03 发表评论

BlogJava-明年今日-文章分类-Software Methodology