Re: Question re. git remote repository

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

 



On Fri, 18 Jan 2013, Junio C Hamano wrote:

David Lang <david@xxxxxxx> writes:

What I would do is to have each developer have their own local copy
that they are working on.

I would then find a machine that is going to be on all the time (which
could be a developer's desktop), and create a master repository
there. Note that if this is on a developers desktop, this needs to be
a different repository ... from
what they use to do their work.

developers then do their work locally, and after a change has been
reviewed, pull it into the master repository.

s/pull it into/push it into/; I think.

fair enough, I always think in terms of pulling from feature branches into the main repository so that any merge conflicts get resolved. I didn't describe this clearly enough.

Junio, is there a really good place we should be pointing David where the different workflows are described and explained?

for David

After the work is completed in the feature branches, you now have the problem of how to combine this work in with whatever other work has taken place in the meantime.

One common way to do this is to pull from the feature branch into the main tree. If there are conflicts, git will help you identify them and resolve them (note that some changes will not produce conflicts that git detects, but can still result in non-working code)

developers can (and should) do a dry run on this if significant changes have happened in the master. Create a new throw-away branch of the master tree and merge your feature branch into that tree and see what happens. If everything works, you are good to go. If you have massive conflicts, it may be worth doing work to avoid the conflicts and then submit the result of that to the master (also known as upstream)

With only two developers, you can have each of them do the merge work on a temporary branch and then push the results upstream to the master, or you can have one of them 'change hats' to be the release manager and work from the point of view of the master to pull the changes in)

David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]