github guru - any idea where to find one?

27 views
Skip to first unread message

bruce

unread,
Jan 30, 2024, 11:04:34 PMJan 30
to lv...@googlegroups.com
Hi.

Might be off base, but does anyone know of a mentor/guru for Github/git/gh?

Starting work on a small project, and would like to be able to have
Github server as the source version control/repository.

The quick goal is to create a workflow/process for users handling code.

So, if you know of anyone I can talk to, let me know.

ps.
Once the basic workflow/recipes/examples are created, users would have
a better understanding of working with the platform.

thanks

Matt B.

unread,
Jan 31, 2024, 1:44:58 PMJan 31
to lv...@googlegroups.com
Hi Bruce. Are you wanting to start using Github (the website) as a repository for a code base or set up your own git-based service on your own server? 

You can also do some advanced build and testing automation on top but it sounds like you’re just looking at getting started with code repositories, right?

—Matt

--
You received this message because you are subscribed to the Google Groups "LVL1 - Louisville's Hackerspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lvl1+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lvl1/CAP16ngptX6rVcWeE1vDGKVYcXQWNG0sAHsT%3DuzJdNqjQRqLWSw%40mail.gmail.com.

Michael Melhorn

unread,
Jan 31, 2024, 1:55:16 PMJan 31
to lv...@googlegroups.com
Hey Bruce!

This is something I made a while back when I was in code Louisville.  Has some of the commands you would use on a normal bases.  As well as a qr code to a explaner that helped me out a lot when I was going through code Louisville.  

Hope it can help you out if you need anything between now and you find someone.

BigMike

bruce

unread,
Jan 31, 2024, 2:33:58 PMJan 31
to lv...@googlegroups.com
Hi Matt.

Thanks for the reply. This would be for a project using Github as the
repos. I've been looking at fiverr for a person or two to handle part
of the dev stuff, but realized that there really should be a
foundation/process for basic dev/test/release processes. Which means
if I choose Github, I more or less need to "know" it, as well as
define some of the basic things the potential devs should know.

If you're volunteering to be a quick mentor, let me know!

-bruce

ps, for me to get to where I think I want to be, this shouldn't take
too long. Part of having that "mentor/guru" is to not go down the
wrong path... So the process is faster..
> To view this discussion on the web visit https://groups.google.com/d/msgid/lvl1/CAHiMttsD1HJxb8qkKvMXzQ8CZPs_hy%3D8QzZaRKg4DDfF%3DJ%3DWhw%40mail.gmail.com.

Matt Schutz

unread,
Jan 31, 2024, 3:08:07 PMJan 31
to LVL1 - Louisville's Hackerspace
Hi Bruce.  Git is super easy at a high level, but the ins and outs can be overwhelming.  Simply committing code isn't awful, but when you start to create new branches, restore from a particular point, or do much more than commit code I'm easily lost.  I'd also love to have some kind of workshop on this if anyone is willing to help out!  I personally do all of my dev work through VSCode, so for me that would be my preferred lens into the Git world.

Specifically I'd love to learn more about
  1. Setting up Git locally - the install, why I need it, what role it plays in daily operations
  2. Creating a project locally - both 100% from scratch, and also adding Git to an existing VSCode project/directory
  3. Setting up on a remote server, namely GitHub
  4. Commits, pull requests, branches, and other concepts (this is where it starts to go over my head)
  5. Restoring a project to a specific point in time
Great idea Bruce, I'm in.

- Matt

bruce

unread,
Jan 31, 2024, 5:11:21 PMJan 31
to lv...@googlegroups.com, Matt Schutz
Hey Matt,

Saw your msg!!! ok. so it's not just me!

I take it you're local, do you have github acct?
Are you open to doing some "co" figuring out via phone!

Do you use linux/mac/windows?

I've got Github, as well as test digitalocean droplets for testing.

-bruce
> --
> You received this message because you are subscribed to the Google Groups "LVL1 - Louisville's Hackerspace" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to lvl1+uns...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/lvl1/5c6499c2-b60f-4f9d-957d-4ae5f26d3042n%40googlegroups.com.

bruce

unread,
Feb 1, 2024, 11:45:20 AMFeb 1
to lv...@googlegroups.com, mmelhor...@gmail.com
Hi Michael/BigMike

Thanks for your reply the other day...

Trying to wrap my head around the concept  of "git checkout -b new-branch"

Thought I'd see if you have an understanding or can point me to something that does..

I've been looking at lots of sites.. They seem to say the same things, and I'm missing it.

