There is less than a year of contact with Git, which can be said to be late than most people start. That will be immersed in their own comfort circle inside, into the company using the perforce, a use for almost 7 years, feel that they will use an SCM on the line, holding it, do not want to contact other SCM.
It was not until last year that a new project was opened, the time was very strong, and then I was pulled into the project team. The programming language uses Php,framework is LARAVEL,SCM is git. Just heard, I ... A. NET programmer, now let me to do PHP, or never touched, thought not to mistake it, but the big Boss arranged, conflict is useless, and then was forced to contact with the PHP, access to git.
If perforce brings me the feeling that it is Michael Teng, Git is the S-Class Big Ben, if now let me re-select, I will undoubtedly choose Git, the gap is so large, coupled with today's largest code hosting platform Github,git as today's most powerful distributed SCM, well-deserved.
Nonsense said a bit more, below to get to the chase. installation of Git
Reference official website https://www.git-scm.com/
Children's shoes on Windows download packaged integration environment: Https://www.git-scm.com/download/win
Git Flow
Git flow has a lot, from simple to complex, no absolute standard, choose the right one for you:
- If you are the only person in the whole project, you can play on a master branch
- If the project has more than one partner, and the master branch can always match the online environment, it is developed using the Master branch +branches.
- If the project has multiple people working together, and the master branch does not necessarily match the online environment, use the master Branch +production Branch +branches Development.
- Wait a minute
This article describes the second flow above:
- The master code is on the master branch
- Any changes you want to make to your code, whether it's a development feature, fix a bug, open a new branch from the master branch
- Code completion, send Pull/merge request, if there is a CI, this time will run test script, through, reviewers will come to review your code, during the period may require you to make some changes to code
- Once completed, the code is merged into the master branch and, if there is a CI, is automatically deployed to the stage (QA) environment
Flow corresponds to the following: 1. Get the Master branch code
For the first time, with the git clone Directive, the code repository has an address such as [email protected]:ypzc/first-web.git
git clone [email protected]:ypzc/first-web.git
If you are getting the latest remote code, use the git pull command, the following command gets the latest code from the remote master to the current branch
Git checkout Mastergit pull Origin Master
2. Create Branch
Whether you are developing features or fixing bugs, start with the master branch:
-B Training
Git checkout-b is equivalent to executing two instructions:
GIT branch traininggit Checkout training
After the branch is created, you'll start modifying code, such as adding try-git.md files:
# I like git very much
You can now use the git status command to see which files in your workspace have been modified:
$ git statuson Branch Trainingyour branchis up-to-date'origin/training' "git add <file> " inch What'll be committed) try-"git add" to track)
Git has been smart enough to remind us that there is no list of tracked files and tells us to use the git add command to track it
$ git Add try-git.md
Use git status again to view the status
$ git statuson Branch Trainingyour branchis up-to-date'origin/master' "git reset HEAD <file> " file: try-git.md
Prompt has the modification need to submit, is not a bit dizzy, just we under the git add why go to ...
Here's a look at Git essentials, workspaces and staging area.
The workspace is the source code directory that is currently being written, and we modify any of the files in the workspace.
The git add command puts the changes we make to the file in the workspace into staging area, which is the equivalent of a snapshot, and can then continue to modify the file, but the staging area contains the same look that was put in the file.
Git is a distributed SCM, so each workspace Local has a corresponding code warehouse repository, after a file git add, just tell git to do version control of this file, you need to continue the instructions git commit, submit the file to the local repository
" First Add File " try-git.md1file1 insertion (+100644 try-git.md
Run git status again
$ git Statuson branch trainingnothing to commit, working tree clean
The world is quiet.
So far, the operation of Git is only done locally, you need to push the code changes to the remote repository, others can see your modified code
$ Git push Origin trainingcounting objects:3, Done. Delta compression using up to4threads.compressing objects: -% (2/2), Done. Writing objects: -% (3/3),307bytes |0BYTES/S, Done. Total3(Delta1), reused0(Delta0) remote:remote:To Create a merge request fortraining, Visit:remote:xxxxxremote:To xxxxx* [New Branch] training-training
If the training branch represents a new function, then the code for this function is not in the Master branch, and in general, code that is deployed to the online environment is from the master branch, so the functions developed by the training branch need to be merge to the Master branch. At present, many CI environments support the Pull/merge request, this action will be executed manually on the CI system, take Ali code example:
After execution, reviewers will receive a notification letter, review the code, the code will be automatically marge to the Master branch, If you encounter another developer who also modifies the try-git.md file, this may cause a conflict, so it is recommended that the latest code Marge on the master branch be the current branch before you push to the remote repository:
$ git pull-- in try-git.md
Git uses <<<<<<<,=======,>>>>>>> to mark the contents of different branches, when you open the Try-git.md file, you can see similar
<<<<<<< head# gitis so powerful!=======# I like Git very much>>>> >>> Feature1
Manual adjustment to:
# Git is so powerful! # I like git very much
After adjusting, commit to staging area with git add, then execute git rebase--continue, then push to remote
$ git add try---continue$ git push origin training
Common git commands
- git add [file-name] put the file into staging area
- git Add. Put all the files into staging area
- Git Status View workspaces and staging area status
- git commit-m "message" [File-name] Submit file to Repository
- git commit-m "message" commits all files in staging area to the repository
- Git push origin [branch-name] pushes the current branch to the remote branch
- Git pull--rebase Origin master updates the remote master's modifications to the local current branch
- git diff [File-name] compare workspace files to staging area/repository differences
- git checkout [file-name] ignores changes to the current workspace of the file, if staging area has a modification to the file, go back to the staging area version, or go back to the version of the repository
- git rm [File-name] Delete file
- git log view repository commit history
- git reset--hard [Commit-id] rolls back the code to a commit and discards all changes. In addition, the HEAD represents the current version, and head^ represents the last time commit,head^^, and so on, and, of course, this representation method: Head~10
- git reset--soft [Commit-id] cancels the commit record, but retains the code modification. This is useful when the merge from Feature Branch is back to master, usually developing a feature will have a number of commits, if not processed directly Marge to Master,commit will also Marge in, Causing the master branch to commit too much is not easy to read and maintain. It is best to empty the commit before pushing to origin, leaving only a commit that describes the current function
- git tag View all tags
- Git tag-a [tag-name]-M "message" tag the current commit and add a description to the tag
- Git tag-a [tag-name]-M "message" [Commit-id] tag a commit and add a description
- Git push origin [tag-name] pushes local tags to remote
- Git push origin--tags to bulk push locally-pushed labels to remote
- Git tag-d [tag-name] Delete tags
- git push origin:refs/tags/[tag-name] Delete remote tags
There are also some files that you do not want Git to track, which can be described in the. gitignore file in the root directory of the workspace, syntax Baidu.
git diff default functionality is more difficult to read, you can use third-party tool, here is more recommended Suorcetree, official website: https://www.sourcetreeapp.com/, after registration can be free trial.
If the official website download is very slow, also can download from Baidu disk:
Http://pan.baidu.com/s/1pLS4W7D
Application of GIT multiplayer cooperation mode