Git and the DevOps Workflow

Fifteen engineers can edit one product on the same afternoon. Without a record, they overwrite each other, and you lose the ability to say who introduced a line. Git is the tool the industry uses as that record. It is a distributed version-control system: a history of the code, with an author and a time on each change.

For a lawyer, the repository is where the intellectual property actually sits. An assignment that does not mention it is an assignment of an idea of the code, not of the files.

The words

Repository. The folder of source files plus their history, usually on GitHub, GitLab, or Bitbucket. When a contractor is paid to build, the clause should say that what they commit to the client’s named repository is the deliverable being assigned.

Branch. A copy of the project where one person can work without touching the live line. The live line is often called main.

Commit. A saved point in that history, with a message such as “fix the payments webhook on sign-in.” It is not a casual save. It is an entry you can later point to.

Pull request. The request to bring a branch back into main. Someone reviews it. If it is accepted, the history records who merged it. If a later build leaks data, or a copied algorithm appears, this is the audit trail: which change, whose name, what date.

DevOps

DevOps is the practice of moving code from a laptop to the repository and then to the servers users touch, with as little hand-carriage as possible. The usual machinery is called CI/CD: continuous integration and continuous deployment. A pipeline can refuse a change that fails tests before it reaches production. You will not operate the pipeline. You should know that “we deployed” means a recorded change left a branch and reached a server, and that the log is evidence.