--need to understand git checkout -b new-branch
 does it create a new dir
 does it operate in the same dir
 what files does it operate on
 how do files get there
 does user manually place them?
 can you do multiple/simultaneous "checkout -b new-branch2"
 eg
    if user is in the "base" dir from the initial "git init"
     or "git clone foo repos1"
    and user does a "checkout -b new-branch"
    exactly what happens??
        on the remote/github repos
        on the local "repos1" dir
  what/how does the user then upload the modified files in the "new-branch"
 
do you have a "workflow" of how this works?

I've got the Github/Digital Ocean test droplets to test all of this. But missing something subtle.

thanks
-bruce



DaveCampbell

unread,
Feb 1, 2024, 4:44:54 PMFeb 1
to LVL1 - Louisville's Hackerspace
i found this 4 minute video covers almost all those questions:
https://www.youtube.com/watch?v=e9lnsKot_SQ&ab_channel=ByteByteGo

and the other videos in his channel also seems super informative, at a high level, and uses animation for visual learners.

Robbie Cooper

unread,
Feb 1, 2024, 6:09:22 PMFeb 1
to lv...@googlegroups.com
Hi Bruce,

I can answer this.

"git checkout -b new-branch" is my preferred way to create new branches on the fly. It does exactly two simple things.

1. It creates a new branch at the current commit named "new-branch". (This step is equivalent to "git branch new-branch".)
2. It switches the current branch to this new one. ("git checkout new-branch")

It doesn't change any of your files/dirs. It doesn't change what you've already staged. It doesn't care what dir you're in. As a local operation, it doesn't care about your remotes. It just creates a new branch for you, ready to use. The next commits you do will go onto this branch (unless you checkout something else).

You can verify it worked by running "git branch" with no args, which will list your branches.

That's the gist of it, but I'm going to go into more detail since your questions seem to be about branches in general.

All of git's metadata, including branch and commit data is stored in the ".git" dir at the root of your repository. When you manipulate branches in any way, that is where the changes physically occur. You can treat ".git" as a black box. You should never need to go in there.

Everything outside of that ".git" dir is your "worktree", which is just the term for all of your files. This is what you edit and eventually add and commit. No special metadata here at all.

I'm going to assume you know about commits. The important details for now are that each commit points to a parent commit, forming a chain: its history. The history can branch/diverge, meaning that multiple commits can share the same parent. It can also converge: merge commits can have multiple parents. To see this for youself, run "git log --graph --all". Though, it will look pretty simple if you have no branches or merges.

With all of that out of the way, I can now tell you that a branch is just a label/reference to a commit. The commit it points to is the tip or "HEAD" of that branch. When you create a commit on a branch, all you're doing is moving that label to the next one. That label on the tip of the branch is all git needs to know to infer its whole history and where it diverged.

Git has the concept of the "current branch", which is the one that your commands will affect. You only have one current branch. So, if you run multiple "git checkout -b new-branch2" as you asked, you will create mutiple branches at the same location, but only the last one will remain the current branch. (And if any of the branches already exist with the same name, the command will fail.) "git checkout" is the way to change the current branch (and update your worktree to match).

You asked about how to upload the files in the new branch? Just push the branch. The default remote name is "origin" (check with "git remote -v"). To push the new branch run "git push origin new-branch". This will create or update a "new-branch" branch on the remote, pushing up all of its history. That is, the commit pointed to by "new-branch" and all of its parents that aren't already present in the remote. A commit is also a snapshot of the files, so by pushing the commit, you also upload the files.

I hope this helps. Feel free to ask me more questions. Also, tonight I'm planning to be at the space for Open Coding Thursday.

Best,

Robbie
To unsubscribe from this group and stop receiving emails from it, send an email to lvl1+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "LVL1 - Louisville's Hackerspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lvl1+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "LVL1 - Louisville's Hackerspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lvl1+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lvl1/CAP16ngrtN6_UFbuRaiVJYtGgf8Cvi6U%3DizSHsRBg31f5jMfnSA%40mail.gmail.com.

bruce

unread,
Feb 1, 2024, 8:18:31 PMFeb 1
to lv...@googlegroups.com, Dave Campbell
Hi Dave.

Thanks! 

For some reason, it wasn't clicking. Found a few more sites, with slightly different explanations/examples. Most of the road blocks appear to be cleared.

The issue of "merging" from multiple users might be interesting. And then there will be the issue of automating some "workflows" to test/deploy to new cloud instances.

Having to recall things you knew decades ago...

thanks!


Reply all
Reply to author
Forward
0 new messages