分类 Linux 下的文章

Git学习笔记一:基本用法(上)

一.学前准备

需要有一定的linux基础,能够熟悉linux的常用命令

二、git的初始化

1.Git 配置

使用Git的第一件事就是设置你的名字和email,这些就是你在提交commit时的签名。

$ git config --global user.name "Scott Chacon" $ git config --global user.email "[email protected]" 

执行了上面的命令后,会在家目录(/home/shiyanlou)下建立一个叫.gitconfig 的文件(该文件问隐藏文件,需要使用ls -al查看到). 内容一般像下面这样,可以使用vim或cat查看文件内容:

$ cat ~/.gitconfig [user] name = Scott Chacon email = schacon@gmail.com 

如果你想使项目里的某个值与前面的全局设置有区别(例如把私人邮箱地址改为工作邮箱);你可以在项目中使用git config 命令不带 --global 选项来设置. 这会在你项目目录下的 .git/config 文件增加一节[user]内容(如上所示)。对于新建项目,这部分定制操作需要在git初始化之后才可以执行.

三、获得一个Git仓库

既然我们现在把一切都设置好了,那么我们需要一个Git仓库。有两种方法可以得到它:一种是从已有的Git仓库中clone (克隆,复制);还有一种是新建一个仓库,把未进行版本控制的文件进行版本控制。

1.Clone一个仓库

为了得一个项目的拷贝(copy),我们需要知道这个项目仓库的地址(Git URL). Git能在许多协议下使用,所以Git URL可能以ssh://, http(s)://, git://,或是只是以一个用户名(git 会认为这是一个ssh 地址)为前辍. 有些仓库可以通过不只一种协议来访问,例如,Git本身的源代码你既可以用 git:// 协议来访问:

$ git clone http://git.shiyanlou.com/shiyanlou/gitproject 

也可以通过http 协议来访问:

$ git clone http://github.com/shiyanlou/gitproject.git 

当前git project仅是测试项目,里面仅有一个README.md文件

2.初始化一个新的仓库

可以对一个已存在的文件夹用下面的命令让它置于Git的版本控制管理之下. 创建文件夹

$ mkdir project 

添加文件及文件内容

$ echo "test content" > project/testfile.txt 

Git仓库初始化

$cd project $git init 

Git会输出:

Initialized empty Git repository in /home/shiyanlou/project/.git/ 

通过la命令会发现project目录下会有一个名叫”.git” 的目录被创建,这意味着一个仓库被初始化了。

四、正常的工作流程

1.正常的工作流程

进入我们刚才建立的project目录,创建文件file1,file2,file3

$cd project $touch file1 file2 file3 

修改文件,可以使用vim编辑内容,也可以直接echo添加测试内容。将它们更新的内容添加到索引中.

$echo "testcontent1" >>file1 $echo "testcontent2" >>file2 $echo "testcontent3" >>file3 $git add file1 file2 file3 

你现在为commit做好了准备,你可以使用 git diff 命令再加上 --cached 参数 ,看看哪些文件将被提交(commit)。

$git diff --cached 

(如果没有--cached参数,git diff 会显示当前你所有已做的但没有加入到索引里的修改.) 你也可以用git status命令来获得当前项目的一个状况:

$git status 

如果你要做进一步的修改, 那就继续做, 做完后就把新修改的文件加入到索引中. 最后把他们提交:

$git commit -m "put a message to commit" 

需要使用-m添加本次修改的注释,完成后就会记录一个新的项目版本.除了用git add 命令,我们还可以用

$ git commit -a -m "put a message to commit" 

这会自动把所有内容被修改的文件(不包括新创建的文件)都添加到索引中,并且同时把它们提交。

五、分支与合并

1.分支

一个Git仓库可以维护很多开发分支。现在我们来创建一个新的叫 experimental的分支

$git branch experimental 

如果你运行下面这条命令:

$git branch 

你会得到当前仓库中存在的所有分支列表:

 experimental *master 

