These rules define how an AI coding agent should plan, execute, verify, communicate, and recover when working in a real codebase. Optimize for correctness, minimalism, and developer experience.
I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again.
I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:
| FROM golang:1.21.0-bullseye as builder | |
| COPY . /workdir | |
| WORKDIR /workdir | |
| ENV CGO_CPPFLAGS="-D_FORTIFY_SOURCE=2 -fstack-protector-all" | |
| ENV GOFLAGS="-buildmode=pie" | |
| RUN go build -ldflags "-s -w" -trimpath ./cmd/app |
| # Licensed to the Apache Software Foundation (ASF) under one or more | |
| # contributor license agreements. See the NOTICE file distributed with | |
| # this work for additional information regarding copyright ownership. | |
| # The ASF licenses this file to You under the Apache License, Version 2.0 | |
| # (the "License"); you may not use this file except in compliance with | |
| # the License. You may obtain a copy of the License at | |
| # | |
| # http://www.apache.org/licenses/LICENSE-2.0 | |
| # | |
| # Unless required by applicable law or agreed to in writing, software |
This document serves as a way for this project's maintainers to document their process of getting their repository ready for the 2020 Hacktoberfest alongside the Virtual Coffee Hacktoberfest Initiative. We also hope this project continues beyond just Hacktoberfest, and so we thought it best to collect all the knowledge, resources and learnings we pick up along the way in one central place, both for our own reflection, as well as sometimes that others can use to create welcoming and valuable spaces for their own open source contributions.
While we will try as best as possible to create a body of knowledge that is accessible and understandable to everyone who finds it, we hope you understand that this may not always be as comprehensive, current or exact as you may want to be. The language will be more candid that you might find in your typical technical documentation, and YMMV _(Your
The intention of this document is to provide some guidance and suggestions to customers who are wondering how they should structure organizations and teams in their GitHub Enterprise environment. The idea isn't to give hard and fast rules on which approach is better than the other, but to give examples of when one approach might be preferable to another depending on the use case.
________________
| Org |
| ______ |
| | |\ |
| | Repo | \ |
To rename your Git master branch to main, you must do the following steps:
Navigate to your repository in the command line and issue the following commands:
- git branch -m master main
- git push -u origin main
Change your default branch on GitHub by going to your GitHub repository in your browser, and navigate to Settings > Branches and click on the dropdown and switch from master to main and click Update (this will only show if you have two or more branches). The main branch is now your default branch.
Update the tracking of the branch from your command line with the following command:
- git branch -u origin/main main
Sometimes, debugging with console.log is not enough to find out what is
happening in the code, as console.log prints only plain objects but neither
functions nor objects with circular references. Besides, it's possible you
may need to know the context and flow of the code.
Read more about debugging with VS Code in VS Code: Debugging.
