Re: Integration-Manager Workflow

[Michael Poole <mdpoole@troilus.org>]

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