Using Git in the Real Life for Beginners 1
This tutorial is for newbies who want to learn git in real life and easy way. 此篇教程献给学了点线面没学骨架的我,另外我学习的逻辑其实是骨架到面线点。
I use git basic for a while, like copy and paste git init
, git add
, then push. something even forgets add
before commit
, but whenever I go through the git tutorial, I just get bored.
But hey, I have to adapt git during working, now I decide to share my learning note to make newbies feel more comfortable to use git.
git 真是让我头疼,学了很多指令,结果遇到一堆问题,只能边 google 答案边解决。后面发现一开始使用逻辑都没弄对,所以学习 git 之前先弄明白使用逻辑,从逻辑框架中去学,比一堆什么 basic 指令啊,merge 怎么用有效的多。
File Status
First, let’s make three concepts clear. Imagine you are a Prop Maker working in an Entertainment Industry, your job is making, preparing the props according to the script, then carry them to shooting setup.
首先,先理清我们的工作逻辑:工作区(Working Directory)、 版本库(commit History)和 暂存区(stage or index)。
- Working Directory:
it’s like your own department or backstage, contains tons of props, tools, and other material; It’s a place where you make props. For me, I would like to have some Markdown files on my current IDEA project, then I can easily write down any problem-solving steps.
- stage or index:
It is the prop list, This helps organize what props to attain, what characteristics they have, any changes needed, and where to place them.
- commit History:
every commit is like you taking a picture of what you have done so far, keep hanging them in a certain direction, then when you mess up by accident, you can just choose a picture then return to the specific time you want. Yeah, we are talking about the Time machine.
- Branch: just like the pictures below, you or your teammate work on the different stage designs for the film shoot.
Now it’s time for the real-life case: The first week the tech Managers set up a meeting, a working schedule…
Usually, every company would have different Branch models according to the projects.
Now the leader has set up a project repositor, including several branches:
- Develop Branch: team members need pull/fetch and push code in time
- Test Branch: files need to be pushed to the test branch after finished
- Release Branch: depends on your Tech Leader’s plan
- Master Branch: once pass the test, the test/managing team will publish this branch, and have tag
- if there are some bugs during the test process, create a bug branch bash on the release branch
Grab a coffee, let’s work.☕☕☕:coffee
1.remote to local
git clone https://github.com/xxxxxx/projectxx
That creates a directory named projectxx, initializes a .git directory
2.working on your Develop branch
Coding…Coding…Coding…
finish xx.md
git add xx
you add xx file on the staged, just like you create a new prop, then update the prop list.
git add *
add every untracked/modified filed to the stage area your new prop, which has never been in the prop list would be called untracked.
git add ./readme.md/
add readme file inside a folder
Now let’s know more details about our remake prop, prop list items, new prop things.
git status
it’s a more simplified output to find out your files in untracked or staged status. I use it a lot.
git status -s
$ git status -s
?? newFiles.txt
A lib/add.rb
M lib/staged.rb
M mo.text
MM twice.text
??
means New files that aren’t tracked (your new prop has not been put into the prop list yet)A .
means new files that have been added to the staging area have an AM .
modified and staged. M
modified files but not yet staged (tricky one, your prop has been in the prop list, but it need modified, you finish modifying)MM
modified, staged, and then modified again, so there are changes to it that are both staged and unstaged.
Sometimes if the git status command is too vague for you — you want to know exactly what you changed,
use git diff
- git diff : Working Directory VS stage or index
- git diff –cached :stage or index VS commit History
- git diff HEAD : Working Directory VS commit History
- git diff origin/branchname..branchname origin/branchname VS branchnam
time to take the picture and leave for the day.
git commit -m “cell”