Project experience, if necessary, please specify the author: Yuloran (t.cn/EGU6c76)
preface
This article shows you how to use the Git Bash command line, commit code, resolve conflicts, and avoid them. Help you understand the rationale behind the VCS for Android Studio.
Check out the code
Check out the remote warehouse
git clone https://github.com/Yuloran/GitTutorial.git
Copy the code
It is possible to check out the Origin/Master branch to the local, which is the default host/branch name when GitHub creates the repository. Git branch -vv
The local branch name is master, and the associated remote branch name is Origin /master (Origin is the host name, and master is the branch name).
Check out the remote branch
Many times, configuration administrators need to create many new remote branches for parallel development of different versions of the same project. For example, one branch is for requirements development, another branch is for Bug fixing, and so on. At this point, we need to check out the corresponding branches, modify and commit the code.
Synchronous remote branch
After the administrator creates a new remote branch, we need to synchronize the remote branch to see the new branch:
As shown in the figure above, use git branch -a to look at all the local and remote branches and find that there is no bug_fix branch created by the administrator. Enter git fetch to prompt you for a new branch bug_fix. Enter git branch -a again to view all branches:
Well, there is one more bug_fix branch.
Check out the remote branch
git checkout -b bug_fix -t remotes/origin/bug_fix
Copy the code
Checkout -b means new local branch, bug_fix is the local branch name, but you can call it something else. -t indicates the remote branch (track). Remotes/Origin /bug_fix indicates the remote branch name.
Type Git branch to view the current local branch:
Enter git status to check the current branch status:
Note that the current changes are up to date and no changes can be submitted.
Submit code
Bad habits
Many developers like to commit code continuously on a local branch. This is a bad habit to have, especially if you’re working with multiple people. This results in dependencies between each commit, even if each change is unrelated. This may result in merge collisions and cherry-pick merging redundant code. Also, if you suddenly find yourself having problems with your last submission, I think you might feel like you’re missing it.
Correct posture
Keep a local branch dedicated to synchronizing code.
For example, we now need to make a requirement on the master branch. First type git status to check the status of the local master branch:
A message is displayed indicating that a file has been modified locally but not committed. What to do? There are two ways to deal with it:
- Just type it in
git pull
After synchronization, conflicts will be automatically merged. If the conflicts cannot be merged, manually resolve them. -> A merge record may be generated locally - Make local changes first
stash save
To continue usinggit pull --rebase
Synchronize, and finally the changes will be stagedstash pop
Conflicts will be automatically merged. If the conflicts cannot be merged, they will be manually resolved. -> Recommended, automatically rebase, does not generate local merge records
1. Temporary code
git stash save [-u] 'update readme.md'
Copy the code
[-u] Indicates that the parameter is optional. If the value of -u is added, the newly added files are temporarily saved. If the value of -u is not added, only the modified files are temporarily saved. With ‘update readme.md’ as the description, the following lists all the actions supported by git Stash:
git stash list
Displays all temporary recordsgit stash show stash@{0}
View the specified temporary recordgit stash pop stash@{0}
Pops up the specified temporary recordgit stash drop stash@{0}
Deletes the specified temporary recordgit stash clear
Clear temporary records
2. Synchronize the code
git pull --rebase
Copy the code
Synchronization result:
The tips are already up to date. If the native code is not up to date, it should look like the following:
3. Pop up the temporary code
git stash pop [stash@{0}]
Copy the code
[stash@{0}] indicates that it is optional to pop the top of the stack by default. You can also specify which temporary record to pop. The result is as follows:
There is a conflict. Don’t panic, just resolve the conflict, after all, we are working on a “small project”, unless the file newline changes, there will not be too many conflicts. For big projects like AOSP and Mokee, conflict is bad. For example, every time domestic phone manufacturers upgrade a major version (such as from Android 8.0 to Android 9.0), it takes several months to stabilize the version, which is why the Android version of domestic phones always lags behind Google. Git status:
Git has changed the readme. md file.
- use
git reset HEAD <file>
To discard local modifications - use
git add <file>...
Flag conflict resolution (ellipsis indicates that multiple files can be followed, separated by Spaces)
Git diff
Git USES:
<<<<<<< Updated upstream
=======
>>>>>>> Stashed changes
Copy the code
To mark the conflict status, ======= above is someone else’s change on the remote repository, below is our local change. Well, I made the conflict so it was easy. After the conflict is resolved manually in the IDE, use the git add readme. md command to mark that the conflict is resolved:
Readme.md: Excuse me? Changes to be committed Changes to be committed Changes to be committed Submit what, just resolved the conflict, the requirements are not done! Git reset
Order to withdraw it from the staging area:
… Optional. If the file is not added, all files are removed. If the file is added, the specified file is removed. Many Linux help manuals use
or [arg] to indicate optional arguments. <> and [] do not require input, which has become a developer idiom.
4. Create a local branch
A lot of people, at this point, just go crazy on the local master branch. NO! We should create different local branches for different development content. For example, feature_shopping, bugfix_tombstone, etc. Assuming we now need to implement a shopping feature, we should create a new local branch using git checkout -b Feature_shopping:
5. Submit code
After five straight overnight nights, we finally got the requirement done and were ready to commit the code:
Git commit -m “update readme. md” commits your changes to a local repository before pushing them to a remote repository. -m is the modification description, which is a shorthand way of writing it. Large companies have format requirements for the submitted description, so you need to configure the COMMIT template first:
git config --global commit.template ~/.gitmsg
Copy the code
Edit the template:
Enter git commit:
The template has taken effect. Enter the description to modify the template. The Git editor I configured here is vim, you can also configure other Git editor:
git config --global core.editor notepad
Copy the code
In this way, you can use the notebook to write and modify the description.
6. Append the submission
Git commit –amend
7. Roll back the submission
Commit (); commit (); commit (); commit ();
git reset [--soft] commit_id
, soft rollback, file modification records will not be discarded,--soft
You can do without it.git reset --hard commit_id
, hard rollback, discard all changes. Generally used only when you need to back up to the specified node to verify the problem.
Check the commit_id:
git log- 1Copy the code
-1 indicates that only the last entry in the submitted record is displayed:
306 c8b26360adfbdb3992f62514e8d58626f2d20 input git reset, then back to submit. Git add
… , git commit.
8. Push code
After commit, many people will git push directly. This is not correct. You should synchronize your code first. Because we are now on a new local branch, Feature_shopping, which is not associated with a remote branch, git pull –rebase cannot and should not be used to synchronize code. The correct operation is:
git checkout master
: Cut to the local landlord branchgit pull --rebase
: Sync codegit checkout feature_shopping
: Switches to the local requirements branchgit rebase master
Add the local branch code to the local requirement branch.git push origin HEAD:refs/for/master
: Pushes the submission of the local requirement branch to the remotemaster
branch
conclusion
Git Bash has a detailed description of the result, success or failure, of each command. When you encounter problems, as long as you follow the prompts and operate step by step, you can generally solve them.