SYSTEM NOTICE

Auto translation by AI. Be sure, accuracy, nuances and authorial intent may not be fully reflected.
見出し画像

What exactly reaches the other person's computer when you 'publish to GitHub'?


IT stories you think you know but don't: Part 1


Back when I was obsessed with Arduino, every time I got a new sensor, it became a habit to 'look for someone else's sample first.' Camera modules, motor control, drone attitude control... whenever parts arrived, I would open GitHub, find sample code, and get it running.

There was joy in it. To be honest, I didn't really understand what I was doing at the time. What is a clone? What is inside the downloaded files? Where did the framework come from? I just moved on, thinking, 'It works, so that's fine.'



Time has passed since then, and now that I am on the side of publishing code myself, the questions that were vague back then have taken shape. What on earth actually reaches the other person's computer?


The answer is simple.

What gets uploaded to GitHub is only the code you wrote. Frameworks (large toolsets for running programs) are not uploaded to GitHub.

It might be easier to understand if you think of it like a cooking recipe. When you give someone a recipe, the ingredients are separate, right? You just hand them a piece of paper saying, 'Please try making this with this recipe,' and the person who receives it goes out to buy the ingredients themselves. Publishing to GitHub has exactly the same structure.


What is uploaded to GitHub: The code you wrote. The original recipe
Framework: Ingredients. The person who receives it prepares them themselves.
package.json: A list of materials saying, 'You need this and that.'




What does the person who receives it do?

The person who gets the code from GitHub first types one command: `npm install`. Then, the computer automatically reads the material list and collects all the necessary tools from a warehouse on the internet (a service called npm). Humans don't need to search for anything, and the environment is ready in a few minutes.

When I was cloning Arduino samples, the same thing was actually happening. The messages that were scrolling across the screen back then were a record of the process of fetching libraries from the internet.

GitHub(自作コード+材料リスト)
  +
npmサーバー(ツール類の倉庫)
  ↓
受け取った人のPC(すべてが揃って動く)

There is just one thing to be careful about.

This mechanism assumes that a small configuration file called `.gitignore` is written correctly. Only by specifying in this file that 'tools should not be uploaded to GitHub' does this division of labor work.

Now that 'vibe coding,' where you have AI write code, has spread, there are increasing cases of people publishing without remembering to write this setting. Even if the tools are uploaded in their entirety, the program will run, but the repository becomes heavy and management becomes complicated. Before you think, 'It works, so I'll publish it,' this is one point you should make a habit of checking.


It is a simple story once you know it. However, for those who have only experienced the user side, there is rarely an opportunity to be taught this. The feeling of 'it's working, but I don't know what it's doing' is, as a starting point, actually quite natural.

Back in the days of that Arduino, even if I didn't understand the meaning of the messages scrolling across the screen, the feedback when the sensor moved was real. And that small question of 'why does it work?' is what connects to where I am now.



Summary: What is published to GitHub is only the 'code (recipe) you wrote.' The framework (ingredients) is automatically retrieved by the person who receives it. The bridge that connects them is the material list (package.json) and a single command. From user to creator. That first step starts with a surprisingly small question.



#GitHubIntroduction #ProgrammingBeginner #VibeCoding #Arduino #ITTalkForNonEngineers #OpenSource

いいなと思ったら応援しよう!

むみま|道具道 ここまで読んでいただけるとは✨チップはnote創作に使わせていただきます🤗