How to step into the world of git ?

There is always a relevant xkcd!

It is wrong. Git does not need a central system (although most people define one as the central). The local system has a repository, too.

Commits go into the local repository, not outside.

Push goes from the local repository (not from a commit that’s hanging in the air) to a remote repository (most times to the “central” one).

There are pretty good tutorials on youtube. Just be sure to learn git itself first, and then all the website things like github etc.

Git gud

Basic workflow that got me through the learning pains.

If I just sat down:

• git checkout develop or whatever ur main branch is

• git pull origin

If I’m working on a new branch:

(If not already on the new branch)

• git branch -b feature/123-ticket-name

(After making some changes)

• git add .
• git commit
• git push

Git will prompt you the first time you git push, just follow the instructions.

And of course there’s tons more you could learn or dive into. But that should give you a stable foundation to start working from

I’ve tried learning git a few times and new a bit about it but this article helped me understanding it quite a bit better:

https://www.chrismccole.com/blog/git-for-artists

The practical bits are about Github which you obviously don’t want to use but you can still get the gist of it when using Codeberg or something similar.

There are many many many many many git tutorials online. You literally need to stick the question into a search engine or watch a YouTube video.

Depends on the goal. Exploration for exploration sake is probably not going to hold your attention long. git is a tool to track changes. Do you have something you want to change? In other words, you need a reason to use it. Pedantically, your image already has a problem. git is not centralized. It is merely convention that some given local repo is blessed as “upstream”. But the whole point is that git is distributed.

Advice: Find a reason to use git. Put your /etc/ under git control, for example. Or something in your home directory (lots of people roll some kind of dotfiles repo). Or contribute to a FOSS project that uses git.

https://learngitbranching.js.org/

Make this your background. Use a gui like gitg if you’re learning, but repeat the terms on what each action is doing so you can transition to the konsole

Go in a empty directory and type git init .

Then have at it.

I like to explain it as “advanced undo-redo.” Most people who use computers have an intuitive understanding of undo-redo. You can ctrl-z all the way back to when the document was empty, and ctrl-y all the way forward to where you were. The difference with git is that you have to manually create those checkpoints with a commit.

But what if you ctrl-z a few times, and then type something? Most people know that all the changes they just ctrl-z’ed are gone. This is git’s first advanced feature: branching. Git allows you to maintain alternate ‘timelines’ for your file(s), which you can hop between at will. This is also what makes it a powerful collaboration tool: everyone on the team can maintain their own personal branches.

That last capability becomes extremely powerful with the next advanced feature: merging. Git has a number of very nice tools to assist in merging timelines back together, identifying conflicts when needed. This allows teams to set up one “true” branch that is the main (we used to use a different word) timeline. That way, each developer isn’t undoing and redoing on the same set of files, they can make their changes in isolation, and when a change is ready, it can be merged back into the main timeline. The proposed changes can be easily seen using git’s diff tool, and can be reviewed by the team, further refined, and finally merged with the main timeline. After this operation, the two histories have been joined and everyone else can pull in and start using that change.

I find that’s enough to get a new user conceptually oriented. That is, they have a good idea of what they need to do, if not the exact git commands to do it. But that’s the easy part, just a quick glance at the man page is all that’s needed.

That picture you included is kinda weird and misleading IMO.

First thing: Ignore the “central repository”. There is none. git works entirely locally (this confuses the hell out of people who grew up with CVS/SVN, for some reason). You CAN push and pull to other people’s computers, if you want, or your own other computer; all Github or whatever is is a “someone else’s computer” in the cloud that you can push to. But you also don’t need a remote repository at all. Most of ours don’t have one.

Seconding https://learngitbranching.js.org/. It’s quite nice.

Some stuff you should know:

• A commit is a snapshot of everything in the project (that was added to git at the time).
• A branch is basically just a movable tag pointing to the latest commit, with which you can get to previous commits by walking the chain backwards; when you make a new commit, you move the branch to point to it.
• You can make alternate timelines by going back to a previous commit (without moving your branch pointer), making a new branch pointer (and switching to it), and editing/committing/etc. That’s why they’re called branches.
• There’s an undo history for where your branch has been, git reflog. Can save your butt if a rebase or whatever goes sideways and you get screwed up.
• All your history is in the .git folder in your project folder. Everything. If you back that up you’ve got the whole history of the project.

– Frost

• Save a file
• Commit it
• Change that same file
• Commit it

You don’t absolutely need a central repository for Git. It’s decentralized. You can learn the basics (committing, branching, rebasing, amending, merging, resolving merge conflicts) entirely on your computer.

My advice would be to get familiar with using Git locally first. Simulate things like merge conflicts - have two branches that both change the same line in a text file, then merge them together and resolve the conflict.

Once you’re more comfortable with using it locally, learn about code forges like Github or Forgejo.

I always recommend Oh My Git.

The “pull” can get confusing to new users of git because they soon see people talking about “pull requests”. They should rename a pull request to a “sync request” or an “update review request” , etc.

There is Pro Git book also.
ChatGTP told me to read it after I wiped 4 hours of work by listening to llms :D