git usage conventions

 git  No Responses »
Aug 302011
 

We’ve been using git at work for a greenfield project and, so far, this has worked for us. It could be a useful template to get another team started.
We have gotten rid of the name ‘master’, which is only a convention anyway, and instead are using a few permanent branches:

  • production (only stable code which gets deployed to production goes there. The only branch to be merged in, EVER, is ‘stable’)
  • stable (only stable code which goes to the staging environment goes there. The only branch to be merged in, EVER, is ‘integration’))
  • integration (code from other branches goes here – tests should, of course, pass before merging in.)

And then we have, of course, other branches for work in progress and other stuff. we’ve used these prefixes to help with the naming, and called this the ‘buffers’ convention (look at the first letters – BFRS):

  • bug_
  • feature_
  • refactor_
  • spike_
How have you organized your git repositories?
 Posted by at 12:46 pm  Tagged with:

Github’s customer service: bad review

 technology  6 Responses »
Mar 122010
 

I will readily admit that I don’t know all that much about Github or Git for that matter. I use them, they’re handy, and that’s where it stops. I read about a git feature called “smart HTTP”, which would allow to communicate both ways with git (push and pull) with HTTP or HTTPS. So, I asked Github about it – it would be nice for them to have this feature, because I currently can’t push to Github from work. Here’s how the exchange went.
(this first message is from memory, as I used the web interface, so I don’t have a copy of it)
Me:
Hi, I just read about this: http://progit.org/2010/03/04/smart-http.html and I would like to know when Github plans on implementing this, because it would be very useful.
_______
From: Tekkub (Support staff)
Subject: [Contact] Upgrading git to support smart HTTP ?

You do know that Scott (the guy who wrote Pro Git) works for us, right? We’re well
aware of smart http…
_______
I tried to make light of the condescending tone and sent the following reply:
Me:
Nope.. Had no idea.
So when will it be implemented? ;)
_______
From: Tekkub (Support staff)
Subject: [Contact] Upgrading git to support smart HTTP ?

It will be implemented when it is…
_______

That’s when I just gave up. I don’t know if whoever handles the messages is paid or not, but I’m pretty sure Github pays its employees by now. I’m using a free account, so they wouldn’t lose anything by me leaving them, and they do provide a great service.
Am I just being picky when I expect the support staff to be polite? I say this as someone who has worked as support staff for over three years: no. The support staff SHOULD, nay, MUST be polite. I don’t care how flat your company hierarchy is, I don’t care how young or forward-thinking the company is, and I especially don’t care if your target audience is Asperger’s syndrome-suffering programmers who laugh at Star Trek jokes and read slash fiction. You’re the support, you’re polite. Especially over a medium like text, where you can’t easily place a slap on the shoulder, a grin and a wink.

This has left a bad taste in my mouth.

Git : moving a remote branch

 programming  No Responses »
Dec 292009
 

One can’t actually move a remote branch, but you can copy a branch and delete a branch, so…

Copy oldbranch in repo to newbranch.

git push {repo} {oldbranch}:heads/{newbranch}

Ex: git push origin foobranch:barbranch
renames foobranch to barbranch

Remove a remote branch: it’s all about the colon:

git push <remote_repo> :heads/<branch>

Example: git push origin :heads/some-branch removes some-branch from the remote repo (apparently git push origin :some-branch works as well).

This works for removing a tag as well: git push origin :sometag

%d bloggers like this: