Re: [git-users] Branches and workflow
I'd agree branching is all that and should be the way to do development, it's more of a question of *how many* branches you go with and being sensible about it. As your branch count proliferates then it can become more complicated to keep track of what is going on, what's being done where, etc. I'm not saying it's difficult to pull things back into line or clean up the branches once you know what you want to achieve and Git is incredible, if not sometimes almost magical, at doing that. The point is really that you have to find the branching model that fits your development process and strikes the balance between time spent in the VCS compared to getting things done and striking that balance sometimes takes a little thought and practice. You may find that as you become more proficient and comfortable with Git and branching that you would benefit from some extra branches, if so then get branching. It's all about experimentation and finding out what works for you and its a true testament to Git that it can lend itself to so many situations, to be so flexible and versatile. On Friday, May 24, 2013 3:16:37 PM UTC+1, Paul Smith wrote: On Wed, 2013-05-22 at 20:02 +0100, Roddie wrote: This is just an example. The general point is about how branches are not, in reality, completely independent, and work on one can affect another. What should I do? I have the feeling that I'm missing the point about branches. Everyone raves about them, but they seem to fail as soon as the complexity of the real world kicks in. I've read the replies here but unless I'm misunderstanding the problem they seem more complex than necessary. Yes, of course, ideally in the real world you'd have perfect foresight and every change would be self-contained and made on an individual branch and you can just use git merge to pull them together. But life is not perfect, and for sure foresight is not perfect. Suggesting that you can't use branches unless you gain such foresight, or that it's more painful to branch than not in the real world, is doing branching (and Git) a disservice. The first thing to do is get into the habit of making individual commits that constitute single, relatively atomic changes. It's not always easy to retrain yourself but it will pay off big-time. This is made a LOT easier if you have a decent front-end for Git: if you use Emacs I can't recommend magit enough for this. With the right front-end, creating commits is trivial; it will even let you choose individual patch hunks to commit while leaving the rest of the file for later commits. You can make lots of changes, then go through later and commit them in parts. If you've done that, then if you decide you need one of those commits on another branch, you can use the git cherry-pick command to trivially grab a commit from another branch and apply it to your current branch. But what if, for whatever reason, you just want the contents of a file or two from another branch, but not an entire commit? It's trivial; see this Git tip: http://jasonrudolph.com/blog/2009/02/25/git-tip-how-to-merge-specific-files-from-another-branch/ (TL;DR: use git checkout otherbranch file1 file2 ...) What if you only want parts of the other file, or the other file is changed locally so you want to merge it, not just replace it? This is also trivial, see this SO discussion (a shame no one accepted the answer :-/): http://stackoverflow.com/questions/10784523/how-do-i-merge-changes-to-a-single-file-rather-than-merging-commits (TL;DR: use git checkout --patch otherbranch file1 file2 ...) Upshot: branches definitely _ARE_ all that and you should be using them as much as possible. They do not have any problems whatsoever handling the complexity of the real world. Cheers! -- 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.
[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.
Re: [git-users] Re: 3 servers git workflow help needed: Development-Testing-Production
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.
Re: [git-users] 3 servers git workflow help needed: Development-Testing-Production
Hi, On 2013-05-24 09:33, 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) Let me give you my opinion here. I think it's a good opinion but I'll let you judge for yourself. You should have a separate fork of the repo when there is a person specifically in charge of that fork. By that I mean the person will pull new commits into the fork, and keep it maintained and published so that the next person can pull from it as and when necessary. Using this strategy it makes sense to have one public fork per developer, maybe a little less sense to have a DEV fork (who's in charge of maintaining it?), a lot of sense to have the TESTING fork (the boss is using that for testing), and finally it's probably a good idea to have a PRODUCTION fork (what we call the `blessed' repo) maintained by a release engineer or someone like that. The extreme opposite approach is to have a single repo with separate branches for each purpose (developer, testing, production) which everyone commits to. Git obviously supports this but you still have to deal with the risk of somebody pushing some commits where they shouldn't and then making a mess in the central repo. With the forks approach you don't need to worry about the production repo because the release engineer takes good care of it. How can I only push some commits and not others from DEV to TESTING? Put the commits you want to push on a separate branch and push only that branch. Or if you do decide to have one person maintaining each fork, have the TESTING maintainer pull from the DEV maintainer. HTH, Yawar signature.asc Description: OpenPGP digital signature
