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
--
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