对于有经验的Git用户来说,这是一个非常简单的问题。 我在git托管上创建了存储库并设置了我的电脑:
git init
git remote add origin git@*.sourcerepo.com:*/ *.git
然后,经过一些改变后我做了:
git add .
git commit
git push
所有这些操作都是在第一台开发者电脑上完成的。
现在的问题是:第二个开发人员如何访问并对repo进行更改? 首先,他必须克隆回购?
答案 0 :(得分:6)
是的,你会使用克隆。您还应该确保设置sharedrepository配置选项:
git config core.sharedRepository "true"
您还应该知道,对于多个提交者,fetch选项可以让您预览主存储库中的更改,以及它们将如何应用于您:
git fetch
git diff origin
或者您可能只想查看文件列表并分别对每个文件进行区分:
git diff --name-status origin
答案 1 :(得分:3)
是。这将是
git clone $giturl
git add .
git commit
git push
对他而言。
答案 2 :(得分:0)
当多个开发人员正在应用补丁时要当心选项:
在Git 2.30(Q1 2021)中,“ git apply
”根据core.sharedRepository
的设置错误地调整了工作树文件和目录的权限位,并且
纠正了很长时间。
apply
:请勿使用core.sharedRepository创建工作树文件
core.sharedRepository
定义了在$ GIT_DIR中创建文件时,Git应该设置哪些权限,以便可以与其他用户共享存储库。但是(以当前格式),该设置不应影响工作树中文件的创建方式。
在创建前导目录时,
apply
和am
(使用apply
)不尊重这一点:$ cat d.patch diff --git a/d/f b/d/f new file mode 100644 index 0000000..e69de29
在没有设置的情况下应用:
$ umask 0077 $ git apply d.patch $ ls -ld d drwx------
应用以下设置:
$ umask 0077 $ git -c core.sharedRepository=0770 apply d.patch $ ls -ld d drwxrws---
仅前导目录受到影响。
这是因为它们是用safe_create_leading_directories()
创建的,它调用adjust_shared_perm()
来基于以下内容设置目录的权限core.sharedRepository
。要解决此问题,让我们介绍该函数的一个变体,该变体将忽略设置,并在
apply
中使用它。
还要在功能文档中添加回归测试和关于使用的注释 每个变量根据目标(工作树或git dir)的不同。