Git实践记录与总结感悟（一）

Dear 丶 2023-08-17 17:26 106阅读 0赞

#### Git基础知识 ####

1.  颜色

<table> 
 <thead> 
  <tr> 
   <th>颜色</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>红色</td> 
   <td>未加入版本控制</td> 
  </tr> 
  <tr> 
   <td>绿色</td> 
   <td>已经加入版本控制暂未提交</td> 
  </tr> 
  <tr> 
   <td>白色</td> 
   <td>加入版本控制，已提交，无改动</td> 
  </tr> 
  <tr> 
   <td>蓝色</td> 
   <td>加入版本控制，已提交，有改动</td> 
  </tr> 
  <tr> 
   <td>灰色</td> 
   <td>版本控制已忽略文件</td> 
  </tr> 
 </tbody> 
</table>

1.  一个总文件下，**只有**一个.git文件，如果有多个的话，就不会往仓库里推。
2.  一定要有一个.gitignore文件。
3.  如果远程分支的版本高于本地分支的版本，并且是两个人修改的同一份文件，但是修改的行数是不一样的，这里的行数不是修改了多少行，而是修改的具体行数，比如同事修改了第5行和第10行，自己修改了第100行，虽然远程分支版本高于本地分支，但是依然是没有任何冲突的。
4.  当使用git clone 下来的时候，一定要切换成想要的分支，不然就是原来的master分支。或者git clone的时候，就指定自己想要的具体分支。

--------------------

#### git 工作中常规操作流程 ####

a) git add filename  
b) git commit -m “我的提交”  
c) git pull 如果有冲突就会提示，然后解决冲突  
d) git push

--------------------

#### git使用的问与答 ####

1.  **问题：**  
    那为什么要先**add**, 其次在**commit**，然后在**pull**，最后再**push**？如果我pull了，岂不是把自己修改的代码都给覆盖掉了嘛，因为远程没有我改的代码，我pull，岂不是覆盖了我本地改动好的地方了？那我还怎么push？  
    **答：**  
    **先add,在commit 再 pull 再 push 的情况就是为了应对多人合并开发的情况：**  
    a) **add**是为了把修改的文件或者新添加的文件，添加到本地仓库中。
    
    b) **commit** 是为了告诉 git, 我**这次提交改了哪些东西,不然只是改了但是 git 不知道我修改了,也就无从判断比较**;
    
    c) **pull**是为了本地 commit 和远程commit 的对比记录,**git 是按照文件的行数操作进行对比的**,如果同时操作了某文件的同一行那么就会产生冲突,git 也会把这个冲突给标记出来,这个时候就需要先把和自己冲突的那同事进行讨论，最终确定保留谁的代码,然后在 git commit && git pull ,再次 pull 是为了防止再自己与冲突同事协商的时候另同事又提交了一版东西,如果真发生了，流程重复一遍即可,通常没有冲突的时候就直接把文件合并了,不会把代码给覆盖掉 。
    
    d)出现代码覆盖或者丢失的情况:比如Alice和Bob两人的代码pull的时候，文件版本都是1,Alic在本地提交了2,3并且推送到远程了,Bob 修改文件完成后**没有commit** 操作,直接 git pull 这个时候 Bob 本地版本已经到3了。Bob 在本地版本3的时候改了 A 写过的代码,再进行了git commit && git push 那么在远程版本中就是4,而且 A 的代码被覆盖了,所以说都要**先 commit 再 pull,最后在push**,不然会覆盖代码的。

--------------------

#### Tag使用记录 ####

1.  查看tag  
    git tag
2.  在某个commit上打tag  
    git tag v1.0.0 c809ddbf83939a89659e51dc2a5fe183af384233
3.  **本地tag**推送到**远程**  
    git push origin v1.0.0
4.  删除本地tag  
    git tag -d fc-V1.0.0
5.  删除线上tag  
    git push origin :refs/tags/ fc-V1.0.0  
    注意冒号前有一个空格。

--------------------

#### 如何在Github上协同工作？ ####

##### 1. 建立关系 #####

a) 查看现有远程仓库：

$ git remote -v
    origin  https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
    origin  https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)

b） 添加指向原仓库的upstream：

$ git remote add upstream
    https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

c) 查看origin和upstream

$ git remote -v
    origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
    origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)
    upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch)
    upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push)

d）直接从原仓库的master分支拉取代码并直接合并代码，其中pull=fetch+merge.  
git pull upstream master

##### 2. 协同工作流程理解和梳理 #####

a) 自己本地仓库，自己githuh远程仓库，对方github远程仓库。

b) 我可以先在本地写好代码。提交到我本地仓库。

c) 然后，我在pull request的时候应该先去合并对方仓库的代码。

d) 然后，我需要把本地仓库的代码，push到我github的仓库上。

e) 最后，我在New pull request。

##### 3. 如何同步对方仓库的代码。 #####

git pull upstream master

这行代码只能把对方仓库中的代码拉取到本地仓库而已

#### 4. github协同工作小结 ####

1.  理解，自己本地仓库肯定是和自己的github远程仓库建立关系。然后本地又需要和**源github**（远程别人的github仓库）建立关系。然后理解它就很简单了，自己的githup远程仓库和源githup远程仓库想象成两个分支，中间桥梁就是自己本地分支。由自己本地分支去交互自己的githup远程仓库和源github远程仓库。合并了最新的代码后，就直接去githup网站，New pull request就行了。
2.  它的工作原理其实跟自己玩的时候一样的，我在自己的远程仓库中建立了无数个分支。假如我本地的分支跟远程分支是一一对应的。然后我本地仓库作为中间桥梁，不停地去合并别的分支的代码到本地，然后push到远程仓库分支（push前是需要先进行pull操作的）。他们唯一的区别就是，一个直接在本地就可以完成分支合并，但是合并的结果也还是在本地，需要push一下。Githup的工作模式是，我本地仓库作为中间桥梁去pull**源githup**上的最新代码并合并到本地分支，然后在把最新代码push到自己的远程仓库中，然后最后一步就是**New pull reques**t即可。

--------------------

### 小结 ###

1.  从记录git最基础知识颜色，到实践中的心得体会，比如一定要有一个.gitignore文件，git冲突判断标准是否有多个人修改了同一个文件同一行。
2.  梳理git使用的常规流程。并通过问与答的方式理解了add,commit,pull,push指令的含义。
3.  记录tag使用的常使用指令。
4.  梳理在githup网站上，多人协同工作的操作方式的理解。流程梳理和流程总结式的理解。