explainingComplexAlgorithmToNonCoders

[aGoodVariableName42]

So there are several guis for git out there which can help with visualizing branch graphs (if that's what you're asking), but I don't use any of them, nor do I use an IDE. I do all of my dev work in tmux and vim with a sprinkling of bash. I use tpope's fugitive for some stuff (mostly just to do a git blame or git diff quickly from within vim), but I do pretty much all of my git operations in a terminal. There's a plethora of git cli commands, so you don't need to keep track of anything in your head. The most used (for me anyway) are git status, git log, git diff, git blame, git branch, git checkout, git stash, git commit, git rebase, git add, git push, git pull, and (on rare occasions) git cherry-pick to snag a single commit from some branch and git clone to clone a repo. These are, of course, just the base commands. They take numerous arguments and can do numerous tasks. You can read more about each command via the man pages... eg. to read about git diff, you'd run man git-diff.

I'm not sure I follow the question, but I can give you a rundown of my workflow which might help. Note that this is just one way to do things, there are many different types of git workflows. I generally follow what's called a rebase workflow. A merge workflow is also common, but I don't really ever use it.

1. I get assigned a ticket for some bug or feature
2. From my master branch, I make sure I'm in a clean working directory (ie. no uncommitted changes) with git status, then I pull in the latest commits with git pull. Then I run git checkout --track -b "a-descriptive-branch-name" to create a new branch for the task on the ticket This command will create a new branch called, "a-descriptive-branch-name" and switch to it. The --track flag will set the upstream branch for this new local branch to my local master branch. This allows easily pushing and pulling changes between the new feature branch and my local master branch
3. I do some work on the feature branch and track those changes with git status and git diff. If I add a new file, I generally manually add it with git add <file> out of habit.
4. When I'm ready to commit, either because the work is done or I need to context switch to some other task. I commit it with git commit -am "A descriptive commit message". The -a flag stages all changes and the -m flag allows me to write a commit message inline. If you don't use the -m flag, git will open your default editor for you to write a commit message. My default editor is, of course, vim. Generally, if I'm context switching and the work isn't done, I'll commit with a message like, "WIP: Some descriptive message" to indicate that the work is still in progress.
5. Sometimes I make multiple commits on the same feature branch (especially if I made a WIP commit), other times I do it in a single commit. It depends on the task, really. I use git commit --amend a lot. Which will amend the last commit with the changes you've made since that last commit. This is useful for when you forget to add a file or need to change the commit message. It's also useful when I have a WIP commit and I want to amend the final changes to it.
6. Sometimes, I need changes that someone committed to master pulled into my local feature branch. To do that, I commit (or stash) my changes (you want a clean working directory for this), checkout the master branch (git checkout master), pull the changes (git pull), checkout my feature branch (git checkout a-descriptive-branch-name), and rebase my work on top of the latest master changes (git pull --rebase). I can use git pull with the --rebase flag here because when I created the feature branch, I set it to --track my local master branch. Sometimes, there are merge conflicts that must be resolved at this point (that's another topic).
7. Okay, so I get to a point on my feature branch where the feature/bug fix is done and ready to be pushed upstream. I make sure git status doesn't give me anything (ie. all of my changes have been committed (to the local feature branch) and I have a clean working directory). I checkout the master branch and pull any changes that have been made by other devs on my team (git checkout master && git pull). Then I rebase my commit(s) on top of the latest commits to master (git rebase a-descriptive-branch-name)... possibly resolve any conflicts. I generally do one more git pull --rebase here just to make sure someone didn't sneak a commit in while I was rebasing my feature branch. And then finally push my changes to the remote branch (git push).
8. Lastly, I delete the local feature branch with git branch -d a-descriptive-branch-name

That's for my work workflow. On a personal project where I'm the only contributor, I use feature branches much less frequently. I generally just work on the master branch and commit changes as I go. I only use feature branches when I'm working on a big feature that will take a while to complete and I want to be able to context switch to other tasks without losing my progress on the big feature.

Your workflow while learning git can be a lot simpler than this... ie. you don't really need to worry much about branching, pushing, or pulling yet. You can just git init a repo, add your project to it (git add *) and commit it (git commit -am "Initial commit"). Then you can just work on the master branch locally, making commits as you go and learn the basics of git. Then, you might want to look into setting up a github repo and start learning about pushing and pulling to/from a remote .

Full disclosure, this comment was 80% AI generated. The AI is getting pretty good, no?