git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Integration-Manager Workflow

From
MPMichael Poole <mdpoole@troilus.org>
Date
Jan 17, 2010, 02:53 UTC
Message-ID
<87my0dwifb.fsf@troilus.org>
In-Reply-To
<201001162047.38010.aribao@gmail.com>
Adrián Ribao Martínez writes:
Show 14 quoted lines
>> 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.)

Show 15 quoted lines
>> 
>> 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
Previous: Adrián Ribao Martínez
Message 4 of 4 in “Integration-Manager Workflow”
  1. Adrián Ribao MartínezJan 16, 2010
  2. Michael PooleJan 16, 2010
  3. Adrián Ribao MartínezJan 16, 2010
  4. Michael PooleJan 17, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.