You can always have a look at how git itself is 'managed' in terms of its
branches that Junio (maintainer) integrates. That is, he has lots of
sub-branches for each contributer's patch series that are merged into 'pu'
(potential updates) at various points (and rewound when they are updated or
ejected)
It does take a while to get used to the distributed nature of git, and perhaps
the need to split [big] projects into its smaller managable constituent
projects (but avoid git subprojects at the start, they are best seen as slow
development library projects).
Being distributed, individual developers can have their own branches to do
their own 'try out' tests before a final nice pretty branch is submitted [*] to
your upstream. You are likely to also provide them with a server area for their
personal branches to act as backup (it maybe separate personal repos, or a
ref/dev/ namespace.
[*] Deciding how that submission process is managed is the core question, e.g.
see git help workflow(7).
Once you get used to committing often, very often, (to your local feature
branch which you can later tidy before publishing) it becomes easier.
- Original Message -
From: Bruno Cassol
To: git-users@googlegroups.com
Sent: Friday, May 24, 2013 7:21 PM
Subject: [git-users] Re: 3 servers git workflow help needed:
Development-Testing-Production
Thanks for your reply!
We are currently not using branching in git. Perhaps that's why I tried to
map different branches in different servers/repos in my mind.
I'm afraid the team lacks experience with distributed version control in
general.
I guess we will need to sit down and learn git so we can do something like
this: http://nvie.com/posts/a-successful-git-branching-model/ right?
On Friday, May 24, 2013 10:25:45 AM UTC-4, Alex Lewis wrote:
If I've understood correctly, rather than pushing specific commits it might
be better to have the developers working on feature branches and those features
only get merged into a development/integration branch when they're ready for
release. Then you would push the development/integration (or a release branch
created from integration/development) from DEV to TESTING and then from TESTING
into PRODUCTION for actual release.
It might help if you describe the branching process you follow between the
DEVELOPERS and DEV repo as that might influence what you push into TESTING,
PRODUCTION, etc.
Probably pushing specific commits will end up in problems although I could
be wrong and other's may disagree with me.
On Friday, May 24, 2013 2:33:24 PM UTC+1, Bruno Cassol wrote:
Hi,
we have the following setup and I would like advice/help. I'm not even
sure if this the correct setup.
DEVELOPERS WORKSTATIONS (Windows/TortoiseGit)
c:\xamp\htdocs\intranet/
|
| push / pull
V
DEV (CentOS/ssh)
/home/git/repos/intranet/ (bare)
/var/www/html/intranet/ (working/apache)
|
| push
V
TESTING (CentOS/ssh) --- Boss tests the system here
/home/git/repos/intranet/ (bare)
/var/www/html/intranet/ (working)
|
| push
V
PRODUCTION (CentOS/ssh)
/home/git/repos/intranet/ (bare)
/var/www/html/intranet/ (working)
How can I only push some commits and not others from DEV to TESTING?
I also have to think about automating MySQL schema changes. We use PHP
(Zend framework) and MySQL.
Is there a better approach?
--
You received this message because you are subscribed to the Google Groups
Git for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an
email to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3343 / Virus Database: 3184/6353 - Release Date: 05/24/13
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
