From: Michael Poole <mdpoole@troilus•org>
To: "Adrián Ribao Martínez" <aribao@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: Integration-Manager Workflow
Date: Sat, 16 Jan 2010 21:53:44 -0500 [thread overview]
Message-ID: <87my0dwifb.fsf@troilus.org> (raw)
In-Reply-To: <201001162047.38010.aribao@gmail.com> ("Adrián Ribao Martínez"'s message of "Sat, 16 Jan 2010 20:47:37 +0100")
Adrián Ribao Martínez writes:
>> Adrián Ribao Martínez writes:
>>
>> > What happens if they accidentally work in the develop branch instead of creating a new one? What should we do?
>> > I think I should never fetch from teamx.myserver.net to avoid this problem and instead track the branch like in step 2. Is this correct?
>>
>> It is simpler than that.
>>
>> If you just use "git remote add teamx teamx.myserver.net:/...." (rather
>> than cloning your integration repository from one of those
>> repositories), it will leave all your local branches alone -- any
>> changes to teamx.myserver.net's "develop" branch will only show up in
>> the teamx/develop tracking branch.
>
> I think this is a stupid question but, how do I bring the feature1 branch from teamx to my local repository?
In brief, "git fetch teamx" -- it will copy that repository's branches
into "tracking" branches. In your repository, they will be named like
teamx/develop, teamx/test, teamx/feature, and so on.
When you run the "git remote add teamx ${location}" command, it creates
a section in .git/config that looks like this:
[remote "teamx"]
url = ssh://teamx.myserver.net/home/teamx/product.git
fetch = +refs/heads/*:refs/remotes/teamx/*
This tells git to copy the remote branches to tracking branches; it will
not overwrite any of your own branches. You can later add "push"
entries to this section to change the default behavior for "git push
teamx". For example, adding:
push = refs/head/develop
push = refs/head/test:refs/head/test
push = +refs/head/master
These all tell git to push your local branch (develop, test or master)
to the same branch name in the teamx repository. The + in the last line
says to push even when it is not a fast-forward. (The "<refspec>"
section of the git-push man pages has more discussion of the syntax.
Using these push entries makes sure that you don't accidentally modify a
feature branch on the team's repository.)
>>
>> The reason is that a fetch or pull only merges into your develop branch
>> if your branch.develop.merge git-config entry specifies an upstream
>> branch -- more detail can be found in the git-config man page under
>> branch.<name>.remote and branch.<name>.merge.
>>
>> Those entries are set up when you clone from a repository, and through
>> some other commands, but if teamx clones from the integration server,
>> they can only mess up their own develop branch. If/when you push into
>> teamx's repository from yours, you can forcibly overwrite any of those
>> accidental changes. (Normally, though, the push would only do a
>> fast-forward merge -- so if teamx made such a mistake, the merge will
>> fail until you address the mismatch.)
>
> I'm not sure if I understand.
The process you listed looks workable, although I would swap 2 and 3 to
save commands when the change is good (with no extra commands if the
change is bad). In addition, merging first will find merge conflicts
before you do any verification.
> 1. I bring the feature1 to my local repository.
git fetch teamx
> 2. Check if everything is ok
git checkout teamx/feature1
make clean test (or whatever is appropriate)
> 3. Merge or rebase the branch into develop
git checkout develop
git merge teamx/feature1
If I were to swap the two steps above, I would make sure I was on the
develop branch, and then run:
git merge teamx/feature1
make clean test
If the check-out fails, "git reset --hard HEAD^" will back up to the
first parent commit -- in this case, the previous tip commit for
"develop". If the check passes, the rest of the process is the same.
> 4. Push the develop changes into the in central repository
git push central develop
> 5. Push and force the develop changes into the teamx server
git push teamx develop
> 6. The developers pull their local repositories from teamx server
git pull teamx
Hopefully this helps explain things.
Michael Poole
prev parent reply other threads:[~2010-01-17 2:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-16 17:49 Integration-Manager Workflow Adrián Ribao Martínez
2010-01-16 19:06 ` Michael Poole
2010-01-16 19:47 ` Adrián Ribao Martínez
2010-01-17 2:53 ` Michael Poole [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87my0dwifb.fsf@troilus.org \
--to=mdpoole@troilus$(echo .)org \
--cc=aribao@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox