I want to deploy from git to production. In that case, should I simply be cloning from git?
I know that clone duplicates the history of the project, which I don't really need in a production environment. Is there a better approach?
You could also use git archive to create a tar-file just containing the files of the commit you select and extract it in your production environment. I prefer cloning, since this makes later updates a lot easier (you can just git fetch, look what you'll have to adjust to make the update work and git merge). This safes a lot of trouble than doing git archive again, moving the old tree, extracting the new one, finding differences between old and new, adopt configuration changes etc., …
Clone to temp folder and then rsync to desired location excluding whatever you wish.
You can simply create a branch for deployment and push your updates to it whenever you wanna deploy, check this article here.
I used to have a node.js script that handled deploying code, but it became unwieldy to manage once I had more than one project with specific requirements. I recommend using https://stackahoy.io/ (Warning: I'm on the Stackahoy team and would be happy to answer any Q's.). It's totally free for 1 repo and unlimited branches. It allows you to:
Maintain deployments for your git repositories in one place
Maintain static configuration files (stuff you keep in the .gitignore file)
Preform post-deployment scripts
Securely and instantly deploy your code based on the branch that was pushed and see real-time logs as it deploys.
Deploy to multiple servers at once (good for load-balanced applications)
Related
When a team work on a Laravel project, they usually edit route file, the same controllers and views. Resulting in thousands of merging conflicts. And resolving them is time consuming. Is there a way of preventing these conflicts?.
What is git?
Git is a mature, actively maintained open source project. A staggering number of software projects rely on Git for version control, including commercial projects as well as open source. Git is an example of a DVCS (hence Distributed Version Control System). Rather than having only one single place for the full version history of the software as is common in the once-popular version control systems like CVS or Subversion (also known as SVN), in Git, every developer's working copy of the code is also a repository that can contain the full history of all changes.
In addition to being distributed, Git has been designed with performance, security and flexibility in mind.
When to use git?
For example, say a developer, Alice, makes changes to source code, adding a feature for the upcoming 2.0 release, then commits those changes with descriptive messages. She then works on a second feature and commits those changes too. Naturally, these are stored as separate pieces of work in the version history. Alice then switches to the version 1.3 branch of the same software to fix a bug that affects only that older version. The purpose of this is to enable the Alice's team to ship a bug fix release, version 1.3.1, before version 2.0 is ready. Alice can then return to the 2.0 branch to continue working on new features for 2.0 and all of this can occur without any network access and is therefore fast and reliable. She could even do it on an airplane. When she is ready to send all of the individually committed changes to the remote repository, Alice can "push" them in one command.
What are the advantages of git?
Git has a lot of usage and advantage but few are below that may clear to you when and why to use git
Git is a version control system or stagging for open source project. You can control your project by creating version step by step.
If an issue has been aroused after changes it is possible in git to restore a previous version to ignore all those changes and bugs.
We create a project on git as origin master and then make clones in different machines when working as a team project. When we 'push' our changes from different clones on different machines git merge all those changes in one origin master. So we don't need to bother about how to merge changes from different clones in one project folder.
How to resolve merge conflicts in git?
May this be help full to you to understand how to solve easily merges conflicts problem in git. The best tool for this purpose is git-mergetool Run merge conflict resolution tools to resolve merge conflicts in git projects.
Use git mergetool to run one of several merge utilities to resolve merge conflicts. It is typically run after git merges.
If one or more parameters are given, the merge tool program will be run to resolve differences on each file (skipping those without conflicts). Specifying a directory will include all unresolved files in that path. If no names are specified, git mergetool will run the merge tool program on every file with merge conflicts.
Backup in git mergetool git mergetool creates *.orig backup files while resolving merges. These are safe to remove once a file has been merged and its git mergetool session has completed.
Setting the mergetool.keepBackup configuration variable to false causes git mergetool to automatically remove the backup as files are successfully merged.
For further study about git mergetool please see the link:
https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/merge-conflicts
I think this may be helpful to you.
Yes GIT is a good solution for a large project. But you have to deal the route or any common file on which more than one person is working so that the merge conflict are minimum. On any common file make different code block like:
/* Block 1 Start */
/* Block 1 End */
/* Block 2 Start */
/* Block 2 End */
and put all the related functionality inside these blocks, so that the conflict are minimum and when it occurs, it is easy to resolve the conflict as the blocks are divided.
It happens in almost every project when using git , we all face these situations like working on same files which result in merge conflicts but on the other hand we all team members have a synced code at the end of the day. Also as an alternative to avoid multiple merge conflicts in each pull , you can make your branches and then push your code to your respective branches. In this way there will be merge conflict only when you merge these branches to your main branch. This is just my opinion that GIT is the best tool when it comes to project management.
You could also try adding comments section in your file if you don't want to create that many branches.
I'm a total newbie to this Git.
My PHP project files have been added to Git by admin.
Now one new person is going to start working on this project. He will work on one module of this project. So, being a senior developer I've been asked to create a branch for him that will contain only specific files that he will need to start work on the specific module.
So this thing has created so many questions in my mind :
Can I create a special branch for him with only specific/selected files from the project? If yes, how? If no, why?
Now only master branch of project is present. If the new branch of git is created for the new developer and he commits and pushes the changes he made to the git; how will they get merged with the master branch? Do I need to do it manually using third party tool like 'DeployHQ' or anything like or is there any way around.
To keep the things easy for him what I want to do is he should be able to commit, push the changes, those changes would straight away be reflected on server and he should be able to check it by running the pages in a browser. Can I make the this simple and easy as I'm thinking.
In a nutshell I don't want to disclose all of my project files to him and want to keep things easier and simpler for me as well as for him.
Please please please guide me.
Thanks.
The basic building block of GIT version control is project. You can't branch off only some files from the master as it doesn't make any sense in an environment where projects are the single version controlled entities.
You can add or remove files from a branch and later commit to the master with the changes.
Some people refer to the branching model in Git as its “killer
feature” , and it certainly sets Git apart in the VCS community. Why
is it so special? The way Git branches is incredibly lightweight,
making branching operations nearly instantaneous and switching back
and forth between branches generally just as fast. Unlike many other
VCSs, Git encourages a workflow that branches and merges often, even
multiple times in a day. Understanding and mastering this feature
gives you a powerful and unique tool and can literally change the way
that you develop.
This question seeks to isolate factual differences between two approaches to deployment, not subjective. Review the list at the end for concrete concepts.
I'm currently looking at options for deploying my app from wherever it's built. I've been reading a lot about and am familiar with how git is sometimes used for deployment. I've also seen how you can simply create a tar.gz of the desired files and then ship that out to the server.
The more I think about this, the more I feel like simply scripting the creation and send of the archive is simpler and is "more static" than depending on git for deploy.
The main factors so far that have me favouring a simple archive are:
The destination doesn't have to have git or any other tools installed
I don't have to set up any special keys for dependency checkout on the destination
When using git, the deployed repository will always be larger than the actual deployed code
I'll have one less git repository to muddle with keeping consistent
In my specific case, I also have dependencies that are built or retrieved outside of the git repository (composer, bower, grunt)
I can select a subset of files to deploy, not the entire branch/tag
The prepared package is a fully working distribution of my site, almost like a binary
Further reading:
http://gitolite.com/deploy.html#why-git-is-not-a-deployment-tool
There are two different ways I go about doing this. One is to actually clone the git repo onto the server and do pulls from the command line on the server. The second is to use a deployment tool like http://dploy.io/ which (s)ftp's the files from the repo to the server.
In both instances I .gitignore from the repository anything that is installed via (composer, bower, grunt) and do that from the command line on the server manually when needed. I am satisfied with the workflow of both methods and use the one more appropriate for the server being deployed to and the team that will need to do future deployments.
The main difference between the two approaches (beside having Git on a production server) is the number of files which have to transit over the network: the less files you have to transfer, the less error-prone the all process is.
That is why I prefer using git archive in order to generate the required tar file (archive of the specified format containing the tree structure for the named tree).
That way, I only have to transfer one file, as a regular archive, and I don't need Git on the other side.
I am developing a PHP project using github.
My editor of choice is Coda 2 which has a function of saving at the same time on local computer and on the FTP server.
Now, I also have the need to commit the changes to git, and therefore to github as well so, every time I am saving (both locally and remotely) I commit to github.
The problem arises now:
What if I need to revert changes? Those would be only affected on github and will probably lead to a mess. What I am doing currently to "revert" is just writing manually the pieces of code that need to be backed up.
You are using Git wrong. There is no reason to commit when you save. Also it's okay if you keep your local git repo for developing and sync with github from time to time only.
So all you need to do is to change your workflow. Remove the commit on save.
Don't upload manually using ftp, instead clone the repository on the server and pull there.
Of course this is only possible if you have shell access to the server. If you want to do serious development you should have a server with shell access.
You misunderstand the purpose of git. It is not a backup tool, but a collaboration tool along with version control system. It never meant to backup your code. It is of course possible, but git's and any other VCS' nature is to provide readable and trackable flow of the project's development phase.
You basically never commit code without explaining changes you've done to the file(s). VCSs encourage you to describe the commit and it's purpose so that the project's team could get into it and see why a certain change was made.
However, to adopt git's capabilities I would suggest making a backup branch and committing files there, so that you know that specific branch is nothing more than chaotic code flow. That at least will make things clear.
Then, when a certain feature is ready and tested, you can squash-merge backup branch into dev branch.
This way you will get organized structure of your repo and you'll be able to revert or pull from the dev branch the state of the code that you really need.
EDIT:
I also suggest having a look at successful git branching blogpost. In it's time it made me understand how git project evolves and develops.
I am wondering what is your procedure method of a web development using Git?
When you finish coding, do you just overwrite the files on the FTP to the live server?
How does git handle number of version of same project? like v1, v1.5, etc
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?
Can two people work on the same project on the same server? Wouldn't this be easier than question 3?
The idea behind git is that it actually takes care of all that for you.
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.
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.
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.
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.
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
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