#git tutorials

[petrapixel]

here's a list of all the intermediate coding tutorials i've written so far!

git / github tutorial

npm (and node.js) tutorial (+ how to use the command line) (this one's a prerequisite for the following 2 tutorials)

webpack tutorial (a module builder for JavaScript and (S)CSS)

11ty (eleventy) tutorial (a super easy static site generator!)

if you have ideas/requests, feel free to contact me!

more beginner coding tutorials are coming VERY soon! meanwhile, check out my common questions and common mistakes pages!

[maranull]

first reaction to the photo mode:

(like it's great if you're the posing kinda picture taker but i am very much not so while i'm very glad they added it i do feel a bit like... it could had been more and had more "in-action options")

[starcell00]

(warning: this post is mostly about silly little video games, but it mentions traumatic methods of teaching and their results. also, minor early-game spoilers for Outer Wilds.)

Outer Wilds and the Dark Souls series approach the problem of what to do when new players fail at the game from opposite directions, and (at the risk of pissing off soulslike enjoyers) I think Outer Wilds does it right, and Dark Souls does it wrong.

When a player dies in Dark Souls, the screen briefly flashes with the iconic "YOU DIED" before fading to black and putting them back at their most recent campfire. At first glance, this doesn't seem like anything more than the game telling the player the obvious, but...

"YOU DIED". There's so much emotional content packed into those two words.

The player already knows they've died when they see their character take the final hit and crumple to the ground dramatically, before those words ever hit the screen. Iconic though it is, the phrase is unnecessary; but it's also worded in such a way that it aims itself squarely through the fourth wall at the player themself. When you see it for the fiftieth or hundredth time, it starts to read as a judgment from the game, and the deaths start to feel like personal failings.

Coupled with the notorious, punishing difficulty of the game itself, Dark Souls' method of developing skill in the player boils down to "repeatedly demanding competency, until the player develops the ability to give it." If they develop that ability quickly, or by being persistent enough, they're rewarded with a slow trickle of lore and worldbuilding as rich and deep as amber - which is something that Dark Souls shares with Outer Wilds.

But if they fail to develop this ability in a timely manner, or even at all, a particular boss or area can quickly become a brick wall for the player to hit their head against. In this way, the game's teaching style is roughly analogous to a strict piano player rapping their student across the knuckles and saying "Again" every time they hit a wrong note; this harshness and lack of sympathy from the game is even a meme in the Dark Souls community, with many a comments section littered with "git gud."

(tw: this is where it gets heavy)

Although Western society has largely moved on from corporal punishment, this "just get good" style of teaching is still regularly practiced in almost all areas of real life, and - speaking from personal experience - the consequences for students are usually severe: from loss of passion for the material, to lifelong insecurities and anxiety disorders, to crippling depressive tendencies, up to and including suicide. The entirety of Whiplash (2014) comes to mind, but particularly the bit where the harsh band director gets physically attacked by his star drum student.

(ok ur good)

By contrast, Outer Wilds takes great care to frame the player's death as a natural inevitability. You can glean every bit of information from every NPC in your starting village and go take off in your wooden shack of a spaceship, you can land (very gingerly) on your home planet's moon and talk to the NPC hanging out there, you can take off again, land again at the places on the moon they suggested you go to, and translate some alien text, you can go to some more places, and rinse and repeat for twenty minutes...

...and then, you can look skyward and watch the fucking sun explode, turning you and every other bit of matter in the solar system into a glittering cloud of plasma.

The game unequivocally tells you, within the first half-hour of gameplay: "you will die, and that's okay." In fact, it proactively makes you die, at no fault of your own - without even saying any words about it, to boot. (Interestingly, this can sometimes be a major turn-off for soulslike enjoyers.)

You then wake up back where you started, and your ship's computer still has logs of the people you talked to and the text you translated in the previous life, ready for you to take off again and add to them. Outer Wilds defines success such that you only fail if you manage not to learn anything in a life - an exceptionally difficult thing to do, given how plentiful knowledge is in the worlds you visit.

In fairness, though, Outer Wilds does have areas locked behind requirements of lateral thinking, unusual cunning, or raw mechanical skill, and you will not be progressing into those areas until you meet those requirements. The game temporarily switches to the Dark Souls model of teaching: demanding competency until you develop it. Given some of the places it shows up, the switch usually makes sense, and the areas in question are still largely optional (let's not talk about the DLC), but it says something about that model of teaching that those moments are widely considered to be the worst parts of the game.

tl;dr Dark Souls demands perseverance and punishes failure, where Outer Wilds encourages perseverance and makes true failure quite difficult. Some people want Harder Battles, but some people can't handle them.

[smurfton]

As a sequel to this, if you want to learn more about how git works, there's tutorials in its documentation that go further in depth.

Some things that aren't in the interactive link above which I've found handy below the cut

What if you want to learn about every commit that is part of newBranch but not part of commit c1? (If there's no merges this just means every commit between c1 and newBranch). You can use:

log c1..newBranch

to only see that. (You can actually use this <commit-ish>..<commit-ish> notation anywhere that would accept a list of commits, like cherry-pick)

What if you have two branches, nextRelease and pastReleaseFixes, and the tree is too complicated and big to follow how they connect, but you know something going into nextRelease fixed something that's broken in pastReleaseFixes, and that it's related to the file my/important/file.cpp?

git log pastReleaseFixes..nextRelease -- my/important/file.cpp

Will show you only commits that are in nextRelease (but not pastReleaseFixes), and filter that to only commits that touched the file you care about. (You can actually choose a function or series of lines in the file, too). See

A different bug fixing option is git bisect. You tell it about a time when things were bad and a time when things were good, and it picks a place in the middle for you to check. Even with 1000 commits to go through, it'll find the problem in only ten tries!

Fancier than I am includes stuff like how git is properly decentralized. You can have more than one remote, such as the computer of each person you're working with, if you don't like showing your work to a company. That's why git wants you to say origin — you could say something else and it would go to a different place

Me upon discovering an online game that helps you learn git: haha I've been using git for years now, I could skip ahead many levels, methinks hahaha no, no, I'll be humble and start on level 1

Me on level 5: You can do what??? There are commands for what???

[vivektech]

Use Git if: ✅ You need speed and distributed development ✅ You want better branching and merging ✅ You work offline frequently

[harikumarstudio]

#00248

If you've ever come across a GitHub project site and wondered what it was all about (or just how to download the project), then this course by Stephen Ulibarri is a great short course.

My plan is to use both GitHub and Perforce as follows:

GitHub: for building Unreal Engine from source and testing out C++ code

Perforce (Helix Core): for Unreal Engine projects and its assets (eg. Houdini files)

[thecommoncoder]

Git Tutorial: Learn How To Use Git in 23 Minutes!

Do you want to learn how to use Git? In this tutorial, we'll cover the essential Git commands that you need to know, so that you can start using version control inside of your projects. Enjoy! 🎉 #git #gittutorial #howtousegit #thecommoncoder

[moose-mousse]

Ok. I am going to let you in on a secret about how to make programming projects.

You know how people write really good code? Easy to read, easy to work with, easy to understand and very efficient?

By refactoring.

The idea that you write glorious nice code straight is an insane myth that comes from thinking tutorials is how people actually code.

That is because programming is just writing. Nothing more. Same as all other writing.

The hobbit is ~95000 words.

Do you think Tolkien created the Hobbit by writing 95 thousand words?

Of course not! He wrote many many times that. Storylines that ended up scrapped or integrated in other ways, sections that got rewritten, dialog written again and again as the rest of the story happened. Background details filled in after the story had settled down

Writing. Is. Rewriting.

Coding. Is. Refactoring.

Step 1 in programming is proof of concept. Start with the most dangerous part of your project ( danger = how little experience you have with it * how critical it is for your project to work )

Get it to do... anything.

Make proof of concept code for all the most dangerous parts of the project. Ideally there is only 1 of these. If there is more than 3 then your project is too big. ( yes, this means your projects needs to be TINY )

Then write and refactor code to get a minimum viable pruduct. It should do JUUUUUST the most important critical things.

Now you have a proper codebase. Now everytime you need to expand or fix things, also refactor the code you touch in order to do this. Make it a little bit nicer and better. Write unit tests for it. The works.

After a while, the code that works perfectly and never needs to be touched is hard to read. Which does not matter because you will never read it

And the code that you need to change often is the nicest code in the codebase.

TRYING TO GUESS AHEAD OF TIME WHAT PARTS OF THE CODE WILL BE CHANGED OFTEN IS A FOOLS ERRAND.

( also, use git. Dear god use git and commit no more than 10 lines at once and write telling descriptions for each. GIT shows WHAT you did. YOU write WHY you did it )

Is this how to make your hobby project?

Yes. And also how all good software everywhere is made.

[max1461]

Can someone explain to me in like five seconds how to use git, assuming that I know basic shit about coding/command line/whatever but don't know any of the specific terminology related to git. Like every tutorial online is at the same time both over my head and also vastly too basic. Just like. Tell me what it is.

Uh. First tell me its ontology. Is it a program, a standard, a language...? I know that it's for version control. Suppose I wanted to do version control at a piece of code. What do I do. What buttons do I press, on my computer? Tell me these things.

[markrosewater]

hi a friend walked me through a commander game and I liked it and so I got a couple premade decks. I then went to a couple commander nights and I kinda liked it except for the part where I felt like I was a little kid with floaties in the middle of the ocean trying to sing a little song to myself so I wouldn't think about the things that might be lurking just below the surface that I can't see. Magic is vast and deep and I don't know how I can enjoy playing when there's just too much. I get that the hugeness is part of its staying power, but it feels too big and too much to even approach beyond playing my premade deck and hoping the people at the table won't look down on me for it (which they often do). Even looking up tutorials and guides is overwhelming because each one of them is sharing a *different* tiny slice of material! I haven't felt this baby-beginner starting something new in a very long time (and I say that as someone that is otherwise well-versed in being a terrible beginner at new things). Is there a way to play magic without getting absolutely lost in the depths? or is that the nature of the beast and I just gotta "git gud"?

The two formats I would suggest are draft or Cube. Both use a much smaller card pool, one you can more easily learn about.

[ibarrau]

[PowerBi] Integración con AzureDevOps Git Repos

El lanzamiento de Power Bi Developer Mode durante el evento Microsoft Build está causando gran revuelo no solo por su posibilidad resguardar un proyecto de PowerBi sino también porque por primera vez tendríamos la posibilidad de que dos o más usuarios trabajen en un mismo proyecto. Esto no es trabajo concurrente instantáneo como Word Online sino más bien cada quien modificando los mismos archivos de un repositorio y logrando integrarlos al final del día.

La deuda de versionado y trabajo en equipo finalmente estaría cumplida. Según uno de los personajes más importantes del equipo, Rui Romano, aún hay mucho por hacer. Veamos que nos depara esta característica por el momento. 

Vamos a iniciar asumiendo que el lector tiene un conocimiento básico de repositorios. Entienden que en un repositorio se almacenan versiones de archivos. Se pueden crear ramas/branches por persona que permita modificar archivos y luego se puedan integrar/merge para dejar una versión completa y definitiva.

Todo esto es posible gracias a la nueva característica de Power Bi Desktop que nos permite guardar como proyecto. Esto dividirá nuestro pbix en dos carpetas y un archivo:

Carpeta de <nombre del archivo>.Dataset: Una colección de archivos y carpetas que representan un conjunto de datos de Power BI. Contiene algunos de los archivos más importantes en los que es probable que trabajes, como model.bim.

Carpeta de <nombre del archivo>.Report: Una colección de archivos y carpetas que representan un informe de Power BI. El archivo más importante es "report.json", aunque durante la vista previa no se admiten modificaciones externas en este archivo.

Archivo <nombre del archivo>.pbip: El archivo PBIP contiene un enlace a una carpeta de informe. Al abrir un archivo PBIP, se abre el informe en  Power Bi Desktop y el modelo correspondiente.

Entorno

Lo primero es configurar y determinar nuestro entorno para poder vincular las herramientas. Necesitamos una cuenta en Azure DevOps y un workspace con capacidad en Power Bi Service. Para que la integración sea permitida necesitamos asegurarnos que nuestra capacidad y la de la Organización de Azure DevOps estén en la misma región. 

La región de una organización de Azure DevOps puede ser elegida al crearla, al igual que podemos elegir la región de una capacidad cuando creamos una premium, embedded o fabric.

En caso de utilizar capacidad PowerBi Premium Per User o Fabric Trial, no podríamos elegir la región. Sin embargo, podríamos revisar la región de nuestro PowerBi para elegir la misma en Azure DevOps

En ese caso creamos la organización de DevOps igual que nuestro PowerBi porque haremos el ejemplo con un workspace PPU.

Seteo

Dentro de Power Bi Service y el Área de trabajo con capacidad que queremos versionar iremos a la configuración. Con la misma cuenta de ambos entornos completaremos los valores de organización, proyecto, repositorio, rama y carpeta (opcional).

Como nuestro repositorio esta vacío, lo primero que sucederá cuando conectemos será una sincronización de todos los items del área de trabajo en el repositorio. Ahora bien, si teníamos reportes en el repositorio y en el area,  tendremos un paso más para coordinar la operación deseada si pisar o integrar.

Una vez que todo tenga tilde verde y esté sincronizado, podremos ver como queda el repositorio.

En caso que ya tuvieramos informes cuando inicio el proceso, se crearán carpetas pero no el archivo .pbip que nos permitiría abrirlo con Power Bi Desktop.

Si crearamos el informe con Power Bi Desktop y eligieramos “Guardar como proyecto” si se crearía. Entonces podríamos hacer un commit al repositorio y automáticamente se publicaría en nuestra área de trabajo.

El archivo pbip es un archivo de texto. Podemos abrirlo con un bloc de notas para conocer como se constituye para generarlo en caso que necesitemos abrir con Desktop uno de los informes que sincronizamos antes. Ejemplo del archivo:

Al tener sincronizado el repositorio con el workspace podemos usar un entorno local. Si está en el repositorio en la rama principal, entonces estará publicado en el área de trabajo. Veamos como sería el proceso.

Esta sincronización también nos favorece en el proceso de Integración y Deploy continuo puesto que varios desarrolladores podrían tener una rama modificada y al integrarlo con la principal delimitada en el área de trabajo tendríamos automáticamente todo deployado.

Si algo no se encuentra en su última versión o hacemos modificaciones en línea, podemos acceder al menú de source control que nos ayudaría a mantener ordenadas las versiones.

Alternativa Pro

Con las nuevas actualizaciones de Fabric en agosto 2023, podremos por primera vez, trabajar en equipo en PowerBi sin licencia por capacidad o premium. Guardar como proyecto es una característica de PowerBi Desktop. Por lo tanto, podemos usarla contra un repositorio Git en cualquier tecnología. Al termino del desarrollo, una persona encargada debería abrir el PBIP y publicarlo al área pertinente. Ahora podemos publicar desde Desktop los informes guardados como proyectos. Esto nos permite que los casos de puras licencias pro puedan aprovechar las características de histórico y control de versiones. Quedará pendiente la automatización para deploy e integración que aún no podría resolverse solo con PRO.

Conclusión

Esta nueva característica nos trae una práctica indispensable para el desarrollo. Algo que era necesario hace tiempo. Sería muy prudente usarlo aún en proyectos que no modifiquen un informe al mismo tiempo puesto que ganamos una gran capacidad en lo que refiere a control de versiones.

Si no tenemos capacidad dedicada, deberíamos trabajar como vimos en post anteriores sobre metodología de integración continua de repositorio https://blog.ladataweb.com.ar/post/717491367944781824/simplepbicd-auto-deploy-informes-de-powerbi

Esperemos que pronto tengamos una opción para importar por API estos proyectos al PowerBi Service para poder idear nuestros propios procesos sin usar las integraciones por defecto sino una personalizada a nuestro gusto.

[skarlettskwrl]

GIT Font and PNG Generator

This post by @pichikui was the spark of inspiration for this whole project.

I'm super excited to share this project (though it's in beta stage) The first part is a font family based off of the glitch in time ghost speak codex.

The second part is PNG Image Generator that can copy the GIT font to the system clipboard as PNG, download it as PNG, and copy an HTML template to paste into AO3. If you are unsure how to embed images into AO3, please consult this tutorial on the topic.

As I previously stated, this project is still in beta, so if you guys find any bugs or issues, feel free to reach out. I'm also open to collab as well.

[a-fox-studies]

And just like that, a year has gone by.

Hello, I'm Iris, a disabled undergrad student navigating through life. This year has been CRAZY.

If I think about it, 2024 has been a year full of treatments that haven't worked, my disability getting worse, so much pain, so much failure. I completed my first year of undergrad, and figured out routines for myself, and decided how I want my day to be structured. And I think those can count as wins too.

But I think the biggest win of all was that I made it. I made it through this hell of a year.

Looking back, a lot of people have helped me, knowingly or unknowingly.

Thankyou @studaxy for never leaving my side.

Thankyou @sadiests, @winryrockbellwannabe, @inkblotfeathers for being the positive force and motivation I needed.

Thankyou @guz013 for being patient with me lol, I know that I can be a handful sometimes.

Thankyou @montecarloedexistence for just every conversation we've had lol, you're amazing.

Thankyou @sapphicacademic for starting the AMAZING studyblr server, we even had its 1 year anniversary in november! You have changed my life, even though it may not seem like it.

Thankyou @moose-mousse for keeping the codeblr server alive and also helping me whenever I needed help and explaining concepts to me patiently. Your git tutorial is amazing!

Thankyou to all my followers, moots, others who I might forgotten to mention, and anyone who decided to like or reblog or even read through my posts. It means a lot to me <3

I don't have many high expectations of 2025. Maybe I'd complete writing my first book. Maybe I'd lose some weight. Maybe I would get cured. Maybe not. Either way, I'm excited for what the future holds for me. I am excited to meet new people, share new ideas, have deep conversations about life and goofy talks about nothing in particular. I'm excited to give all the love in my heart to the people around me, to gain opportunities to help and make other people's lives better. I'm excited to continue this journey of life, even though it sucks sometimes.

Here's to 2k25!🥂

[emacs-unofficial]

As a neovim user, I don't honestly know much about emacs. How is it differnt fundamental from vim and such?

I probably don't know enough about vim/neovim to give a meaningful awnser. (I know as much as vimtutor teached me, and apparently there are a lot of functions that are completely unmeantioned there)

If we talk about fundamentals, the biggest differences is probably, that emacs is (out of the box) not a modal editor, meaning instead of switching between an edit and insert-mode, you are always in insert mode and navigate/edit via key combinations (kinda like modern gui text editors). Another fundamental difference is, that the cursor sits between the characters in contrast to vim, where it sits on a character.

Also, while emacs can run in a terminal, it is also a GUI programm with image support and such.

Oh, and "yank" means in emacs term the opposite to what it means in vim. (Ah, good old software so ancient, that it precedes modern terminology like "cut" and "paste")

Thats mostly it for text editing. But emacs can do a lot more cool things: Org-mode is fantastic for taking notes (and can get even better with certain packages) (and IMHO a better markup language than markdown). Magit is for some people the best git client in existence. Editing and file navigation on remote systems works as well as local editing. And much more.

I can highly recommend simply installing emacs and trying out the tutorial. It tells you basically everything thats in the base packet and gives you links to where to get more in depth infos for configuration and external packages. To run the tutorial, start Emacs and type C-h t, that is, Ctrl-h followed by t.

You could even continue to use vim keybinds thanks to the @emacs-evil-mode package.

I've had a similar discussion in the past worth reading: