The project needs, the code management tool is switched to git, which is not the same as the switch to svn from cvs. I myself began to resist git. I feel that it is similar to svn, and there is no need to replace it. For projects that rely heavily on branches for development, it is very convenient to use git to manage them. Because git was created for branch management. In addition, the rise of the github community has also promoted the rapid popularization of git.
The little turtle also has a management tool for the git protocol, called tortoiseGit, which seems to be written more for svn users, and many interfaces are the same as tortoisesvn. No matter what tool, you'd better take a look at the principle of git, otherwise you will feel very strange in many operations in the future.
biggest advantage
No more worrying about switching branches, using git is a real convenience in projects that rely heavily on branches to develop features.
When using git development, eclipse can install the official egit plug-in, in eclipse, just switch to switch branches. Save the work of switching workspaces, or importing and exporting code.
However, in the process of my use, because our project is managed by maven, and we like the development method of multiple projects (one project for dao, one project for service interface, and one project for serviceImp) to form a large project. After switching branches every time, the problem of compilation failure often occurs sometimes. I think this may be a bug caused by the combination of maven and git. However, we may switch branches just to check the code modification, and we can ignore the compilation problem.
biggest disadvantage
Version comparisons are no longer so clear.
If you use svn, develop on a branch, and then merge into the trunk, then look up the modification history of a file on the trunk, and you can see that the merged version and the pre-merge version are next to each other, and the modification of a file on the branch History cannot be found on the trunk. But this is not the case with git. After merging into the trunk, you see the same change history on the branch. It is too difficult to see the version before the merged branch. And the modification trace diagram is very abstract.
In addition, git has a standard branch management process called git flow. You can research this for yourself. Team development, I think specifications are very important, I think this is one of the reasons why everyone adopts git.
Attach the main command of git
git fetch: Fetch changes from the server, but do not merge into the current branch.
git pull: fetch changes from the server and merge into the current trunk.
git commit: Commit changes to local.
git push: Submit the local repository changes to the server (provided that your local code is newer than the server, if there is no new server, the server will reject it)
Please support the original:
About me: from Handan, focusing on software technology.
For more of my previous articles, you can visit
my space