Here is a simple workflow with GIT
- Consider two environments – development and production.
- Development environment has a git repository with two branches – “dev” and “master”. “dev” is the branch for daily development use – to check-in also the half-baked code. “master” branch is used for merging “dev” branch into “master” for pushing the development changes to the production environment. Set up repository in a location that is accessible for all developers (a network share / a server that people can ssh into / a third-party service like github or bitbucket).
- Production environment has a git repository just with the “master” branch which contains the latest production code.
- Clone development environment repository onto each developer's machine and work on your local copy; After every development cycle in development environment I look at which files have been changed using “git status” and add all the changed files for commit using “git add <file>”.
- When that is done, commit the code to the “dev” branch using “git commit -m “<commit message>”". Commits are local, so you won't hurt anyone.
- After commit, just for sake of backup, push the local repository’s “dev” branch changes to the central repo by using “git push”
- When a code in “dev” branch is tested and found ready for pushing to production environment, I am merging the “dev” branch into the “master” branch in development environment using following commands: first “git checkout master”, then “git merge dev” and push the changes of master branch to the remote git server usign “git push”
- Then deploy the altered code by pulling the changes to the production environment by switching to the production environment and using “git pull” – this is pulling the code from the remote git server’s “master” branch.
- On the central repo, whenever you have a version you want to mark as release candidate, tag it. This way, you can update any given clone to that exact version later on.
References:
No comments:
Post a Comment