update once before submission
merge first pull, then pull and then merge, if the changes do not intersect, it is the same.
if so, it is recommended to merge pull first.
you should first understand the principles of git.
git is divided into two repositories, one is local , and the other is remote .
git add. And git commit are both for your local warehouse .
what git add does, you can simply understand which files are marked to be submitted to the local repository .
git commit is to submit your marked files to local warehouse
git pull is to pull the code from the remote warehouse and merge it to your local warehouse. Pull is the combination of two commands (fetch and merge)
so theoretically pull has no problem before these two, but pull, is usually recommended first. My habit is
pull, add, commit
git for multiplayer development. Every time you submit code, pull the code of your teammates git pull , and then submit your code.
try git pull origin [your-branch]-- rebase .
if you do not pull,commit, you will report an error when there is a conflict in push,. This should be what happens to you ("if you go home and submit it, you will get an error").
after commit, you need pull before push-- rebase, and then push. Pull would be better to add-rebase, can just commit rebase to the latest remote commit, which sometimes avoids the useless merge submission caused by direct pull (because pull equals fetch & & merge, if remote submission is newer than your local submission, it will generate merge). Of course, if there is a conflict, whether or not to add-- rebase also have to manually resolve the conflict, and then push.
all the steps are as follows: the first step is that you create a git init locally, step 2,: git remote add origin (, put the SSH key here, and step 3,: git pull origin master, pull to prevent the problems caused by version conflicts. Step 4 git add. Put the code into the staging area, step 5,: git commit-m to generate the local version of the sixth: git push origin master push.
before every push, it's best to pull
to update your colleague's code locally every day when you go to work, and then upload your own code. This is what I usually do. I haven't had any problems yet.
the best practice is to set up your own branch to modify the code, and when you're done, mention MR and merge it into the collective development branch.
process:
git checkout develop
git checkout -b self_branch
//
git add .
git commit -m 'xxxxx'
The
Git website initiates Pull Request, to merge self_branch into the develop branch, and then ask colleagues to review your code, as well as merge.
