8

I am wondering what is your procedure method of a web development using Git?

  1. When you finish coding, do you just overwrite the files on the FTP to the live server?

  2. How does git handle number of version of same project? like v1, v1.5, etc

  3. Let say 2 people working on the project locally at work (same office), how do you work together? Do I have to keep asking them to give me a source ready (save on USB?) for merge?

  4. Can two people work on the same project on the same server? Wouldn't this be easier than question 3?

Vincent Ramdhanie
  • 102,349
  • 23
  • 137
  • 192
user622378
  • 2,318
  • 6
  • 42
  • 63

3 Answers3

8

The idea behind git is that it actually takes care of all that for you.

  1. When you write code you commit your code and you can push it out to the server. Git tracks the changes so its easy to rollback to a previous version.
  2. It tracks the versions of files as they change so you can easily undo any changes that was made in the past, see tags for more details.
  3. NO. You can push your changes to the server and the other person can pull these changes. Some merging will have to occur but its quite easy with git. No need to transfer files from one dev to another. Branching and merging is discussed here.
  4. Yes. Thats the idea.

To better understand the concepts behind a distributed version control system you can read this tutorial by Joel Spolsky. It is about Mercurial, but you will find the concepts very similar and this is probably the best tutorial written about this subject on the web.

Vincent Ramdhanie
  • 102,349
  • 23
  • 137
  • 192
  • I dont understand answer 3. How do you merge codes from 2 web developers (Eg: asking them to email you?) I need source code from two developers first and I will be responsible for merging ready to push to live server? – user622378 May 03 '11 at 22:27
  • No. Git handles the merging for you. So you both check out the base code from the same repository on the server. When you are done you push your changes back to the server. The second developer attempts to pull the changes on the server, if there are clashes then git attempts to merge, or in some cases might require you to say what to do. Now the second developer has your changes. The second developer can now commit and push his changes to the server and you can pull those changes. – Vincent Ramdhanie May 03 '11 at 22:48
  • @adymitruk The idea is to understand the concept of DVCS from the tutorial. Most of the ideas are very similar. So after understanding the concepts as the OP clearly is trying to, using GIT should be straight forward. If there is a GIT tutorial that is as easy to understand why not post a link? – Vincent Ramdhanie May 04 '11 at 00:05
  • Hmm, its actually not that bad for developers to share commits directly with other developers. In fact, they can just run an ssh server so others can pull their "public" branches. ie they'd have a second repository that they push to in /srv. – alternative May 04 '11 at 00:08
  • +1 because of adymitruk's -1. I especially like how you -1 because of the guy who made this site. Nice. – alternative May 04 '11 at 00:08
0

This is how I would do it.

Each developer has his own git repository to develop his code. You as merger hold a third repository, and this repository has separate branches for each developer, for your test system and your production site.

Your developers can push their changes to you, or you can pull their changes from them into branches specifically for them. You hold a branch that you control which contains the merged code in a state for testing. You either use git-cherry-pick, or maybe just git-merge to pull their changes into your testing branch were you test things (and possibly make your own changes - or fire bug reports of to the develops and you re-incorporate their changes). When you are happy you will merge off to a "production" branch. This is normally initially derived from the test branch, but with changes necessary for the live system (I always find there is something, even if its just the database name and password).

I normally use a git hook with some code which checks which branch I am on and then uses rsync over ssh to push the code to my production site.

#!/bin/bash

branch=$(git branch | sed -n s/^\*\ //p)
version=$(git describe --tags)
cd "$git rev-parse --show cdup)"

if [ "$branch" == "production" ]; then
    echo "?php echo '$version';?>" > web/version.inc
    rsync -axq --delete web/ site:public_html/
fi
akc42
  • 4,893
  • 5
  • 41
  • 60
0

google "git flow", it shows you a way of managing work and releasing when you want.

For deploying via a branch, see:

Deploy a project using Git push

Community
  • 1
  • 1
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141