jsp修改数据库代码_正确地对代码库进行更改

jsp修改数据库代码

The difference between a good and a bad commit can be huge. It’s no fun having to ask your colleague — or your past self — what a particular change was about, or what the current state of things is. If you commit changes to your codebase the right way, you can avoid headaches down the road.

一次好和一次差的提交之间的差异可能很大。 询问同事或过去的自我，这是什么意思，这是什么有趣的事，或者当前的状况是什么。 如果您以正确的方式提交对代码库的更改，则可以避免日后的麻烦。

This article aims to provide a thorough guide to the best practices of software commits.

本文旨在提供有关软件提交最佳实践的详尽指南。

何必呢？ (Why Bother?)

If you’re already storing your projects on GitHub, you might assume the files are safe and that whenever you need to update code you’ll pull the changes, and that’s enough. All of that might be true. But let’s see what potential problems you can avoid by going the extra mile, and what additional benefits await if you do.

如果您已经将项目存储在GitHub上，则可以假设这些文件是安全的，并且每当需要更新代码时，都将进行更改，这就足够了。 所有这些可能都是正确的。 但是，让我们看看通过加倍努力可以避免哪些潜在的问题，以及这样做还有哪些其他好处。

没有人是孤岛，无论是团队合作还是个人 (No Man Is an Island, Either in Teams or Individually)

The reasoning above typically comes from a developer used to working alone. But the moment they need to share code with somebody else, we can expect that things are going to get messy and require a lot of explanation. Like, a lot.

上面的推理通常来自习惯于独自工作的开发人员。 但是，当他们需要与他人共享代码时，我们可以预料事情会变得混乱，并且需要大量解释。 就像， 很多 。

Remember that our work doesn’t end at just writing code. We also need to manage things, and that requires a degree of organization and methodology. And while working in teams more readily exposes the problems caused by poor organization, we can also benefit from a better approach when working by ourselves.

请记住，我们的工作并不仅限于编写代码。 我们还需要管理事物，这需要一定程度的组织和方法。 尽管在团队中工作更容易暴露出组织不善所导致的问题，但当我们自己工作时，我们也可以从更好的方法中受益。

原子与膨胀承诺 (Atomic vs Bloated Commits)

We’ve all needed to revert a small change and found ourselves searching for it when a massive commit changes dozens of files and adds multiple features. How much easier would the rollback be if it was located in one commit that only addressed that specific issue?

我们所有人都需要还原一个小的更改，并发现自己在大规模提交更改数十个文件并添加多个功能时正在寻找它。 如果回滚位于仅解决该特定问题的一次提交中，回滚将有多容易？

凌乱，肿胀的方式 (The Messy, Bloated Way)

git add *
git commit -m "new components"

In this example, we can bet that a large number of files are being affected. Additionally, the message “new components” doesn’t tell us much of anything — such as what components, which functionality for those components, and if the functionality is new or a refactor. Also, are any existing bugs being addressed?

在此示例中，我们可以打赌大量文件正在受到影响。 此外，“新组件”消息并没有告诉我们任何信息-例如哪些组件，这些组件的功能以及该功能是新功能还是重构功能。 此外，是否解决了任何现有的错误？

That information will be important when we need to change or recover something. We’ll be trying to find a needle in a haystack, and we might just end up looking at the codebase instead and spending valuable time debugging while we’re at it.

当我们需要更改或恢复某些东西时，这些信息将很重要。 我们将试图在大海捞针中找到一针刺刀，然后我们可能最终只是看一下代码库，并在调试时花了宝贵的时间进行调试。

原子方式 (The Atomic Way)

git add ui/login.html static/js/front-end.js
git commit -m "validate input fields for login"

Now we’re getting somewhere, as we start to have a clearer idea of what’s going on with that one commit.

现在，我们取得了一些进展，当我们开始有什么事情与一个承诺的一个清晰的概念。

The trick is that we can semi-automatically commit changes as part of our workflow. That is, doing a block of work that does something very specific (implementing particular functionality, fixing a bug, optimizing an algorithm), testing (and write a unit test, if need be), adding a description while our memories are fresh, and committing right away. Rinse and repeat.

诀窍在于， 我们可以半自动提交更改作为工作流的一部分 。 也就是说，这样做，做了非常具体的(实现特定功能，修复bug，优化的算法)，检测工作中的一个区块 (写一个单元测试，如果需要的话)，添加描述，而我们的记忆是新鲜的，并立即承诺。 冲洗并重复。

