4 ms·

A web-focused Git workflow

42 points by kqr2 17y ago

vog 17y ago
If "git push" would work properly for non-bare destinations (as it is the case with e.g. Mercurial and also Darcs), the design could be simplified by merging "hub" and "prime".
- cookiecaper 17y ago
  I guess I don't know how it works on hg or darcs, but I appreciate the bare repositories and git's reluctance to push on top of a checked-out working copy. It's not too hard to add hooks that make things automatic if one is so inclined, as we see in this case. As for me, I just type the extra "git pull" or "git push". It's not a big deal for my use case right now, though if it were I know it's fairly simple to add hooks that automatically pull changes into your running copy ("Prime"), though I'm not sure I want that. I like pushing to the hub and controlling when those changes get rolled out without having to maintain a ton of different branches.
  - vog 17y ago
    Unfortunately, it's not just a hook. It's a whole new repository clone just to maintain a checked-out working copy. The whole synchronization process between them is simply unnecessary. BTW, in Mercurial it is indeed just a hook. And in Darcs even that hook isn't needed. And FWIW, Mercurial can handle bare repositories, too.
- windsurfer 17y ago
  You can actually add a git hook or two to make pushing work fine for non-bare destinations - but then you're trashing any local changes.
  - vog 17y ago
    That's why I'm calling it a bug in Git. Other tools (Mercurial, Darcs) don't trash anything.
    - windsurfer 17y ago
      Its a few more lines to prevent trashing.
      - vog 17y ago
        That's true, but unfortunately, trashing is the default. Without any hooks, the next "git commit" on the remote system would add a patch that reverts the uploaded changes. This is very contra-intuitive and could be the source of big mistakes. It's a really nasty trap if you don't watch out! I like more the approach of Marcurial and Darcs where "not trashing" is the default.
- thenduks 17y ago
  Because it would be a good idea to push directly to live websites? This is a feature.
  - vog 17y ago
    The original article wants to do exactly that, so it would profit from a better-designed "git push". Also, Git was never designed for minimalism, but rather for feature-completeness. In contrast, Mercurial was designed with a minimalistic approach (as least in the beginning), so I find it especially strange that Mercurial provides a proper "push" but Git doesn't.
    - thenduks 17y ago
      Just because git gives you a method (hooks) to do stupid things doesn't mean they should be built into it. Pushing to a live site (or even just the implied case of pushing into a non-bare repo) is a bad idea. If you want to use hooks (or you own script, or scp, or whatever) to do it you can.
      - vog 17y ago
        The two generalizations 1) "Pushing to a live site is a bad idea." 2) "Pushing into a non-bare repo is a bad idea." both don't hold. Regarding 1): It depends on how well-tested the code you're pushing is. Also, conceptually it doesn't matter whether you deploy by pushing to the live system, or by triggering a script on the live system which pulls from the test system. Both achieve exactly the same, so both are equally good or bad. However, the push is more comfortable. Regarding 2): I have a scenario at home where such a push makes a lot of sense. There is a stationary computer and a laptop, both of which have a common document repository (using Mercurial). Synchronization happens when the laptop is at home. It's just "hg pull -u ; hg push". The laptop needs access to the stationary computer, but not vice versa. If I avoided the push, I'd have to trigger a script on the stationary computer which in turn pulls from the laptop. Net result: One more script and one more communication channel, i.e. more work and less security. So please be careful with exaggerated generalizations.
