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 ingit pullAfter 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 firststash saveTo continue usinggit pull --rebaseSynchronize, and finally the changes will be stagedstash popConflicts 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 listDisplays all temporary records
  • git stash show stash@{0}View the specified temporary record
  • git stash pop stash@{0}Pops up the specified temporary record
  • git stash drop stash@{0}Deletes the specified temporary record
  • git stash clearClear 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.

  • usegit reset HEAD <file>To discard local modifications
  • usegit 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,--softYou 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:

  1. git checkout master: Cut to the local landlord branch
  2. git pull --rebase: Sync code
  3. git checkout feature_shopping: Switches to the local requirements branch
  4. git rebase masterAdd the local branch code to the local requirement branch.
  5. git push origin HEAD:refs/for/master: Pushes the submission of the local requirement branch to the remotemasterbranch

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.