Centralized workflows, chapt 5.1
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 38/100
- issue の種類
- ドキュメント
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- git
調査の方向性
Start with chapter 5.1, Distributed Workflows, and review the two quoted paragraphs about centralized workflows alongside the reported merge-before-commit distinction. Clarify the comparison between Git and centralized version control in the book source, with the chapter's explanation making the differing workflows unambiguous.
索引モデルが issue の本文から書いたものです。
説明
There's no existing/similar bug report.
- I have searched the existing issues
This report is about a single actionable bug.
- I'm reporting a single actionable bug
This report is about the ProGit book, version 2, English language.
- This bug is not about a translation or old version
Bug covers book website/pdf
- I confirm the bug is about the book as found on the website/pdf
Problem is present in the Pro Git book on the website?
- This bug also affects the Pro Git book as published on the website.
Which version of the book is affected?
Source files
Describe the bug:
I'm in the middle of translating this chapter to Swedish. I've read this section times and times again, and the comparisons don't add up for me:
This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems. The second developer must merge in the first one’s work before pushing changes up, so as not to overwrite the first developer’s changes. This concept is as true in Git as it is in Subversion (or any CVCS), and this model works perfectly well in Git.
If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git. Simply set up a single repository, and give everyone on your team push access; Git won’t let users overwrite each other.
This gives the impression that Git functions the exact same way like a CVCS if you just give all contributors write access to a single repository. But, and this a honestly asked question that I don't have the answer to, would it really be possible to collaborate with Git and not have your own local repo? And first merge, then commit? For all I know, Git won't let you merge if you have any current changes that aren't committed.
So, the concept of having to merge changes is something you do in both systems, but not the approach (merge-before-commit vs commit-before-merge).
Steps to reproduce:
- Go to chapter 5.1
Expected behavior:
I was expecting a clearer distinction between a CVCS and DVCS.
Screenshots:
No response
Additional context:
No response
Device
No response
Operating system
No response
Browser/application + version
No response
- 主要言語
- CSS
- スター
- 6.6k
- フォーク
- 2.1k
- PR マージ指標
- 30日以内にマージされた PR はありません
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
progit/progit2 のほかの issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
enhancement
難易度 1/5 1時間未満 初心者へのやさしさ 82/100
-
enhancement
難易度 1/5 1〜3時間 初心者へのやさしさ 65/100
似ている issue
-
Link Checker Report オープンautomated issue report
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
Humanity AI オープン
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
numfocus/project-fundraising#166 ·
-
area:proxy bug security severity:low track:open-source
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100