experimental 分支是你刚才创建的,master分支是Git系统默认创建的主分支。星号(“*”)标识了你当工作在哪个分支下,输入:

$git checkout experimental 

切换到”experimental”分支,先编辑里面的一个文件,再提交(commit)改动,最后切换回 “master”分支。

$git commit -a -m "put a message to commit" $git checkout master 

你现在可以看一下你原来在“experimental”分支下所作的修改还在不在;因为你现在切换回了“master”分支,所以原来那些修改就不存在了。 你现在可以在“master”分支下再作一些不同的修改:

$ git commit -a -m "put a message to commit" 

这时,两个分支就有了各自不同的修改(diverged);我们可以通过下面的命令来合并“experimental”和“master”两个分支:

$git merge experimental 

如果这个两个分支间的修改没有冲突(conflict), 那么合并就完成了。如果有冲突,输入下面的命令就可以查看当前有哪些文件产生了冲突:

$git diff 

当你编辑了有冲突的文件,解决了冲突后就可以提交了:

$ git commit -a -m "put a message to commit" 

这时你就可以删除掉你的 “experimental” 分支了(如果愿意):

$ git branch -d experimental 

git branch -d只能删除那些已经被当前分支的合并的分支. 如果你要强制删除某个分支的话就用git branch –D;下面假设你要强制删除一个叫”crazy-idea”的分支:

$git branch -D crazy-idea 

2.解决合并中的冲突

如果执行自动合并没有成功的话,git会在索引和工作树里设置一个特殊的状态, 提示你如何解决合并中出现的冲突。 有冲突(conflicts)的文件会保存在索引中,除非你解决了问题并且更新了索引,否则执行 git commit都会失败 如果执行 git status 会显示这些文件没有合并(unmerged),这些有冲突的文件里面会添加像下面的冲突标识符:

<<<<<<< HEAD:file.txt Hello world ======= Goodbye >>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt 

你所需要的做是就是编辑解决冲突,(接着把冲突标识符删掉),再执行下面的命令:

$git add file.txt $git commit -m "put a message to commit" 

3.撒销一个合并

如果你觉得你合并后的状态是一团乱麻,想把当前的修改都放弃,你可以用下面的命令回到合并之前的状态:

$ git reset --hard HEAD

或者你已经把合并后的代码提交,但还是想把它们撒销:

$ git reset --hard ORIG_HEAD

但是刚才这条命令在某些情况会很危险,如果你把一个已经被另一个分支合并的分支给删了,那么以后在合并相关的分支时会出错

4.快速向前合并

还有一种需要特殊对待的情况,在前面没有提到。通常,一个合并会产生一个合并提交(commit), 把两个父分支里的每一行内容都合并进来。 但是,如果当前的分支和另一个分支没有内容上的差异,就是说当前分支的每一个提交(commit)都已经存在另一个分支里了,git 就会执行一个“快速向前"(fast forward)操作;git 不创建任何新的提交(commit),只是将当前分支指向合并进来的分支。

六、Git日志

1.查看日志

git log命令可以显示所有的提交(commit) 当然你也可以组合上面的命令选项;下面的命令就是找出所有从"v2.5“开始在fs目录下的所有Makefile的修改.

$ git log v2.5.. Makefile fs/ 

Git会根据git log命令的参数,按时间顺序显示相关的提交(commit)。

2.日志统计

如果用--stat选项使用'git log',它会显示在每个提交(commit)中哪些文件被修改了, 这些文件分别添加或删除了多少行内容.

$ git log --stat 

3.格式化日志

你可以按你的要求来格式化日志输出。‘--pretty'参数可以使用若干表现格式,如‘oneline':

$ git log --pretty=oneline 

或者你也可以使用 'short' 格式:

$ git log --pretty=short 

你也可用‘medium','full','fuller','email' 或‘raw'. 如果这些格式不完全符合你的相求, 你也可以用‘--pretty=format'参数 另一个有趣的事是:你可以用'--graph'选项来可视化你的提交图(commit graph),它会用ASCII字符来画出一个很漂亮的提交历史(commit history)线。

