[git-users] Re: help - pushes not reflected on remote origin
On May 7, 8:34 am, Matt Palermo mpale...@vt.edu wrote: I have a server where I setup a git repo. I cloned it on my local dev machine. I add and delete some files and commit them on my local repo. Then I push the commit to the server origin repo. All the files I deleted in the local repo still appear in the server repo structure, and all the files I added in my local repo do not appear on the server structure. I open up gitk on the server repo and it shows that my local commit was pushed to the server. It lists all the files that I added/deleted, but nothing is reflected in the server folder structure. It looks untouched. Am I doing something wrong here? How can I get my local commit pushes to change the server repo structure? Most probably your workflow is broken: https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F -- 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.
Re: [git-users] Re: help - pushes not reflected on remote origin
On Fri, May 7, 2010 at 11:31 AM, Matt Palermo mpale...@vt.edu wrote: Okay, maybe someone can give me advice for the best way to accomplish this... I have a team of developers (myself included) for a PHP website. I also have a design team. On the main webserver I want to setup the live site where all tested code will go. Then for each developer on the team, I want to have another site on the server where that developer can work and we can all see his development in progress. The design team will also have their own site on the server. So it would be something like this: - Server http://site.com/live (live site with only tested/approved code) http://site.com/dev1 (test site for developer 1, which is a clone of the live site) http://site.com/dev2 (test site for developer 2, which is a clone of the live site) http://site.com/design (test site for design team, which is a clone of the live site) So the way I've tried to implement it is this... Setup a main bare repo. Then have clones of the main repo for live, dev1, dev2, design all in their respective webroot folders. Then let's say dev1 makes a change that is tested and ready to go live... I will go to the server into the dev1 repo and push it to the main repo. Then I will go to the live repo and pull the changes to it. All devs will be able to clone their server dev repo to their local machine and work from there. However, I want their server dev repo to be as current as possible so that I can go to the server site for them and see the latest changes. So if developer 1 makes changes on his local clone, then he will commit the changes and push them to the server dev repo so that the entire team can view the changes on the server site. The problem I'm running into is that when the dev pushes commits to the server, the server dev repo working files/folders don't reflect the changes that were pushed to it. Therefore I can visit the dev1 site after a commit was pushed to it and it will look/work the same as before the push. I need to always keep the dev sites current with the latest changes. Should I be doing something different in my workflow? Does anyone have any advice on setting up a system to work this way? Thanks, Matt Why are you pushing from the server(s). I'd set up a main git repository somewhere, probably on github. Have the developers clone this and push changes, use branches to control production vs. staging. Then to deploy to a server have it checkout a specific branch and pull. I don't know about php apps, but this is the way things are normally done with Rails. Most Rails developers use a tool named capistrano to deploy, which has recipes for fetching code from git, rolling back changes... There's probably something similar for php apps. As a matter of fact it appears that some folks are using capistrano for php deployment http://www.google.com/search?q=capistrano+deploy+php Having a separate staging server for each developer seems to be overkill to me, most of the projects I've worked on have the developers run code on their own development machines, and one staging server where code not ready for production can be deployed for manual acceptance testing, or review or ... But I guess there's no reason why you couldn't do that. HTH -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- 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.
[git-users] Re: help - pushes not reflected on remote origin
On May 7, 7:31 pm, Matt Palermo mpale...@vt.edu wrote: Okay, maybe someone can give me advice for the best way to accomplish this... I have a team of developers (myself included) for a PHP website. I also have a design team. On the main webserver I want to setup the live site where all tested code will go. Then for each developer on the team, I want to have another site on the server where that developer can work and we can all see his development in progress. The design team will also have their own site on the server. So it would be something like this: - Serverhttp://site.com/live (live site with only tested/approved code)http://site.com/dev1 (test site for developer 1, which is a clone of the live site)http://site.com/dev2 (test site for developer 2, which is a clone of the live site)http://site.com/design (test site for design team, which is a clone of the live site) So the way I've tried to implement it is this... Setup a main bare repo. Then have clones of the main repo for live, dev1, dev2, design all in their respective webroot folders. Then let's say dev1 makes a change that is tested and ready to go live... I will go to the server into the dev1 repo and push it to the main repo. Then I will go to the live repo and pull the changes to it. All devs will be able to clone their server dev repo to their local machine and work from there. However, I want their server dev repo to be as current as possible so that I can go to the server site for them and see the latest changes. So if developer 1 makes changes on his local clone, then he will commit the changes and push them to the server dev repo so that the entire team can view the changes on the server site. The problem I'm running into is that when the dev pushes commits to the server, the server dev repo working files/folders don't reflect the changes that were pushed to it. Therefore I can visit the dev1 site after a commit was pushed to it and it will look/work the same as before the push. I need to always keep the dev sites current with the latest changes. While Rick's suggestion sounds more sensible, your proposed workflow involving pushing to non-bare (devN) repos can actually be done using hooks -- you just missed the last bits of that FAQ entry. A working sample of such hook can be found in [1] for instance (also don't miss the article it refers to). 1. http://groups.google.com/group/git-users/msg/c136097332748b1c?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.
[git-users] Re: 'v' prefix on version tags
On May 7, 7:57 am, Konstantin Khomoutov khomou...@gmail.com wrote: On May 7, 12:51 am, Trans transf...@gmail.com wrote: I notice that almost every tagging example uses a version number with a prefixed 'v', e.g. $ tag -a -m first major point release v1.0.0 I, on the other hand, have never bothered with 'v' prefix, and have always done, e.g.: $ tag -a -m first major point release 1.0.0 Is there some reason to use the 'v' that I am unaware? Am I going to have issues on other platforms or something? I beleive this is just a question of aesthetic preferences. The only things tag tames might clash with are other commit-ish names such as names of branches or objects (those hashes composed of hex numbers), so both 1.0.0 and v1.0.0 have the same chances to clash with other names. Cool. Thanks. I feel better about it. -- 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.