良好承诺的结构 (The Structure of a Good Commit)

These rules aren’t carved in stone, but can help you estimate what a good commit might look like:

这些规则并不是一成不变的，但是可以帮助您估算良好的提交看起来是什么样的：

• unambiguous: no second guessing about what those commit changes do.

  明确的 ：没有第二次猜测那些提交更改会做什么。

• insightful: clearly describing what the code does, even providing links or extra information when necessary, and marking the bugs or issues that are being addressed.

  有见地 ：清楚地描述代码的作用，甚至在必要时提供链接或其他信息，并标记要解决的错误或问题。

• atomic: addressing one single thing at the time (think of a “block of work”, which could be anything from 20min to 2h, or even 2min if it was a quick bugfix).

  原子的 ：一次只解决一件事情(例如“工作量”，可能是20分钟至2小时，如果是快速的错误修正，则可能是2分钟)。

Let’s look at a template and break it down:

让我们看一下模板并将其分解：

<type/component/subsystem>: <subject>
<BLANK LINE>
<body>

类型，组件或子系统 (Type, Components, or Subsystem)

This would be a set of functionalities on a software project that can be grouped together. For instance, what AngularJS calls types, or what SrummVM calls subsystems.

这将是可以组合在一起的软件项目上的一组功能。 例如， AngularJS调用类型 ，或者SrummVM调用子系统 。

例子 (Examples)

On my projects I often use the term “component”, with some examples being:

在我的项目中，我经常使用“组件”一词，例如：

• i18n, l18n
  i18n，l18n
• authentication
  认证方式
• other, 3rd party
  其他，第三方
• QA, tests
  质量检查，测试
• tools
  工具
• UI, GUI
  UI，GUI

(必修)科目 (The (Mandatory) Subject)

The subject is a simple, straightforward line that describes what the commit does so that everybody can get a solid idea on their first glance.

该主题是一条简单明了的代码行，描述了提交的操作，以便每个人乍一看都可以得到扎实的想法。

When it comes to formatting the subject, I often follow these simple guidelines:

在设置主题格式时，我经常遵循以下简单准则：

1. use the imperative (“change” instead of “changed”)
   使用命令(“更改”而不是“更改”)
2. don’t capitalize the first letter
   不要大写第一个字母
3. no period (.) at the end
   最后没有句号(。)
4. append “(…)” if there’s an optional body available
   如果有可选的正文，请附加“(…)”

例子 (Examples)

These would be some valid subjects:

这些将是一些有效的主题：

• i18n: support simplified Chinese (zh-hans)
  i18n：支持简体中文(zh-hans)
• auth: refactor Google Sign-In
  auth：重构Google登录
• other: add jQuery 3.4.1
  其他：添加jQuery 3.4.1
• QA: pass AWS deployment test (…)
  质量检查：通过AWS部署测试(…)

As you can see, there’s no guessing involved as to what these commits do, and on the last QA commit we can also see that there’s more information available (perhaps links to the relevant documentation, or further explanation for the fix).

如您所见，没有关于这些提交功能的猜测，并且在上一次质量检查提交中，我们还可以看到有更多可用信息(也许链接到相关文档，或对该修复程序进行进一步说明)。

(可选)主体 (The (Optional) Body)

Occasionally, we’ll need to provide more detail than fits in a subject line to provide context, such as when fixing a persistent bug, or when hacking an algorithm.

有时，我们需要提供比主题行更合适的细节以提供上下文，例如，修复持久性错误或破解算法时。

In these cases, you can simply enter a double break line (so the subject works as a title), and enter as much information as needed.

在这种情况下，您只需输入一个双折线(使该主题充当标题)，然后根据需要输入尽可能多的信息。

例 (Example)

For our previous QA commit, we could do something like this:

对于之前的质量检查提交，我们可以执行以下操作：

QA: pass AWS deployment test (...)

I added a `DJANGO_SETTINGS_LIVE` environment variable to 
[AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/)'s 
`django.config` file, so that the synchronization management commands 
in `db-migrate` are _only_ executed in production.

As you can see, the body can be harder to follow, and that’s okay, as it’s intended for those who are actively looking for more detail. Anyone can get an idea of what the commit does just by reading the subject, and the body will serve for further context, saving us back-and-forth emails or exchanges on Slack!

如您所见，身体可能很难跟随，这没关系，因为它是为那些正在积极寻求更多细节的人而设计的。 任何人都可以通过阅读主题来了解提交的作用，而正文将为进一步的上下文服务，为我们节省来回的电子邮件或Slack上的交流！

