4

I'm just picking up git, after years of svn and cvs. I've got the hang of most of it, but I don't feel like my common usage sequence is optimal.

My setup: I do development on my workstation with a local, cloned repository from the origin server, which on my project, is being treated like a "master" repository. I do git fetch regularly, check the new updates, then git merge to merge them if they are relevant.

However, it is when I'm working on and checking in a branch of code wherein my doubt lies.

A common sequence I use:

git branch somenewbranch
git checkout somenewbranch
... work work work ...
git add [changed files]
git commit
git checkout master
git merge somenewbranch
git branch -d somenewbranch

Here is what I think could be optimized:

git push origin master:blahblah         # This won't let me push to master branch
ssh origin
cd repodir
git merge blahblah
git branch -d blahblah
logout
git status                              # this shows me I'm still ahead
git pull origin                         # to bring them back in sync
git remote show origin                  # shows I have a stale blahblah branch
git remote prune origin                 # cleans that up

And now I've got them synchronized. This seems like a lot of extra steps to sync my local and the "master" repository.

Can someone help me optimize my usage?

Thank you.

EDIT: If I don't do the separate branch, I receive an error that states:

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
Sdaz MacSkibbons
  • 27,668
  • 7
  • 32
  • 34

2 Answers2

3

If you just use git push after you've made changes, and you are ahead of origin/master, then everything should go fine. Why are you explicitly specifying a different remote branch to push your local master branch to?

Are you having trouble pushing to your origin repository because it's complaining about a checked-out branch? If so, you are making a common mistake. You need to be using a bare repo as your origin so that Git can accept changes without causing problems with the working copy on the server.

Setting up a Private (bare) Repo

How to convert a normal Git repository to a bare one?

Community
  • 1
  • 1
coreyward
  • 77,547
  • 20
  • 137
  • 166
  • I edited my post with the error message. I think what you've described led to my confusion. The thing is, I sometimes do dev on the origin server as well, but now I think I should put all that into a bare repo, and clone it to both my local host, as well as a work dir on the origin server. – Sdaz MacSkibbons Jan 21 '11 at 01:31
  • If you need to do that, just run a quick `git clone repodir working` and when you're finished, `git push && cd .. && rm -rf working` (probably individually just to be on the safe side). – coreyward Jan 21 '11 at 01:34
  • Yep, I just created a bare repo clone, and that sorted it. Silly newb mistake. Thank you for your help; it's much easier to use now :-) – Sdaz MacSkibbons Jan 21 '11 at 01:42
1

I would suggest fetching and merging BEFORE you push to ORIGIN. If you do that, you should be able to push directly to your master branch.

Justin Soliz
  • 2,781
  • 3
  • 25
  • 33