4.日志排序

你也可以把日志记录按一些不同的顺序来显示。注意,git日志从最近的提交(commit)开始,并且从这里开始向它们父分支回溯。然而git历史可能包括多个互不关联的开发线路,这样有时提交(commits)显示出来就有点杂乱。 如果你要指定一个特定的顺序,可以为git log命令添加顺序参数(ordering option). 按默认情况,提交(commits)会按逆时间(reverse chronological)顺序显示。 但是你也可以指定‘--topo-order'参数,这就会让提交(commits)按拓扑顺序来显示(就是子提交在它们的父提交前显示). 如果你用git log命令按拓扑顺序来显示git仓库的提交日志,你会看到“开发线"(development lines)都会集合在一起.

$ git log --pretty=format:'%h : %s' --topo-order --graph 

你也可以用'--date-order'参数,这样显示提交日志的顺序主要按提交日期来排序. 这个参数和'--topo-order'有一点像,没有父分支会在它们的子分支前显示,但是其它的东东还是按照时间来排序显示。你会看到"开发线"(development lines)没有集合一起,它们会像并行开发(parallel development)一样跳来跳去的:

$ git log --pretty=format:'%h : %s' --date-order --graph 

最后,你也可以用 ‘--reverse'参数来逆向显示所有日志。

七、小结

本节讲解了几个基本命令:

  • git config:配置相关信息
  • git clone:复制仓库
  • git init:初始化仓库
  • git add:添加更新内容到索引中
  • git diff:比较内容
  • git status:获取当前项目状况
  • git commit:提交
  • git branch:分支相关
  • git checkout:切换分支
  • git merge:合并分支
  • git reset:恢复版本
  • git log:查看日志

简单解释一下git commit命令,-m后面输入的是本次提交的说明,可以输入任意内容,当然最好是有意义的,这样你就能从历史记录里方便地找到改动记录。

嫌麻烦不想输入-m "xxx"行不行?确实有办法可以这么干,但是强烈不建议你这么干,因为输入说明对自己对别人阅读都很重要。实在不想输入说明的童鞋请自行Google,我不告诉你这个参数。

git commit命令执行成功后会告诉你,1个文件被改动(我们新添加的readme.txt文件),插入了两行内容(readme.txt有两行内容)。

为什么Git添加文件需要addcommit一共两步呢?因为commit可以一次提交很多文件,所以你可以多次add不同的文件,比如:

$git add file1.txt $git add file2.txt file3.txt $git commit -m "add 3 files." 

小结

现在总结一下今天学的两点内容:

初始化一个Git仓库,使用git init命令。

添加文件到Git仓库,分两步:

  • 第一步,使用命令git add <file>,注意,可反复多次使用,添加多个文件;

  • 第二步,使用命令git commit,完成。

systemd-analyze在ArchLinux上的应用

以下说明的是systemd-analyze的在分析系统启动性能的应用:

1. $ systemd-analyze > starttime.txt 会在~/starttime.txt中显示启动时间。譬如[SSD中]:

Startup finished in 1.894s (kernel) + 5.970s (userspace) = 7.864s

2.$ systemd-analyze plot > start_time.svg 会在~/start_time.svg中显示启动项以及各自所消耗的时间,并在.svg中得到显示

 

以下为man详解:

man systemd-analyze
SYSTEMD-ANALYZE(1)                                systemd-analyze                                SYSTEMD-ANALYZE(1)

NAME
       systemd-analyze - Analyze system boot-up performance

SYNOPSIS
       systemd-analyze [OPTIONS...] [time]

       systemd-analyze [OPTIONS...] blame

       systemd-analyze [OPTIONS...] critical-chain [UNIT...]

       systemd-analyze [OPTIONS...] plot [> file.svg]

       systemd-analyze [OPTIONS...] dot [PATTERN...] [> file.dot]

       systemd-analyze [OPTIONS...] dump

       systemd-analyze [OPTIONS...] set-log-level [LEVEL]

       systemd-analyze [OPTIONS...] verify [FILES...]