— “Hey, how did you get to …”

—“嘿，你怎么去的……”

— “Read the commit 😑.”

—“读提交😑。”

不要忘记解决问题！ (Don’t Forget to Address Issues!)

Finally, there’s the issue of addressing issues (pun!). Any decent mid-to-large software development project should use an issue tracker as a way to keep track of tasks, improvements, and bugs — whether it’s Atlassian Jira, Bugzilla, GitHub’s issue tracker, or another.

最后，是解决问题(双关语)的问题。 任何体面的中型到大型软件开发项目都应使用问题跟踪器来跟踪任务，改进和错误-无论是Atlassian Jira ， Bugzilla ， GitHub的问题跟踪器还是其他。

问题管理 (Issues Management)

In case you didn’t know, with most systems you can manage issues right from the commit message!

如果您不知道，在大多数系统中，您可以直接从提交消息中管理问题！

You can:

您可以：

• close/resolve an issue

  关闭 / 解决问题

• re-open an issue if it has been closed before

  重新打开问题(如果之前已关闭)

• hold an issue, should a feature be postponed for later

  持有一个问题，如果一个功能被推迟后

All it takes is using those keywords with the ID number for the issue.

所要做的就是使用带有ID号的关键字来解决问题。

例子 (Examples)

• tools: consolidate DB data with cron job; resolve #46
  工具：使用cron作业合并数据库数据； 解决＃46
• UI: add routine to serialize user input; bug found, open #32
  UI：添加例程以序列化用户输入； 发现错误，打开＃32
• auth: comment out Facebook login; hold #12
  auth：注释掉Facebook登录名； 举行＃12

Additionally, you can still reference an issue as a way of providing context, even if you don’t want to modify its status — for example, “see #12”.

此外，即使您不想修改其状态(例如，参见“＃12”)，您仍然可以将其作为提供上下文的一种方式来引用。

All of these references will be visible to anybody opening that issue on the tracker, which makes it easy to follow the progress for a given task or bug.

所有这些参考对于在跟踪器上打开该问题的任何人都是可见的，这使跟踪给定任务或错误的进度变得容易。

结语 (Wrapping It Up)

You won’t always get it right (I, for one, don’t!). Things will get messy and from time to time you won’t follow the rules you’ve set for yourself or your team — and that’s part of the process. But hopefully, you know that you can be very organized with just a few upgrades to your workflow, saving yourself and your team time over the long run.

您将永远不会做对(我，一个，不要！)。 事情会变得一团糟，您有时会不遵守为自己或团队设定的规则-这是流程的一部分。 但希望您知道，只需对工作流程进行一些升级，您就可以组织得井井有条，从长远来看可以节省您自己和团队的时间。

I’ve also established from experience that it makes little difference whether a project involves ten developers or if it’s handled entirely by you. Simply put, commit changes to your codebase the right way — it’s a crucial part of good project management.

我还根据经验确定，一个项目涉及十个开发人员还是完全由您处理，这几乎没有什么区别。 简而言之， 以正确的方式对代码库提交更改-这是良好的项目管理的关键部分 。

进一步阅读 (Further Reading)

• Telling stories with your Git history. A fun piece by Seb Jabocs on FutureLearn.

  用Git的历史讲故事 。 Seb Jabocs在FutureLearn上的有趣作品。

• Angular’s Commit Message Guidelines. Even if you don’t use Angular, this is a helpful read.

  Angular的提交消息准则 。 即使您不使用Angular，这也是很有帮助的阅读。

• FreeBSD Committer’s Guide. An in-depth guide on the topic if there is one.

  FreeBSD提交者指南 。 如果有的话，关于该主题的深入指南。

• How to Properly Organize Files in Your Codebase & Avoid Mayhem. We explain how to organize files for both large and small projects, offering some easy-to-follow best practices.

  如何在代码库中正确组织文件并避免混乱 。 我们将说明如何为大型和小型项目组织文件，并提供一些易于遵循的最佳实践。

• Jump Start Git. This concise guide is designed to help beginners get up to speed with Git in a single weekend.

  快速启动Git 。 这份简明的指南旨在帮助初学者在一个周末内掌握Git。

• Professional Git. This book from Wiley takes things further, giving developers the deep dive they need to become Git masters.

  专业Git 。 Wiley的这本书将事情做得更进一步，为开发人员提供了成为Git大师所需的深入探索。

翻译自: https://www.sitepoint.com/committing-changes-right-way/

jsp修改数据库代码