Some notes and experiences when using Git

Just a little bit of personal experience to take notes for review, so most of the time I write to remind myself, so I can read it again when needed

1. Should know

• git remote
  • Very good to use to copy a project instead of copying the entire folder or going to the browser to get the clone link, just use a few commands to show link and then clone the project again. -> copy project
  • Or use a personal repo, and then push to the newly created repo, add another remote, then delete the old remote origin and add it again.
• git stash Save all changes to a clipboard
  • Or use when working with many members. When there is a new change, you need to pull back but there is a conflict so it says k pull dc, you can git stash and pull it back and then stash apply again and fix the conflict later . Or when you are in the middle of working on a branch and have a request to switch to another branch to edit a line, you can use stash – quite convenient.
• git cherry-pick Gets or picks a commit from one branch to another. Before, I did a project that needed multiple versions for different user objects for example: personal version, education version. The versions are a few different, but the core is still the same, so when you finish fixing something in the core, it’s convenient to pick another version branch, which always saves you having to copy by hand or create the wrong branch, but after you commit, you can create again and again. cherry pick sang. Note: if the commit affects too many files, it can be difficult to use cherry-pick because it’s unlikely that all the changes were needed for both branches. So commits include only the necessary edits in one go and should not be combined.
• git reflog Um, this one was unfamiliar to me at first and I didn’t quite understand it, so I use it often. I forgot most of it can’t remember when was the last time I used it. If anyone is interested, you can search for it called therapy or the ultimate weapon for repair (Not counting manually) if there is any problem vs git.

2. Use local

• You don’t need a network to use git, you can create a local git repo yourself and work normally with git.
  git init

  After seeing the git folder, it means that git has been successfully initialized. Repository is now the directory containing the git folder. Basic operations will be possible on this repo.

  git add git commit

  1 2 3

  git add   git commit

  => It is recommended to re-commit even very small changes in the same fix because

  • It will be easy to describe and clarify for the commit.
  • If you notice, when using IDEs, the file states for git will have different colors. If you commit each part clearly, when you fix a new feature, it will be easy to track what you have fixed -> It is easy to check how far you have done if you are disturbed in the process.
  • It will be easier to reuse commits -> Avoid having to make further edits when reverting or using cherry-pick.

  When you want to push to gitlab, github or another repo just add remote with the repo to push and push normally. Remote git is used to link repos against each other.
  

  git remote add 'link' git push

  1 2 3

  git remote add 'link' git push

  
  actually when creating projects on gitlab, github . . . they all have enough instructions to push to the repo no matter the case.
• Not only when the new code uses git. Just finished editing the document face (word, excel). Each edit generates all sorts of final_001, final_002, final_003 . . . cry etc. Done sometimes forget to name the file/folder according to the description so I don’t know what I’m fixing in it.
  => Think of using great git. Each fix is ​​1 commit. Using exactly 1 folder – 1 file vs each commit has an easier description.