DESCRIPTION
       systemd-analyze may be used to determine system boot-up performance statistics and retrieve other state and
       tracing information from the system and service manager, and to verify the correctness of unit files.

       systemd-analyze time prints the time spent in the kernel before userspace has been reached, the time spent
       in the initial RAM disk (initrd) before normal system userspace has been reached, and the time normal system
       userspace took to initialize. Note that these measurements simply measure the time passed up to the point
       where all system services have been spawned, but not necessarily until they fully finished initialization or
       the disk is idle.

       systemd-analyze blame prints a list of all running units, ordered by the time they took to initialize. This
       information may be used to optimize boot-up times. Note that the output might be misleading as the
       initialization of one service might be slow simply because it waits for the initialization of another
       service to complete.

       systemd-analyze critical-chain [UNIT...]  prints a tree of the time-critical chain of units (for each of the
       specified UNITs or for the default target otherwise). The time after the unit is active or started is
       printed after the "@" character. The time the unit takes to start is printed after the "+" character. Note
       that the output might be misleading as the initialization of one service might depend on socket activation
       and because of the parallel execution of units.

       systemd-analyze plot prints an SVG graphic detailing which system services have been started at what time,
       highlighting the time they spent on initialization.

       systemd-analyze dot generates textual dependency graph description in dot format for further processing with
       the GraphViz dot(1) tool. Use a command line like systemd-analyze dot | dot -Tsvg > systemd.svg to generate
       a graphical dependency tree. Unless --order or --require is passed, the generated graph will show both
       ordering and requirement dependencies. Optional pattern globbing style specifications (e.g.  *.target) may
       be given at the end. A unit dependency is included in the graph if any of these patterns match either the
       origin or destination node.

       systemd-analyze dump outputs a (usually very long) human-readable serialization of the complete server
       state. Its format is subject to change without notice and should not be parsed by applications.

       systemd-analyze set-log-level LEVEL changes the current log level of the systemd daemon to LEVEL (accepts
       the same values as --log-level= described in systemd(1)).

       systemd-analyze verify will load unit files and print warnings if any errors are detected. Files specified
       on the command line will be loaded, but also any other units referenced by them. This command works by
       prepending the directories for all command line arguments at the beginning of the unit load path, which
       means that all units files found in those directories will be used in preference to the unit files found in
       the standard locations, even if not listed explicitly.

       If no command is passed, systemd-analyze time is implied.

OPTIONS
       The following options are understood:

       --user
           Operates on the user systemd instance.

       --system
           Operates on the system systemd instance. This is the implied default.

       --order, --require
           When used in conjunction with the dot command (see above), selects which dependencies are shown in the
           dependency graph. If --order is passed, only dependencies of type After= or Before= are shown. If
           --require is passed, only dependencies of type Requires=, RequiresOverridable=, Requisite=,
           RequisiteOverridable=, Wants= and Conflicts= are shown. If neither is passed, this shows dependencies of
           all these types.

       --from-pattern=, --to-pattern=
           When used in conjunction with the dot command (see above), this selects which relationships are shown in
           the dependency graph. Both options require a glob(7) pattern as an argument, which will be matched
           against the left-hand and the right-hand, respectively, nodes of a relationship.

           Each of these can be used more than once, in which case the unit name must match one of the values. When
           tests for both sides of the relation are present, a relation must pass both tests to be shown. When
           patterns are also specified as positional arguments, they must match at least one side of the relation.
           In other words, patterns specified with those two options will trim the list of edges matched by the
           positional arguments, if any are given, and fully determine the list of edges shown otherwise.

       --fuzz=timespan
           When used in conjunction with the critical-chain command (see above), also show units, which finished
           timespan earlier, than the latest unit in the same level. The unit of timespan is seconds unless
           specified with a different unit, e.g. "50ms".

       --no-man
           Do not invoke man to verify the existence of man pages listed in Documentation=.

       -H, --host=
           Execute the operation remotely. Specify a hostname, or a username and hostname separated by "@", to
           connect to. The hostname may optionally be suffixed by a container name, separated by ":", which
           connects directly to a specific container on the specified host. This will use SSH to talk to the remote
           machine manager instance. Container names may be enumerated with machinectl -H HOST.

       -M, --machine=
           Execute operation on a local container. Specify a container name to connect to.

       -h, --help
           Print a short help text and exit.

       --version
           Print a short version string and exit.

       --no-pager
           Do not pipe output into a pager.

