Re: Integration-Manager Workflow
- From
- Michael 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/masterThese 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