Day 13 of #100DaysToOffload - I have a confession to make today.
I have no idea how to use Git!
@kev You're missing git gui. In that, you click "stage" to move changes from the top box to the bottom box, "commit" to commit the changes in the bottom box (with the commit message) and "push" to upload the changes for everyone else to see.
@kev I think I use five commands in total:
git clone (clone a rep to my filesystem)
git pull (pull in the latest changes)
git add . (add any changed files after i've worked on them)
git commit -m "commit message" (commit the changes)
(push them to the remote repo)
Building on this (which is a very good crash course), I've started managing my commits and messages much better. I used to do git add . as well but I would rarely know what actually changed.
git status - see what files have changed
git diff path/to/file - see what changed within that file
git add path/to/file - prepare to commit it
git commit -m "message" - short summary of what the changes were
git push - upload those changes to remote repo 😊
When you're adding individual files, it's best to group them by category. For example, take my latest commit for modifying my dotfiles
Ignore the actual content for now 😉 I created a new file at bin/startup and added a bunch of lines to it. Those lines allowed me to remove some others from my sway config.
git add bin/startup dotfiles/wayland/.config/sway/config
git commit -m "add startup script and reshuffle sway config to accomodate"
Then in the Gitea GUI, that commit shows that I changed to files and summarises what changed within them.
As for branch, tree, etc., etc., etc. . . . all I know is that branches are used to work on something that might break the "main" code in master.
@amolith @jamie @kev branches are just a way to separate two lines of commits from each other. So you have commit A, B, and C. Decide you want to try something out and make a branch where you create commit D and E. Then you switch back to the original branch where you make commit F. The main branch then holds A, B, C, and F. D and E are separated and won't be mixed with the others until you merge the branches.
@amolith @jamie @kev in real life D and E might be a large new feature you're working on that's not ready yet (you might need 10 more commits for that) and F is a bugfix for the released version of the code, so you can roll out bug fixes without waiting for the new feature to be done.
Also a pro tip: "git add -p" (for partial) lets you review each hunk of changes and add changes piecemeal to a commit.
I did have a vague idea of branches conceptually. Actually using them with branch, checkout, merge, etc. is where I get fuzzy.
I looked at the git-add man page and found that there's actually an interactive mode as well as a way to select which lines in a given file you want to add to the commit I may need to start using some of this 😉
It's a very progressive thing in my opinion. As @jamie said, you can get by perfectly fine with just those five commands. For the longest time, I actually scripted my commits 🙈
With that, just run "commit" in the root of the repo, type your message, hit enter, type GPG key password (remove -S if you don't use GPG), and done. It worked but . . . it was really bad practise lol. While you're learning, it's alright but you'll eventually fine yourself wanting more 😉
Try with Mercurial (hg) and TortoiseHg. Way simpler than Git.
I also don't understand and don't like Git...
@kev I have no idea how to make pull requests.
Hearing the phrase "pull requests welcome" immediately makes me think, "I believe that meritocracy is the best form of governance".
The concept is clone the original repo (GitHub calls this "fork"), make your desired changes in your cloned copy, preferably test it so it's not buggy, then make a "pull request" via GitHub which essentially asks the original repo to pull in the difference between your cloned repo and theirs and apply the changes.
You can only do this with commited changes, uncommitted work is not touched.
@kev 0.001% of git features covers 99.999% of use cases. You can "fully use" git with 5 subcomands: clone, diff, commit push and pull. Every time I need to do anything else I have to google it first.
@tomdeb yeah, I’ve since learned that (and added those commands to my wiki).
Clone, add, commit, push are the main ones for my use cases. I’ve also implemented web hooks on my server, which saves me FTPing changes up. It’s a good workflow.
Don’t know why I didn’t make the effort to learn sooner.
@kev git is way less complicated than it seems, and the GitHub model actually makes it worse sometimes. And much of it is only relevant at Linux kernel scale (i.e. 1% of all projects).
Git divorces the concept of "current content of the files" from "the set of changes you want to record as the next patch", which is why it operates in multiple stages (git add -> git commit). Let's say you're working on your website and you want to change the contents of the footer to include a license.
@kev so you add that to the footer template, but you realise you also want to change the css a bit to add more padding around paragraphs and a larger line height, so you do that too.
So now you have two logically separate patches, so you want to make two commits out of it so that someone else can add them both to their version of the file, or pick and choose which one they want to add. You do this by using the git add and git commit commands.
@kev git add accumulates a bunch of changes into a logically related whole; for a webpage you might change html, css, and JS files to make one logical change (content and style of a footer let's say). It's saying "when I save this patch, all of the following changes should go in the patch". Once you're satisfied you do "git commit" which turns the changes into an atomic patch that can be used to replay the changes in a different repository. E.g. so you can sync your local copy with the webhost.
@kev so git add/commit are the core operations. Accumulate changes, then record them as a logical unit of changes.
Everything else in git is there to facilitate moving and syncing these patches between repositories (push/pull), or to enable workflows of changes without stepping on toes (branching), or for releasing your changes to the world (tagging). Pushing and pulling are pretty important for collaboration, but you don't need branches or tags to use git at all.
@kev it's a tool built for kernel dev after all, so everything is built to enable dozens or even hundreds of devs to cooperate on the same files, easily sharing their work across the globe. So dev A can send their 10 commits to the ethernet driver to dev B, and they pull two more commits from dev C and merge it into a whole that they keep working on.
That's why you break it into commits instead of full file merges, to make it easier to sync and to follow the history of the file.
@kev Maybe you want to play a bit around :)
They teach you the basics in a fun little game and challenge you into using as little commands as possible :)
(Note: It's not real git running in background, so they might miss some commands, but all in all, it's a great resource)
I've found a very good source for learning Git, that even I with next to no experience coding can follow along quite nicely.
This may help you.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.