EXIT STATUS
       On success, 0 is returned, a non-zero failure code otherwise.

EXAMPLES FOR DOT
       Example 1. Plots all dependencies of any unit whose name starts with "avahi-daemon"

           $ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > avahi.svg
                 $ eog avahi.svg

       Example 2. Plots the dependencies between all known target units

           systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' | dot -Tsvg > targets.svg
           $ eog targets.svg

EXAMPLES FOR VERIFY
       The following errors are currently detected:

       ·   unknown sections and directives,

       ·   missing dependencies which are required to start the given unit,

       ·   man pages listed in Documentation= which are not found in the system,

       ·   commands listed in ExecStart= and similar which are not found in the system or not executable.

       Example 3. Misspelt directives

           $ cat ./user.slice
           [Unit]
           WhatIsThis=11
           Documentation=man:nosuchfile(1)
           Requires=different.service

           [Service]
           Desription=x

           $ systemd-analyze verify ./user.slice
           [./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
           [./user.slice:13] Unknown section 'Service'. Ignoring.
           Error: org.freedesktop.systemd1.LoadFailed:
              Unit different.service failed to load:
              No such file or directory.
           Failed to create user.slice/start: Invalid argument
           user.slice: man nosuchfile(1) command failed with code 16

       Example 4. Missing service units

           $ tail ./a.socket ./b.socket
           ==> ./a.socket <==
           [Socket]
           ListenStream=100

           ==> ./b.socket <==
           [Socket]
           ListenStream=100
           Accept=yes

           $ systemd-analyze verify ./a.socket ./b.socket
           Service a.service not loaded, a.socket cannot be started.
           Service [email protected] not loaded, b.socket cannot be started.

ENVIRONMENT
       $SYSTEMD_PAGER
           Pager to use when --no-pager is not given; overrides $PAGER. Setting this to an empty string or the
           value "cat" is equivalent to passing --no-pager.

       $SYSTEMD_LESS
           Override the default options passed to less ("FRSXMK").

SEE ALSO
       systemd(1), systemctl(1)

GTK主题黑边问题

自从用了LXDE之后,大部分gtk应用[主要是gnome组件]全部自带大黑框特效。解决方法就是对你正在用的主题路径下的个gtk-widget.css文件做如下修改:

这里我是修改 /usr/share/themes/Numix/gtk-3.0/gtk-widgets.css

把其中的.window-frame和.window-frame:backdrop<span style="font-size: 13px; line-height: 19.5px; white-space: pre-wrap; background-color: #fefef2;">两系列换成以下文本即可:</span>

.window-frame, .window-frame:backdrop {
    box-shadow: 0 0 0 black; /* removes shadow completely */
    border-style: none;
    margin: 1; /* this retains the ability to resize with the mouse, if 1px is too narrow, set some higher values */
    border-radius: 0;
}

最新文章

最近回复

分类

  • 默认分类 (24)
  • 运维 (53)
  • docker (1)
  • 动漫 (19)
  • 科普知识 (15)
  • 苍白边缘 (17)
  • 资源 (12)
  • Linux (58)
  • Arch Linux (19)
  • 计算机 (18)
  • 编程 (3)
  • Java (4)
  • python (0)
  • php (0)
  • 前端 (1)
  • 公告 (1)
  • 归档




      其它