We use a flow that I've coined "Diposable topic branches"
It uses two main branches; master and testing
Master is the latest stable production code. Master is always
releasable and our production servers track master
Testing is our next release and should be of release quality this is
where integration testing and approval to merge that set of commits
that were tested together are merged into master. One person is in
charge of merging to master right before deploy time.
New development happens in topic branches. So I start development by
making a local branch based on testing as featurex, another pair may
start a bugfix or feature as featurey. I immediately create a remote
branch that matches and I track that remote topic branch. This remote
branch can be used for code review, collaboration and pushing the code
to one of our five continuous integration environments.
When the feature development is complete, ie product owner, qa, and
code reviewer has signed off by reviewing the new feature on one of
our test environments the developer is instructed when they can rebase
the branch against testing and merge the rebased branch into testing.
And then the topic branch is disposed of.
Qa retests testing after each commit or commits and when testing is
releasable it's tagged and merged into master as part of the deploy.
You can have many topic branches in limbo. We have long outstanding
feature branches that continue to merge testing into them to keep them
current with the main line of development but aren't yet ready
themselves and they do not block us from moving a small bugfix through
the whole process and releasing it to production.
On Feb 11, 2010, at 1:27 AM, "FlashWebHost.com" <flash...@gmail.com>
wrote:
Hi,
We are a small team of 4 programmers. So far we all worked on same
repository, only I do the commit, rest of the 3 programmers make
changes, i verify the code changes and commit. Recently there are lot
of changes in the code, i could not validate all the changes in time.
I find it difficult to validate.
Recently i installed git all on programmer computers and they studied
the basic operations. I need the programmers work on their own copy of
repo and commit them self.
We have a remote repository, setup in gitosis. If i allow everyone to
commit to it, there can be many errors or unwanted changes. Should i
create remote repository for each programmers ?
Can some one give some tips or links where i can find about managing
small project with git ?
Thanks,
Santhosh
--
You received this message because you are subscribed to the Google
Groups "Git for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com
.
For more options, visit this group at http://groups.google.com/group/git-users?hl=en
.
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/git-users?hl=en.
