Skip to content

Latest commit

 

History

History
47 lines (24 loc) · 3.42 KB

File metadata and controls

47 lines (24 loc) · 3.42 KB

Community Board

Add your takeaway below! This is the "challenge path" from the GitHub 101 article - editing a shared file means you might encounter a merge conflict. That's the point.


ivanlac's Takeaway

I wasn't aware of the difference between stashing and committing. Learning those two different functions and when to use them is quite helpful.

Stashing lets you temporarily save changes without creating a commit — useful when you need to switch branches quickly but aren't ready to commit yet.

Committing is a permanent snapshot of your work with a message explaining what changed.

Understanding when to use each one makes the Git workflow much clearer!

@prithviguruprasad

One thing I learned from GitHub 101 is that it's structured similarly to Google Drive, which made it much easier and less daunting to understand.

I plan to use it to build an automated agent that might help with repetitive weekly status updates.

This was super helpful! Instead of using the Claude desktop app, shifting to VSCode with Claude in terminal and using the PR functionality will help the team! — @KevinRelay

thefamilymanhq: learned process that engr typically take for github. takeaways - use branches for better organization and collaboration

adamzeeee: GitHub is very cool and not scary at all!

jvanboheemen — Geleerd dat forken en clonen praktisch hetzelfde doen, context is het verschil. GitHub is minder dev-only dan ik dacht — ook goed bruikbaar voor PMs. Plan: meer GitHub gebruiken als PM en AI integreren in projectworkflows.

TeammateBob — This guide was a great intro to GitHub. Branching finally makes sense to me!

MMoscosoCruz — GitHub finally clicked for me after reading this guide. Learning the vocabulary, understanding branches and pull requests, and setting it all up with Claude Code made the whole thing feel approachable. Highly recommend this article to anyone starting out.

  • I learned about the git workflow and came up with an acronym for it 'Pizza Before Every Commit Prevent Poor Moods' — @Della05

SA — GitHub finally made sense to me after understanding that branches are like draft copies and PRs are how you propose changes back to the original.Excited to use this for managing docs and workflows!

jjaaeeone - I learned the workflow: pull, branch, edit, commit, push, PR, merge

@JNY8630 — GitHub is analogous to SharePoint or Teams: we're all working with shared cloud-based files. The key difference is the workflow. In a regular office, everyone edits the same cloud file simultaneously, relying on version history to roll things back. In GitHub, you pull the file down locally, make your changes in isolation, push them back up, and then GitHub handles merging — something we do manually (or badly) in normal office work.

What struck me is the discipline this creates: there's a clear main file, individuals go off and propose changes, request specific reviewers, and only merge once it's approved. That structured loop doesn't really exist in corporate tools today. I wonder if, as AI-native workflows become more common, more office workers will start adopting this GitHub-style pattern — because the conceptual leap isn't that big, and the benefit in clarity and structure is real.

  • chandrikasriv: I had never heard about the concept of "stashing" before, and I didn't realize one can easily switch to someone else's branch. That's very cool.