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.
Related
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.
While developing a Symfony2 project, I often come across bugs in third party bundles. Most of the time the bugs are subtle but hard to find. For example this week alone I have found three bugs where a value was tested using a simple if ( $value ) construct but required the use of ( $value !== null) or ( $value !== false ).
Without having sufficient permissions on the relevant github pages for the projects in question, the best I can do is push a pull request. It usually takes quite some time for the request to be merged. In the mean time, especially when using the master version, other pull requests are merged which in turn leads composer to update. When that happens, any local bug fixes will revert back to the original code.
Is there any method to handle this situation?
Ideally, I would like the third party bundle to update but have my modifications persist. Until the pull request is merged of course.
There is a project that allows you to apply patches after downloading packages with composer. It is created to be used with the Drupal project but I believe it should work with your own patches just as well.
https://github.com/jpstacey/composer-patcher
Otherwise, you could fork the project, make you improvements, submit a pull request and in the mean time use your own forked repository in composer. See [this answer][https://stackoverflow.com/a/14637668/3492835) for a detailed description of how to achieve that.
Edit:
The stars say it is about to be 2016 now, and a few things have changed.
jpstacey/composer-patcher is considered deprecated in favour of the netresearch/composer-patches-plugin project. This is a Composer plugin which does basically the same, but it is able to apply local patches as well.
Composer does not support this functionality out of the box. The reason is simple, one should not work with the development versions of other libraries. But fear not, you can easily work around this by forking the projects on GitHub. Of course this means a lot of overhead, but it is the best solution I can think of with which you can tackle this problem.
Note that this approach has several advantages over the patch approach:
You can directly create your pull request from your fork.
The git merge process will identify any conflicts.
A script to automate this process is easy:
#!/bin/sh
git fetch upstream
git checkout master
git merge upstream/master
You could create a Composer post update/install script which executes these command in each projects local directory if it is one of your forks. (I leave this implementation part to the reader. But one would need to create the repository locally first, since Composer only downloads the latest files without an repository data. This might add huge .git folders to a project since some projects are, well, huge.)
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 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)
I have what I believe is a tricky situation but this usually indicates I'm ignorant of something quite simple.
I currently have one php project that is in an svn repo, call it 'firstproject'. The working copy of this is an apache virtual host dir so I can happily run this project at any point of development through a browser.
I now have another project 'newproject' that I want to use some of the core code of 'firstproject' but when newproject requires me to refactor parts of the firstproject classes I would like for that to be integrated back into firstproject at some point.
Is there any way to set svn up so I can have a working copy of newproject happily in it's own apache virtual host and comprising some code from firstproject and then its own code and for svn to keep tabs on which is which or is it a case of creating a 'newproject' branch of firstproject, editing away adding the newproject code and then doing some sort of merging of code back into 'firstproject' when it seems appropriate?
Many thanks to anyone who can help me thinking about this, it feels like there should be a neat way but maybe there isn't.
It seems to me that firstproject should release some deliverable (a library). newproject can then consume this.
If that library needs to change, then the changes should be made in firstproject, and released.
That's how I'd normally manage this sort of dependency in a non-PHP world. I'm not sure that in PHP it should/would be any different. It's a bit of a headache, but you're building a reusable library that a downstream project can consume (and choose which version it consumes, note).
If there is a large part of the code that is common, then you can consider using a common repository instead of two seperate repositories for these two projects. You can then take out a branch for the code that might change within the project newproject . The workspace on the newproject apache server will have to be from this branch so that any changes can be committed back to the branch and merged back to the trunk when you are ready. This way you can incorporate the changes back to the firstproject mainline/trunk.
You can also explore svn externals for another approach to mix and match if you need a workspace with checkouts from multiple repositories. I have not implemented this myself but you may find the details here:
http://svnbook.red-bean.com/en/1.1/ch07s04.html