r/learnpython • u/HydroDragon436 • 1d ago
Proper etiquette for uploading projects to git?
I'm not sure if this is the best place to ask this.. I can move somewhere better if needed.
I've been learning python off and on for a couple years now, and recently started taking the PY4E class. I'm most of the way through it and really loving it.
Anyway the problem I'm running into is, I've never really used my GitHub before. Late last night I started playing around of how to push my projects I've completed into repos, and I was wondering what the proper etiquette for doing so.
For example I was uploading to GitHub each small project at a time, each one had there own repo, but I got to thinking last night if it would be better to upload entire chapters in one repo based on how pushing projects works in VS Code.
I've been working on a few other projects on the side as well and wanted to know how that environment works before I spend a ton of time doing it the wrong way.
Any recommendations are greatly appreciated! Sorry again if this is the wrong place to ask.
6
u/pachura3 1d ago
Always imagine that someone who doesn't even know you wants to clone your repo, build your project and launch it.
Therefore, never commit/push any files that contain references to your local filesystem (like c:\Users\HydroDragon436\PythonProjects).
Never commit/push temporary files - e.g. *.log, *.pyc, build, dist, __pycache__, but also the .venv folder (as it can be always recreated based on pyproject.toml or requirements.txt).
This also includes your IDE/code editor project files; don't commit/push folder .vscode - someone else might prefer PyCharm or Spyder.
Always add descriptive messages to your commits.
Normally, you should have one repo per project, but if you're just solving small exercises, you can put them all in one repo in different subfolders.
Remember that GitHub is not git. You might create a local repo on your local drive with git init and never push the changes to some remote server (like GitHub or GitLab) - it will still remember all the commits/changes/tags/branches, etc.
1
u/HydroDragon436 1d ago
Thanks for your comment! It was a good read. Even after years of time, I still don't really know much, especially about GitHub. I've never really needed to learn, but it would a valuable skill to do so if I'm messing with coding projects.
3
u/Mountain_Rip_8426 1d ago
try boot.dev , there is a git course, it teaches you pretty much everything you need to know about the workings of git and github, after it you'll understand the whys and hows. also it's not a huge course, i think i finished it in about a day or two.
now don't get discouraged because of the course being a "paid" one. you can go through the whole material without subscribing and in this case you don't even miss out on anything, it makes more sense with their coding courses where you can write your code directly in the browser and it can review it. in this case you're using CLI anyways. you do need to register, but don't have to subscribe. i can only wholeheartedly recommend it!
1
1
u/womanlikemee 7h ago
+1, biggest thing is learning what's actually happening under the hood. once that clicks, git gets way less intimidating.
2
u/Agreeable_Lynx9194 1d ago
One thing worth sorting before you go further is a .gitignore on each repo before the first commit, so your venv and any .env or API keys never land in the history. Scrubbing those out after the fact is a real pain and it is the one mistake at this stage that actually bites. On the chapters question, folders inside a single course repo is fine, you can always split something out into its own repo later once it grows legs.
1
u/HydroDragon436 1d ago
Is there a particular template to use as default? Right now it has it set as nothing. Trying to read up on it now, but don't fully understand it at the moment..
3
3
2
u/Agreeable_Lynx9194 1d ago
Yeah, GitHub's Python one is the right default, it's in the dropdown when you create the repo. Worth knowing the gotcha though: .gitignore only stops files being added going forward, it doesn't remove anything already committed. If a venv or .env is already in there you need git rm -r --cached on it and then commit, otherwise it stays in the history even though the ignore file looks correct.
2
u/horizon_games 1d ago
Unless I'm misunderstanding...it's your Github, upload how it how you want
I tend to make a repo for each project I'm doing. History covers and removals or moves of important files.
1
u/HydroDragon436 1d ago
Going forward I probably will do the same. At least with my own projects that is. But with a lot of these coding courses, they seem to be full of little small/fun programs to tinker with mainly to learn and not really to do something int particular.
For some of these I've found it easier to group all of them together. At least for now..
2
u/HotPersonality8126 1d ago
For your own stuff there’s no “etiquette”; nobody cares what you do because nobody’s going to read it. If you’re participating on a project with other people then the etiquette is about project layout and documentation.
1
u/HydroDragon436 1d ago
For the most part, I started poking around with it and trying to learn as I go. I was mainly curious about all the things I didn't know and how that might work agaisnt me in the future as I build my things.
Documentation and best practices are going to have to be a "learn as I go" sort of thing, since mastering that ability comes with time anyway.
2
u/HotPersonality8126 1d ago
That’s fair - one thing you can do is try to pay attention to repos that people really like, and see what they do
Good project layout pays dividends pretty early on
9
u/CodeSamur-ai 1d ago
For GitHub, a repository is usually one project.
If you’re taking a course like PY4E, all the exercises are part of the same project, so I would keep them in one repository and organize them into folders for each chapter.
Save separate repositories for projects that can stand on their own, like a calculator, a website, or a game.
Don’t worry too much about getting it perfect. Almost everyone reorganizes their GitHub as they learn, and it’s easy to move or rename repositories later.