----- Original Message ----- 
  From: Greg Freeman 
  To: git-users@googlegroups.com 
  Sent: Monday, November 18, 2013 7:29 PM
  Subject: [git-users] GIT project maintainer as a developer

  I have an issue with my workflow that I'm trying to resolve. I am a developer 
as well as the project maintainer. We are using the "forking" workflow so 
everyone has their own repo then I pull all their changes to my copy to deal 
with the merge, then push these changes into the master. The issue I am finding 
is that because I develop as well as maintain the project (i.e. merge in other 
people's changes), I need two forks: my working copy and then a copy that I can 
merge other's changes into and push back to the master. Is this the right way 
to handle this situation? The main issue I run into with this is I can't have 
two repos with the same name so I end up with something like ProjectAbc - 
working and ProjectAbc. The latter is what I use to merge everyone's changes 
before pushing to the server (including my changes from my working copy). Am I 
handling this correctly? Is there a more elegant way to manage this?

  Also, I'm new to DVCS so excuse me if I have gotten any terminology incorrect.


While each developer will have their own 'fork', it's better to simply think of 
them has simply having their own local repository (rather than a 'special' 
fork) where they work on their various feature branches to test, develop and 
refine their bits of code. 

For you, you will have both the branches that are maintained branches, and you 
will also have your personal development branches. You merge in your own 
branches when you are happy with them in the normal review cycle.

For example, The Git maintainer has a scheme that has 4 branches. The 'master' 
branch contains the tagged releases. The 'next' branch contains expected next 
version, but may be rewound if there are sever issues, and a 'pu' (potential 
pdates) branch is an integration branch with those parts of working code the 
maintainer has felt are reasonable for everyone to have a look at. The pu 
branch gets rewound a lot as code gets reviewed and revised.

The maintainer also has his own personal branches, which he adds to pus if he's 
happy with it, in the same manner as he adds collorator contributions.

The maintainer also has a number of publishing places where users can pick 
these latest and greatest branches. You will probably also have such a store 
that you publish to (makes it look like a centralised CVS style, but that 
doesn't preclude the DVCS operations)

TL;DR There is no need for you to have a separate fork. Have a read of how the 
Git project is maintained as an example.


You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to