☰

Git 重复克隆与拉取

tag-icon • tag-icon git
Git 重复克隆与拉取

用例：

我有 MyApp 将在 ClientX 上部署。我正在编写一个 shell 脚本来从我的 bitbucket 存储库中获取该分支

我的 shell 脚本（运行良好）

git clone -b $BRANCH_NAME https://[email protected]/MyApp/ecodrone.git

问题：

现在有了更新，是不是更好

  1. 每次都使用 git clone
  2. 一个 git-clone.sh 和一个 git-pull.sh？

答案1

如果您有持久存储，那么重新克隆将非常低效（尤其是克隆整个历史记录，因为您没有使用--depth=）。

同时，拉取/获取将仅接收实际已更改的对象。使用：

  • git fetch && git reset --hard "origin/$BRANCH_NAME"总是检索最新的提交，

  • 或者git pull --ff-only如果有人试图改写历史，你更希望它彻底失败。

不要使用平原git pull，因为在后一种情况下它可能会导致很大的混乱。

答案2

简短回答：

  1. git pull

为了更新，如果您与其他人在同一分支（和/或文件）上工作，最好使用 git pull 或 git fetch、rebase 和 merge，因为 git pull 仅在没有合并冲突的情况下才会尝试合并。

另外，基于您克隆的分支创建一个新分支也是一个更好的主意，这样可以更轻松地在您的计算机上本地解决合并冲突。这在工作流中通常称为功能分支。这样，一旦您的工作完成并提交，您就可以在主分支上运行 git pull（由于缺少名称，我将您克隆的分支称为 master），这应该不会出现任何问题，然后您可以将功能从 master 重新定位并合并（如果您希望保留功能分支日志/提交历史记录，请使用 --no-ff 标志，否则它将被压缩为一个提交）功能到 master。然后将您的工作（主分支）推送到上游。

应该是这样的：

git checkout -b feature
...work, stage changes & commit...
git checkout master
git pull upstream/master #or git pull origin master based on git remote urls
git checkout feature
git rebase -i upstream/master
git checkout master 
git merge --no-ff master feature
git push upstream #or git push origin

另外我不明白你为什么要再次克隆它，克隆应该是 git 存储库的一次性操作

相关内容