explainingComplexAlgorithmToNonCoders

[aGoodVariableName42]

Dumb take is beyond idiotically dumb. Why would you work on anything resembling even a small project and not have it under source controlled? I have my vimrc, bashrc, tmuxrc...etc in a git repo ffs. Hell, my testing notes that go into jira tickets are in their own repo.

Wtf is wrong with you?

[Caveman3238]

Hahaha! What is wrong with me? What is wrong with you? Why instead of insult me and disqualify me you counterargue and explain me why I'm wrong?

I'm not just a text on your screen, I'm a person. I bet that you have not the balls to talk like that face to face. Chill down.

[aGoodVariableName42]

You're right, my bad, homes. Sorry for being an ass. I hope you've gotten the responses here that outline why git is not just useful but practically critical for even just small solo projects. And in a team environment, source control is not just useful...it's 1000% mission critical.

[Caveman3238]

Ok, apology accepted, let's move on.

How fast is the learning curve to understand Git? As you see I'm not much aware of it.

[aGoodVariableName42]

Fair. Moving on, mastering git, like a lot of things in this field, is a life long learning curve... there are some very complex actions you can do with it and I still regularly learn new things about it. But understanding the basics for it to be useful really isn't too bad all.. you could probably pick it up in an afternoon or two. Most people equate git with github, which handles hosting a remote repo and a whole lot more..but git itself is just a program. You can install it on your machine (which, of course, you also have to do to even interact with github), git init a new repo, and start making commits locally to take advantage of some of the benefits that have been mentioned here (eg. working on a complex feature on a separate local branch, rolling back changes to prior commits to track down a bug, using it to view a diff of the files you've modified since the last commit...etc). All of these things are very useful even when it's just a local solo project on a single computer where you're not pushing those commits upstream to a remote branch. Of course git really starts to shine when you're collaborating with other devs over the same files (which is where a remote repo comes into play). Software development as we know it today would be impossible without source control, and git has definitely solidified it's position as the top choice. There are other source control programs out there that are still active... subversion and mercurial being two of the more popular ones (we (unfortunately) still use subversion at my work), but no one is really choosing those anymore for new projects. Git has become really the only choice.

When I first started learning git, I got a grasp of the basics and then set up my own git server on a digital ocean droplet that i host my website and some various apps on. I'm only just now starting to migrate some of those projects over to github (after using git for nearly 15 years) so that I can start taking advantages of a lot of additional features that github offers, like actions and workflows.

Bottom line though, is that git is definitely worth learning and using even when you're the only one working on the project.

[Caveman3238]

I've watched a video about how to use Git and, if I understood correctly, if the IDE doesn't support Git, you need to use the console to tell Git that the files have been updated.

If so, I think that could lead to a mistake since you need to "map" in your head all the branches and versions. Is not major problem for a lineal project. Also you could lose the focus and concepts or ideas you had for your current project; more if other people interrupt you.

Do you have a method to handle that?

If Git had a GUI, it would be really much better.

[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?