git最佳实践
by Hemal Patel
通过赫马尔·帕特尔
Git最佳实践如何为我节省大量的返工时间 (How Git best practices saved me hours of rework)
Recently I was working on the task to upgrade a certificate for a NodeJS application. This was last touched two years ago for a feature enhancement. Any live issue raised to this app would require immediate attention, although the app has only been used internally.
最近，我正在从事为NodeJS应用程序升级证书的任务。 这是两年前为功能增强而修改的。 尽管此应用仅在内部使用，但任何引发到此应用的实时问题都需要立即关注。
The app is old. Core-NodeJS-Infra modules have not been updated for more than two years. Downstream services are deprecated. The way we call downstream services is changed. The tight deadline is a cherry on the cake. I knew it was gonna be a roller-coaster ride.
该应用程序很旧。 Core-NodeJS-Infra模块已更新两年以上。 下游服务已弃用。 我们称为下游服务的方式已经改变。 紧迫的最后期限是蛋糕上的樱桃。 我知道那将是过山车。
I spent three days getting the app running.
我花了三天时间使应用程序运行。
Infra-modules are updated? Check.
基础模块是否已更新？ 检查一下
Downstream services are working fine? Check.
下游服务正常吗？ 检查一下
UI flows are working fine? Check.
UI流程运行正常吗？ 检查一下
One of our team members had touched the app for an upgrade over a year ago. He pointed out that the repo from where I forked was itself a forked repo. Some other team had worked on that repo, and then our team worked on the original repo from that point onwards — but my team member doesn’t know from what point onwards. So it was a bit of a mess!
一年多以前，我们的一名团队成员曾触摸过该应用程序以进行升级。 他指出，我分叉的仓库本身就是一个分叉的仓库。 其他团队已经在该仓库中工作，然后我们从那时开始就在原始仓库中工作，但是我的团队成员不知道从什么时候开始。 所以有点混乱！
We have an “Ownership” tool which shows the correct repo and it “lied” to me. So the situation was like this:
我们有一个“所有权”工具，它显示正确的回购，并且对我“说谎”。 所以情况是这样的：
Yes, it was Forkception! WTF and FML were the first two thoughts that came out of my mouth. I should have worked on the live repo but, instead, I worked on a fork which was stale. How stupid of me!
是的，那是Forkception！ WTF和FML是我口中的头两个想法。 我应该在实时回购工作，但， 相反 ，我曾在一个叉这是陈旧的。 我真蠢！
First thought — my three days of work have been wasted, and I need to start fresh.
首先想到的是-我三天的工作已经浪费了，我需要重新开始。
Second thought? Let me ask my old friend Git?. He has been helping me for a very long time.
第二个想法？ 让我问我的老朋友吉特？ 他一直在帮助我很长时间。
Me — “Hey Git? I’m in a deep trouble and I need your help resolving this issue.”
我 -“嗨，吉特？ 我陷入了严重的麻烦，需要您的帮助来解决这个问题。”
Git — “Hey! Ok, so we have to start from whatever is in live first. Create a new branch-called upgrade, and point that branch to the live code. You can use a git hard reset for that.”
Git- “嘿！ 好的，所以我们必须从现场直播开始。 创建一个新的分支，称为upgrade ，然后将该分支指向实时代码。 您可以为此使用git hard reset 。”
Me — “Ok, I will.”
我 -“好的，我会的。”
At this point, the situation looks like this.
此时，情况看起来像这样。
Git — “We need to know what changed between develop and upgrade. Can you list out the files that differ between your upgrade and develop? Check those files individually, and figure out what kind of changes there were.”
Git —“我们需要知道在开发和升级之间发生了什么变化。 您能否列出升级和开发之间不同的文件？ 单独检查这些文件，并找出有哪些更改。”
Me — “Cool. I see three kinds of changes. There is a service S1 which I need to call in a different way. There is a service S2 which I need to call using a different endpoint. There is a service S3 which I need to call using different parameters. I also see the package.json file in the upgrade branch has some of the packages already upgraded. So only a few packages need to be changed.”
我 -“酷。 我看到了三种变化。 我需要以其他方式调用服务S1。 我需要使用其他端点来调用服务S2。 我需要使用不同的参数调用服务S3。 我还看到了upgrade分支中的package.json文件，其中一些软件包已经升级。 因此，只需更改少数软件包即可。”
Git — “Awesome that you segregated the changes. Now show me the Git log of your develop branch. Hope you have followed some basic Git practices, for example always having buildable code in each commit. The commit message should depict what you have changed.”
Git —“很棒，您隔离了更改。 现在，向我展示您的develop分支的Git日志。 希望您遵循一些基本的Git惯例，例如，每次提交中始终具有可构建的代码。 提交消息应说明您所做的更改。”
Me — “Yes, I have a total of four commits in the develop branch. One commit was for making the project buildable. There is one for each of the three service calls. ”
我 -“是的，我在development分支中总共有四个提交。 一项承诺是使该项目可构建。 三个服务呼叫中的每个呼叫都有一个。 ”
Git — “Perfect! It seems like you have followed best practices properly. Let’s start by stabilizing the project build by making package.json up-to-date. Checkout to the upgrade branch and make a duplicate of package.json — package-copy.json. Now, using Git replace , upgrade/package.json with develop/package.json, and run the diff between package.json and package-copy.json. Since, the live code has some of the packages changed already, and has different versions, you will need to upgrade by looking at the diff.”
Git- “完美！ 看来您已正确遵循最佳做法。 让我们从更新package.json到稳定项目构建开始。 检出到upgrade分支，并复制package.json — package-copy.json。 现在，使用Git replace ，将upgrade / package.json与developer / package.json一起运行，并在package.json和package-copy.json之间运行差异。 由于实时代码已经更改了一些软件包，并且具有不同的版本，因此您需要通过查看差异进行升级。”
Me — “Let me try that. Ok, it is building and running.”
我 -“让我尝试一下。 好的，它正在构建并运行。”
Git — “Awesome! Now, let’s work on the service calls. I see that you have one commit for each service-call change in the develop branch. Time to cherry pick. Pick from least complicated service call to the most complicated service call. Pick, merge, and resolve conflicts. Make sure to check if the project is in buildable condition after each cherry-pick and before each commit.”
Git- “太棒了！ 现在，让我们开始服务电话。 我看到您对开发分支中的每个服务调用更改都有一个提交。 该摘樱桃了 。 从最不复杂的服务电话中选择最复杂的服务电话。 选择，合并和解决冲突。 确保在每次选择之后和每次提交之前检查项目是否处于可构建状态。”
Me — “S1 done. S2 done. S3 done. Thanks, Git”
我 -“ S1完成了。 S2完成。 S3完成。 谢谢，吉特”
Git — “You’re welcome. But it is you who have helped yourself, by following Git commit practices, and not treating Git as a mere code-storage.”
Git —“不客气。 但是您是通过遵循Git的提交实践而不是将Git仅仅视为代码存储来帮助自己的。”
我在这里做什么？ ？ (What did I do here? ?)
提交相关更改 (Commit Related Changes)
Take a pause for a moment and think if this change should go in this commit. A commit which says that “change: service-s1 endpoints” and has service-s2 changes would just create confusion.
暂停片刻，然后考虑是否应在此提交中进行此更改。 提交内容为“更改：service-s1端点”并且具有service-s2更改的提交只会造成混乱。
不要做半成品 (Don’t Commit Half-Done Work)
We have often heard the “commit early, commit often” mantra. In the above example, you can have one commit for different endpoints of the same service. This is called Sausage Making.
我们经常听到“尽早提交，经常提交”的口头禅。 在上面的示例中，您可以针对同一服务的不同端点进行一次提交。 这就是所谓的香肠制作 。
However, I personally squash my small commits using git rebase interactive mode. This helps me to have one logical change, which can be certified, and it helps a Trusted Committer to review your code as well. This is much preferable for large-scale projects.
但是，我个人使用git rebase交互模式压缩了小的提交。 这可以帮助我进行一个可以进行认证的逻辑更改，还可以帮助受信任的提交者查看您的代码。 这对于大型项目是更可取的。
提交前测试代码 (Test Your Code Before You Commit)
We should think of Git as a state machine, and any machine should be in buildable condition at any state.
我们应该将Git视为状态机，任何机器在任何状态下都应处于可构建状态。
写好的提交信息 (Write Good Commit Messages)
This is a most crucial part. I always pause for a moment and think whether I will be able to understand — after three months — the kind of change in this commit by just looking at the commit message.
这是最关键的部分。 我总是停顿片刻，思考三个月后是否能够通过仅查看提交消息来了解此提交中的更改类型。
结论 (Conclusion)
I was able to quickly resolve the mess. I could come out of that WTF and FML moment just because I followed some good practices. They exist for a reason and are like salt in food — you only realize their value when they are not used.
我能够Swift解决问题。 我可以从WTF和FML的时刻中脱颖而出，只是因为我遵循了一些良好的做法。 它们的存在是有原因的，就像食物中的盐一样-您只有在不使用它们时才意识到它们的价值。
Mistakes will happen sooner or later, unconsciously. But make sure you consciously follow some practices around Git.
错误迟早会在不知不觉中发生。 但是，请确保您有意识地遵循有关Git的一些实践。
I’m a fan of Git semantic commit messages, which help to navigate through the Git history. Because, let’s be honest, you can’t expect everyone to use the same words for each commit message. However, message-type can be expected.
我是Git语义提交消息的支持者 ，该消息可帮助您浏览Git历史记录。 因为，说实话，您不能期望每个人对每个提交消息都使用相同的词。 但是，可以预期消息类型 。
This helps make sure that, after each commit, your project can be built — which is really helpful.
这有助于确保在每次提交后都可以构建您的项目，这确实很有帮助。
VSCode has sick support for Git. It becomes super easy to see the conflicts and resolve them, sometimes with just a single click. See the below example ?
VSCode对Git的支持不佳。 有时只需单击一下，即可轻松看到并解决冲突，这非常容易。 看到下面的例子吗？
参考文献 (References)
Git Tip ?: How to “merge” specific files from another branch
Git提示？：现在可以“合并”来自另一个分支的特定文件
Git Tip ?: Git — git-cherry-pick Documentation
Git提示？：Git — git-cherry-pick文档
Git Tip ?: Git — git-reset Documentation
Git提示？：Git — git-reset文档
Special thanks to my friends Saurabh Rajani and Anish Dhargalkar who helped me with content refinement.
特别感谢我的朋友Saurabh Rajani和Anish Dhargalkar ，他们帮助我完善了内容。
翻译自: https://www.freecodecamp.org/news/how-git-best-practices-saved-me-hours-of-rework-cf227bad9a50/
git最佳实践
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
