Git practices #10
Git practices #10
Conversation
…can move on to the practical stuff
Yxhej
left a comment
Yxhej
left a comment
There was a problem hiding this comment.
There's a ton of text walls that really should be separated by something else (images, gifs, animations, code blocks, etc.) Aside from that, very good work!
After reassessing, you should look at our README (i am aware it's not on the main branch) and at some of our other reference sheets to get a general idea of what we're looking for. Notice that they're fairly concise, to the point, and link elsewhere for more complex and in-depth learning. Please modify the document, especially in the conceptualization, to fit these values. Humor is fine, as long as it doesn't come at the cost of a ton of extraneous text that can be hard to navigate through. |
|
|
||
| `"idk if its even worth it anymore. like idk if i have the capacity to keep going"` | ||
|
|
||
| Answers: |
There was a problem hiding this comment.
These answers render on GitHub as being part of one line, which is weird and definitely not how it should look. Try modifying it a bit maybe?
|
|
||
| Two people on a branch is not the only situation when you'd use stash. Sometimes, you want to write something a different way, but want to keep your changes just in case you change your mind. In this scenario, you can just stash your working changes, then rewrite it all, and if you don't like the rewrite, all you have to do is pop! Stashed changes restored. | ||
|
|
||
| ### Merging |
There was a problem hiding this comment.
This section remains far too long. Cut it down
reference-sheets/GitPractices.md
Outdated
|
|
||
| When you're finally done with your changes on a branch, and you are sure that it is absolutely perfect, you create something called a **Pull Request** on GitHub, to merge it to the main branch and be added to the main codebase. Someone with merge permissions (an admin of the repository) will look over your code, indirectly humble your coding skills, and then tell you what to change before your code can be added to main. After the person reviewing your code thinks that it is perfect, they will approve it and you can then **merge your code into main**, bringing your changes officially into the codebase! | ||
|
|
||
| Merging is how you transfer code from **branch to branch**. This, of course, will include transferring code **from** main **to** your branch, to stay updated with recent changes to main. If other people make a pull request and it gets approved, then the main branch will have some new code that is **not** currently in your working branch. This means that you are **not** up to date with main. Therefore, you need to **merge main into your branch** every now and again to make sure that everything is up to date. When you merge main into your branch, there may be conflicts, especially if the file being edited by both you and the other contributor are the same. These are called **Merge Conflicts**, and can happen both with merging **and** with pulling changes from a branch. You just have to sort these out manually, deciding which changes to keep and which changes to toss. It's a little annoying to do, but if you do it often enough and efficiently enough then it doesn't become that big of a problem. |
There was a problem hiding this comment.
There's still a lot of verbosity and text that can be cut, but here I suggest you can focus on making spacing more of a habit. This presents as a large wall, which is undesirable.
However, it can be cut up into separate parts so that each sentence is easier to focus on and read. In this paragraph above, you can definitely cut it into separate sections of 1) introducing merging, 2) the PR example, and 3) introducing merge conflicts.
While they do all connect with each other, the period and the start of the next sentence don't have to be so intimate to get the point across. In fact, it makes it easier to follow and reread because there's just that much more room.
This idea can be applied everywhere through the document and SciGuides as a whole, and it's also likely something to address for all contributors.
There was a problem hiding this comment.
This still very much applies! See the changes I made in the latest commit for pointers.
Really just avoid huge paragraphs---they should not look like a body from any of my APUSH essays
reference-sheets/GitPractices.md
Outdated
| If you're not using VSCode, | ||
| Windows: Press *Win + X* to open the Command Prompt. | ||
| Mac: Press *Cmd + Space* to open spotlight search, then type "Terminal" to open the Terminal. | ||
| Linux: Spin around five times and then sing Mary Had A Little Lamb. |
There was a problem hiding this comment.
I feel like we should give the solution anyway, by principle. You can just add a note in parentheses at the end of that gives the solution for the most popular distros, or just tell them to consult their distro's documentation.
Conceptualization section:
Explains all the concepts and situations for the git commands, and defines most key terms used in git intuitively and in a way that's easy to understand. Also gives some context for some good git practices.
Usage section:
Goes through all command line inputs for using git. Also talks a little bit about issues they'll run into and how to fix them, as well as some good practices (ofc).
Everything is explained with a hint of humor to make the content much more digestible.
No ChatGPT used, because i like suffering.
have fun reading!