diN0bot 17y ago
if i understand the post correctly, then i'm using github as the hub, with copies checked out locally and on the web server. whoa--- how else do people deploy to live sites? i can't imagine not using version control. or am i missing some nuance of the situation?
- prodigal_erik 17y ago
  "yum install". We write a .spec file for each service we deploy, and when we're ready to deploy we compile and package the current release branch. That way the OS package manager knows what's installed where, whether any dependencies also need to be installed or upgraded, and whether local edits should be preserved or renamed. I've never understood how "git pull" is supposed to configure a production server correctly. What do people do, put /usr/bin and /usr/lib64 and /etc in git?
  - vog 17y ago
    Although it is usually not done with /usr/*, it is quite common to put a server's /etc under version control. But that's for administrative control, and is usually completely separate from the web application. However, it is quite common to use rsync for deployment of everything: system, application, etc. from test to production, without any version control needed. This works especially well when using vservers.
  - diN0bot 17y ago
    i'm just updating a web app in /var/sites. git pull followed by an alias to a few commands to rebuild templates and reload the server. i guess there are at least two views of updating web servers: the servers themselves and the web application. the latter is a lot more self contained. i forgot about the former. i set that up once, backed it up, and pray that i don't have to touch it again :-p

42 points by kqr2 17y ago

vog 17y ago

If "git push" would work properly for non-bare destinations (as it is the case with e.g. Mercurial and also Darcs), the design could be simplified by merging "hub" and "prime".

cookiecaper 17y ago
I guess I don't know how it works on hg or darcs, but I appreciate the bare repositories and git's reluctance to push on top of a checked-out working copy. It's not too hard to add hooks that make things automatic if one is so inclined, as we see in this case. As for me, I just type the extra "git pull" or "git push". It's not a big deal for my use case right now, though if it were I know it's fairly simple to add hooks that automatically pull changes into your running copy ("Prime"), though I'm not sure I want that. I like pushing to the hub and controlling when those changes get rolled out without having to maintain a ton of different branches.
- vog 17y ago
  Unfortunately, it's not just a hook. It's a whole new repository clone just to maintain a checked-out working copy. The whole synchronization process between them is simply unnecessary. BTW, in Mercurial it is indeed just a hook. And in Darcs even that hook isn't needed. And FWIW, Mercurial can handle bare repositories, too.
windsurfer 17y ago
You can actually add a git hook or two to make pushing work fine for non-bare destinations - but then you're trashing any local changes.
- vog 17y ago
  That's why I'm calling it a bug in Git. Other tools (Mercurial, Darcs) don't trash anything.
  - windsurfer 17y ago
    Its a few more lines to prevent trashing.
    - vog 17y ago
      That's true, but unfortunately, trashing is the default. Without any hooks, the next "git commit" on the remote system would add a patch that reverts the uploaded changes. This is very contra-intuitive and could be the source of big mistakes. It's a really nasty trap if you don't watch out! I like more the approach of Marcurial and Darcs where "not trashing" is the default.
thenduks 17y ago
Because it would be a good idea to push directly to live websites? This is a feature.
- vog 17y ago
  The original article wants to do exactly that, so it would profit from a better-designed "git push". Also, Git was never designed for minimalism, but rather for feature-completeness. In contrast, Mercurial was designed with a minimalistic approach (as least in the beginning), so I find it especially strange that Mercurial provides a proper "push" but Git doesn't.
  - thenduks 17y ago
    Just because git gives you a method (hooks) to do stupid things doesn't mean they should be built into it. Pushing to a live site (or even just the implied case of pushing into a non-bare repo) is a bad idea. If you want to use hooks (or you own script, or scp, or whatever) to do it you can.
    - vog 17y ago
      The two generalizations 1) "Pushing to a live site is a bad idea." 2) "Pushing into a non-bare repo is a bad idea." both don't hold. Regarding 1): It depends on how well-tested the code you're pushing is. Also, conceptually it doesn't matter whether you deploy by pushing to the live system, or by triggering a script on the live system which pulls from the test system. Both achieve exactly the same, so both are equally good or bad. However, the push is more comfortable. Regarding 2): I have a scenario at home where such a push makes a lot of sense. There is a stationary computer and a laptop, both of which have a common document repository (using Mercurial). Synchronization happens when the laptop is at home. It's just "hg pull -u ; hg push". The laptop needs access to the stationary computer, but not vice versa. If I avoided the push, I'd have to trigger a script on the stationary computer which in turn pulls from the laptop. Net result: One more script and one more communication channel, i.e. more work and less security. So please be careful with exaggerated generalizations.

diN0bot 17y ago

if i understand the post correctly, then i'm using github as the hub, with copies checked out locally and on the web server. whoa--- how else do people deploy to live sites? i can't imagine not using version control. or am i missing some nuance of the situation?

prodigal_erik 17y ago
"yum install". We write a .spec file for each service we deploy, and when we're ready to deploy we compile and package the current release branch. That way the OS package manager knows what's installed where, whether any dependencies also need to be installed or upgraded, and whether local edits should be preserved or renamed. I've never understood how "git pull" is supposed to configure a production server correctly. What do people do, put /usr/bin and /usr/lib64 and /etc in git?
- vog 17y ago
  Although it is usually not done with /usr/*, it is quite common to put a server's /etc under version control. But that's for administrative control, and is usually completely separate from the web application. However, it is quite common to use rsync for deployment of everything: system, application, etc. from test to production, without any version control needed. This works especially well when using vservers.
- diN0bot 17y ago
  i'm just updating a web app in /var/sites. git pull followed by an alias to a few commands to rebuild templates and reload the server. i guess there are at least two views of updating web servers: the servers themselves and the web application. the latter is a lot more self contained. i forgot about the former. i set that up once, backed it up, and pray that i don't have to touch it again :-p