Re: Integration-Manager Workflow

Adrián Ribao Martínez writes:

quoted

Adrián Ribao Martínez writes:

quoted

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

quoted

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