[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP-PROP 12: keep master in ready-to-release state

From: Reinhold Kainhofer
Subject: Re: GOP-PROP 12: keep master in ready-to-release state
Date: Wed, 14 Sep 2011 12:21:18 +0200
User-agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.0; i686; ; )

Am Wednesday, 14. September 2011, 11:26:11 schrieb Janek Warchoł:
> 2011/9/14 Graham Percival <address@hidden>:
> >> >This could reduce the pain of git master getting broken from time
> >> >to time – if everybody worked on separate branches, and those
> >> >branches were only pulled to master when it compiled correctly,
> >> >then master would never be broken! In theory, at least.
> >> 
> >> I'm pretty sure most developers do their work in
> >> separate branches anyway, albeit on local branches.
> > 
> > I'm not at all certain about that
> I do all my work in separate branches; nothing ever touches master
> unless it's being pushed.  Currently i have 12 branches and i don't
> remember when i had less than 5.  Having things flying in master
> causes trouble :)

Same situation here. I'm even working on three different computers (one office 
machine, one laptop at home and one netbook) with different branches and 
developments, where I fetch from each other regularly. I currently have 10 
branches on one machine, and about the same on the laptop.

git is not complicated at all, once you have grasped the basics. Branches are 
a very normal and easy thing, and switching between them, creating them or 
fetching/pulling from some other remote is extremely easy.

And now that I have learnt of "git stash", it makes life even simpler (but a  
bit harder to understand how to use it and what it is).

> > I'm not saying that I can't learn, and if the proposal is accepted
> > I certainly *will* learn.  But right now I don't have the
> > familiarity with git to be comfortable with making

git checkout -b NEW-BRANCHNAME origin/master

> > +merging branches, 

I usually don't merge, but first rebase to origin/master and then push that to 
the server:

git fetch origin                      # to have the latest commits available
git rebase origin/master YOUR-BRANCH-NAME  # This also checks out the branch!
git push origin HEAD:master           # Pushes current state as origin/master

> > with only pushing changes from one branch, etc.

If LOCALBRANCH=REMOTEBRANCH, it can be written as:
  git push origin LOCALBRANCH

> > I'm pretty certain that Janek and Phil are in the same situation.
> I haven't figured out how to push stuff from a local non-master branch
> to remote master, 

Either (in this case LOCALBRANCH does not even need to be checked out!)
   git push origin LOCALBRANCH:master
or if the current state (the current checkout) should be pushed as master, you 
don't have to name the local branch. HEAD describes the current state of you 
local checkout:
   git push origin HEAD:master

Reinhold Kainhofer, address@hidden,
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 *, DVR: 0005886
 * LilyPond, Music typesetting,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]