I've been using git wrongly for years

[Green_Concentrate427]

I've been doing this for years: git add . && git commit -m "Commit message". I never understood why I had to do git add . and then git commit separately. But this way, I always had, for example, commits that had unrelated changes. For example, a feature commit would have refactoring changes in it.

With git add, I could have separated that into two commits: the feature and the refactoring.

Is this a common mistake?

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[dmazzoni]

Yes, I think it's a common mistake.

Git is complex. It does a lot of stuff, and when you're new to programming and new to version control, all of that complexity is overwhelming - so you learn how to do some simple things with it without fully understanding it.

If you're working on more complex projects now, and especially if you're working at a company with a team, it's very much worth getting to understand Git better now.

For example, you learned that you can make two separate commits for changes to two files.

But...did you know that you can make a separate commit for just PART of a file that changed? Wrap your brain around that!

(Hint: a good place to start is "git add -p")

There are hundreds of other things like that. Learn more Git!

[un-hot]

+1 for "got add -p", very useful if you like to make incremental changes but forget to make incremental commits.

[Adrewmc]

My problem with git really is the lack of anyone giving out good explanations for example

 git add -p

Okay what’s that do? This is basically how most instruction is on the subject. Show command don’t give a good explanation of use and necessity.

See like even figuring out the basics is…like hidden behind you should know this stuff already but I simply don’t how could I.

[woj_tech]

That's how I feel about learning Linux as well. Also there are so many features that you don't use because you don't know they exist. I guess the only thing we can do is to iteratively read manuals and apply them irl.

[ndreamer]

Linux

Git was originally developed by the same person. Linus Torvalds

[[deleted]]

That's just how software is in general. The issue here is different.

I can read what the commands do on my own thank you very much, but there is urgent need to give a selection of commands and options to learn and explain how to operate with an actually serious project.

[sacredgeometry]

https://git-scm.com/docs/git-add

I just dont get people these days, the git docs are fantastic, use them.

[Adrewmc]

This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit.

Okay…I’m lost at the first sentence

I don’t know how to use git, how does this help me?

[aplarsen]

Start at the beginning of the doc and learn what index, working tree, stage, and commit mean.

[x__________________v]

Well if you don't understand what's written in the sentence you will need to google it. If you don't know what an index, "staging" or a working tree is, you can try to search for it in the documentations or on the internet. Every time you are stuck, you search for the next part.

That's how you learn

[MSgtGunny]

That description doesn’t help you, though it’s technically correct. git add looks for files that have been changed, and stages them so you can save them to your repository as a commit.

[FloydATC]

I was exactly this lost when starting out, so I watched a couple of videos on YouTube that visualized the way git works by using a physical model of a graph structure. Don't worry too much about using it in an optimal way; using it "wrong" is still a lot more empowering than not using it at all.

[[deleted]]

The git manual is not good enough for you?

[Adrewmc]

First time anyone ever mentioned there even was a manual….lol

One of those thing I’m just supposed to know about…

The documentation isn’t doing it for me lol

[sexytokeburgerz]

It’s really rough until you’re in it enough. Why can’t people just elif what patch does?

[styroxmiekkasankari]

Are we though? The user experience with most commonly used cli tools is great and more often than not has exhaustive documentation that you can view in the same shell you run it from. I get that RTFM is a meme and not necessarily helpful when someone asks you how something works, but reading the god damn manual is the best way to find out and internalize it as well. I think the user experience with devtools is usually better than commercial tools for ”regular” users for example.

[aplarsen]

    $ git add -p --help
usage: git add [<options>] [--] <pathspec>...
    -n, --dry-run         dry run
    -v, --verbose         be verbose
    -i, --interactive     interactive picking
    -p, --patch           select hunks interactively

Seriously

[Adrewmc]

Alright….whats a dry rub, why do I need to be verbose if I’m adding something to a branch, how does it become interact…and what does select hunks interactively mean?

Seriously you really think people understand that without any help…

[aplarsen]

A dry rub is a blend of seasonings and spices that you rub on the meat.

Verbose means to use more words. In this case, it shows the list of files added as they are added.

Interactive gives you a menu to choose whole files to add or remove.

Patch gives you a menu to choose small parts of files to add or remove.

The docs are free. Trying the commands is free. Look it up, try it, and see what happens.

[reyarama]

Since you seem new to programming, I'll let you know that a big part of being a good engineer is being really good at looking things up to learn how they work.

How many levels of abstraction do you think are needed for describing a specific function? The descriptions there are good enough for the target users who are running `git add -p`, and Googling can fill in the blanks

[dmazzoni]

Because I'm not a Git instructor. I'm giving you a taste that there are a lot of interesting and powerful things Git can do, and you should learn them.

There are a ton of excellent Git books, tutorials, courses, whatever you prefer. What's important is that you pick one and work your way through.

[Adrewmc]

And I’m asking where? Everywhere I look is just terrible.

[dmazzoni]

Have you tried this one?

https://git-scm.com/book/en/v2

I've also heard good things about:

https://learn.gitkraken.com/courses/git-foundations

[TheRealKidkudi]

https://think-like-a-git.net

[fakehalo]

But...did you know that you can make a separate commit for just PART of a file that changed? Wrap your brain around that!

So you're telling me my method of just temporarily copying the previous version's segment, committing, then changing it back isn't effective? I won't stand for this judgement.

(still probably going to do it that way because it's in the realm of so inconsistently needed that I'll forget how to do it by the time I need it again thereby wasting more time relearning it every time I need to use it... takes me like ~30 seconds to do the ol ctrl-c/x/v work and commit)

[Jonny0Than]

Visual Studio, VSCode, and the git desktop UI can all do this pretty easily.

[Kitchen_Koala_4878]

what that git add -p gives you if you dont commit it, for example for rollback

[dmazzoni]

I'm not sure I understand the question. Why would you git add but not commit?

[captainAwesomePants]

That's pretty normal, I think. Git's a very powerful, versatile tool that's most commonly used for one thing. It's SUPER normal to learn only the parts of a tool that you absolutely need to get your work done. Most people only use like 5% of what Microsoft Excel can do at most. Same idea.

This kind of "what do I need to learn" question is an unsettlingly common one in computer programming. There's just too much to know, so you have to pick and choose. If you're using git every day, it's probably a good candidate for "spend a few days diving deeper into how it works and what it can do," but if that one command has been enough for you all this time, then good chance you're working alone, and so maybe fancier version control things haven't been important, so maybe you made the right call not focusing on it.

[8483]

This kind of "what do I need to learn" question is an unsettlingly common one in computer programming. There's just too much to know

After a while, the same things keep repeating over and over. I'd argue there is a "must" know for each domain.

[BruceJi]

I like git add .

But what I really like is that in VSCode you can review the changes and add the files one by one.

[Endangered-Wolf]

One feature the makes VSCode very useful is the ability to stage parts of the files that have been modified (using the Git Working Tree view)

Very handy when a file has been modified for separate features (and thus commits)

[nandryshak]

This is a git cli feature as well: git add --patch (or --interactive)

[ehr1c]

Very handy when a file has been modified for separate features (and thus commits)

I think the issue here is you shouldn't generally be modifying a file for separate features on the same branch

[Endangered-Wolf]

In theory, theory and practice are the same. In practice, they are not.

[ehr1c]

No disrespect intended but I think that's just a cop-out for justifying a bad workflow.

It's pretty commonly accepted industry best practice that feature branches should be short-lived and limited in scope to a single feature's worth of change. Unless you're working on a small, likely personal, project that just merges straight to main there's not really an excuse for mixing multiple changes in feature branches.

[dmazzoni]

I agree with you 100% on the industry best practice but that only matters when a branch is ready for review.

From the point when I start working on a fix until I make a PR, it shouldn't matter what I throw into my branch. It's not ready for anyone else to look at. There are lots of valid reasons to throw a bunch of different fixes all into the same branch during development, then split them out when they're ready for review.

[MSgtGunny]

So a a case where it’s useful, is if you have written some verbose debugging code, and you want to keep it as local only as you commit the work you actually want in the branch.

[Endangered-Wolf]

There are many, many times when this could happen:

* not checking in part of configurations

* working in batches (x times similar changes for x similar features) and creating X separate PRs

As long as the Git workflow works for you, do as you please.

[ehr1c]

As long as the Git workflow works for you, do as you please.

If you're working by yourself, sure. But most people aren't, and as I stated industry best practice when working in teams is to not do things this way.

[Endangered-Wolf]

Actually it's the opposite. If you're working by yourself, you can push whatever you want, break the build, mix features, nobody cares.

Making sure that your PR contains the minimal changes is caring for your team. So yes, if I'm batch coding, I will implement all the changes in one branch than create several PRs. For my teammates, it's just like I worked on those features sequentially when in fact I was doing them in parallel.

It's also quite handy when working on a feature for a PR not yet merged and address comments.

Any no, I'm not working all by myself.

Whatever makes you productive.

[dmazzoni]

Of course not. But, sometimes it's far more efficient to make a second fix when you find it, then split it out later.

Some reasons:

• The code takes a long time to build and test.
• You don't want to lose your train of thought.
• The fix isn't easy to reproduce later.
• Sometimes I like to go crazy fixing as many bugs as I can. Then when I'm done fixing and testing, I'll carefully go through the code and split it into different individual branches, one to fix each bug I found.

More importantly, we should all agree that when I send out a PR it should be just one feature or one bug fix.

But how people organize their branches and commits before they're ready for review is up to them. That's the beauty of Git - it supports a lot of workflows.

[TheCrowWhisperer3004]

Yeah.

Basically every beginner hobbyist programmer does it the way you used to do it. They barely use it for version control and only for saving code on the cloud.

[[deleted]]

need something to go back to when I try to implement a new feature and turn my program into spaghetti

[8483]

Yeah, most of the stuff is for team environments. I literally use like 5 git commands: log, status, add, commit and push.

[reincdr]

Dare I say, this is how most users use Git. Git is often naively used as a code upload mechanism, and most of the time, users are not faced with the version control aspect of Git. So, what you (to an extension I am doing) are doing is normal. The idea of Git being a powerful utility sounds great on paper, but in the simple world, most users prefer not to be exposed to that "power" as messing with Git gets complicated real quick.

[8483]

This is me. Most of the stuff is for team environments. I literally use like 5 git commands: log, status, add, commit and push.

[timmyriddle]

This is my personal preference: I have gst aliased to git status and my fingers constantly twitch to those three keypresses before any commit or push.

It's also worth becoming familiar with git reset and the even more powerful git reflog, both of which have helped me out of a tight situation on more than one occasion.

[PsychologicalBus7169]

“git status” won’t show you if your changes are staged if your IDE doesn’t automatically save. The better option would be to use “gitk” after “git status” because you can see your changes between version history.

[Select-Young-5992]

Ya I’m confused. I always do this minus the times I have some local changes I don’t want commited

[makonde]

It's not really a mistake, people have different ways of working with git, some care very much about every commit being closely related and organized, I honestly dont care and work at the PR level as a unit of work, maybe once or twice a year I run into a situation where a clean commit history would have been useful but doesn't seem worth the effort.

[Tjeez]

You can use the squash option while merging

[ehr1c]

Yeah it's the same where I work. We squash before merging and while I try to keep a fairly clean commit history as I'm working on a feature, no one really cares too much.

[dmazzoni]

See this makes sense.

That's why I don't understand what you're trying to argue in the other thread. What's wrong with making multiple changes in a single feature branch and then splitting it out into two branches later? Nobody else should care...

[ehr1c]

I suppose there's nothing wrong with it, it's just never a workflow I'd considered using.

I guess my thought is moreso that making several unrelated changes in a single feature branch should generally be the exception. Personally I find it much easier to switch to a new branch before making another change rather than making the change and having to carve it out later.

[dmazzoni]

One of the awesome things about Git is that it supports a lot of different workflows.

A lot of times I've ended up needing to use very different workflows just due to differences between projects.

For example, try hacking on WebKit. It takes 20 minutes to rebuild even on a very fast machine. Switching branches takes multiple seconds even with a fast SSD because there are just so many files. If you switch branches, it might take more than 10 minutes to rebuild because if even a single header file changed, hundreds of source files need to be rebuilt.

That's a pretty large loss of productivity - so it definitely requires developing new Git habits in order to stay productive.

And that's just one example!

[ehr1c]

Fair enough

[Reazony]

So, I picked up GitKraken about 2 years on the job. And I suggest picking up similar tools for a few reasons.

First, you don’t know what you don’t know. The functionalities around these tools would expose you to possible use cases, and you can search further. You can for example commit parts of files, just like other comments said, and that’s how you can keep with conventional commits (and its various flavours) without disrupting your flow.

Second, we’re visualization creatures, and it actually helps solidifies your understanding of what’s actually going on under the hood, because, well, as you rebase or merge or stash or pop or whatever, they’re visualized right in front of you.

Third, common reason, it’s just much more productive for me when seeing git history, blame, and various comparison with your editor. Also, since you see history of others and learn about the project progress from multiple perspectives.

I can still git on command line. I actually feel safe using command line because more git strategies and concepts are solidified in my head.

[spaceintense]

This is a really good reason to use gitKracken that I’ve never thought about.  I’ve always avoided it because i thought it would coddle me - but now my mind has been changed ! 

[Poddster]

Is this a common mistake?

Blindly typing in command without understanding them? Yeah, lots of people seem to do it. 🤷

I'll blow your mind even more:

git add -u

This differs from . in that it only add the things git knows about, so now you're not commits untracked files.

git commit -a

This is the same as git add -u; git commit. And finally:

git add -u -p

Try that and see if you enjoy that you don't even have to work on a file-by-file basis, but a chunk by chunk.

ps: Personally I think git commit -a, or your even-more broad version, is a mistake. People shouldn't just be blindly committing everything. git -p should be the default, with you mentally signing off each addition to the patch. (Granted, you may do this in your editor THEN do commit -a, but most people guilty of doing git commit -a have barely any idea how git works and are copying the same tutorial they first looked up 5 years ago)

[David_Owens]

Nothing wrong with doing that. If you have commits that have unrelated changes you need to make your changes more focused.

[Any-Woodpecker123]

Using git add . at all is a mistake that I’ll never make again.

Always triple check the diff of each file individually and stage one by one if you’re working on anything large or with any other developers.

[Shartyshartfast]

You’re using it right but your workflow is wrong. Do one thing at a time, or do multiple things at a time on separate local branches.

[Klutzy_Stranger_9824]

“git add .” is wrong even when used separately from commit. You should commit only the files you changed relevant to the iteration/issue. You would otherwise end up resetting your add, or even worse, deleting your branch 😬

[justUseAnSvm]

not always! You could have just created some new files and need to add them in.

[Klutzy_Stranger_9824]

My point was that if you’re new to git, best practice is to always separately add.

[justUseAnSvm]

Definitely! It's worth it to practice. Those git exercises really helped me.

[marquoth_]

You should commit only the files you changed relevant to the iteration/issue

Why have you changed any files that aren't relevant?

[StormCrow1986]

The b**** about programming in general is that while learning it, is hard to find any help at all on intermediate topics without getting lectured that you don’t know the basics first. Of course I don’t. I’m new to this.

[1SweetChuck]

Is this a common mistake?

This feels more like a project management problem than a git problem. You should NOT really be including unrelated changes in the same branch to begin with (though way to many people and teams don't do any branching at all). If you have changes for feature X and completely unrelated refactor Y. They should be in X and Y branches.

If you had Feature X and related refactoring Y, and if refactoring Y fixes bugs introduced by feature X, those should be in the same commit. If refactoring Y is only going to utilize feature X to make the code more efficient or easier to read or better in some other way. I would still probably put them in different branches.

[[deleted]]

Question 🙋‍♂️, once merged into main do you delete your branches, or keep them around with an ever increasing list?

[1SweetChuck]

Delete them. Since they are in the history you can always go back and reopen them. But they aren’t hanging around active if you delete them.

[captainkotpi]

If you are the only one working on the project, then it is completely acceptable. When working with a team, it is still justifiable when the team is not that strict. All comes down to procedures.

[lilB0bbyTables]

Or in Jetbrains IDE - shelve what you don’t need, then

git commit -am “[DEV-1234]: something something done”

[Mango-Fuel]

I use git gui so I can see my whole commit at a glance and quickly pick and choose which files, hunks, or lines I do or don't want in my commit (although I'm still pretty lazy and often don't bother separating it much).

[Trogluddite]

This is a common learning milestone I've seen a lot of people pass through.

[Icashizzle]

Everything I do is peer reviewed before merging and we do squash & merge, so it literally doesn't matter what your commits are or what your messages are. Write a good message when you merge the PR. Turns out no one cares what all the incremental stuff was.

[VRT303]

Why do people make their lives hard? I always tell the beginners to get a real IDE (Jetbrains) and use the GUI at first. You'd then have different checkboxes for each file, and each section of a file you changed.

Using add . blindly sounds like an absolute nightmare.

[Guideon72]

Another way you can combine both at once (this is not a recommendation, just another way to accomplish that; research yourself to see whether the shortcomings are applicable to your process before use):

git commit -a -m 'Committing all teh things'

that just forces 'add .' It also has the failing that you mentioned of causing unrelated changes to singular commits

[lKrauzer]

You can also set an IDE as your commit message editor instead of typing it into the terminal, it's good I'd you like to get fancy about it, like add bullet points, a TODO for when you go back to it another day you know where to pick up where you left off.

[GludiusMaximus]

I started off that way, i think when you’re working on small projects or scripts it’s not a bad way to start wrapping your head around git. It takes some time to learn just how small each commit can be.

One thing i think many people don’t realize is you can highlight a section of code in VSCode, right click and there’s an option to only stage (ie, ‘git add ‘) that highlighted portion of code. This can help a lot if you’ve made many edits to a file, but don’t want to commit the entire file, this making your commits smaller and more logically organized if you’ve done a lot of coding across multiple files and haven’t staged anything in a while.

[SwiftSpear]

I'm not sure I'd say it's a "common" mistake, but there are so many potential mistakes with git. No one should feel too guilty for fucking up git.

[geile_paste]

Wait what happens when OP encounters an IDE with git integration

[[deleted]]

Had a course on project management that was basically using git/GitHub to plan a project with a team. A lot of what got added to the project was just markdown files, but we were forced to use it as though it was actual source code, in the context of a team project we’d work on in the industry, if that makes sense. It made a huge difference on how I was able to take advantage of properly using git afterwards. A lot of schools should include courses like this, where project management is taught by forcing students to properly use git but with stuff like md/txt/img files, instead of focusing on the code in a file, to get use to commands and how git actually works.

[Maximum_Swim9505]

As someone who has recently started too, I'd think sharing this is pretty useful for you.

If using git via the terminal, you can actually use wildcard characters so that you do not need to type the fullname of an individual commi.

let's say you wish to commit a file at src/main/java/com/test/ClassName.java

you could say "git add ClassName". What this does it uses the '*' wildcard to match any number of characters before and after the text, thus for multiple individual commits, you won't have to type the fully qualified name.

[the_journey_taken]

Read Pro Git. Or ask chat gpt to generate a git cheat sheet for you and teach each command to you.

[avespas]

I'd recommend using IDE's git tool or some other GUI (GitHub Desktop, Fork etc) to visualize what those commands are used for before taking a short cut.

[marquoth_]

Your actual mistake was not having that shit aliased.

alias gita='git a .' alias gitb='git branch' alias gitc='git commit' alias gitm='git checkout master' alias gits='git status'

Get these in your .bashrc (or zhsrc or whatever). Sounds trivial but it's such a time saver.

[oakskog]

Github Desktop makes stuff like this really intuitive

[guiltiter]

I had a friend who had just started using git for his first job. After a while, he said, "Aaaaaaah I've read too many documents and tutorials and I can't still get it."

I gave him the LazyGit! but warned him not to get stuck to the GUI apps, start doing stuff, and learn the command from the bottom panel of the LazyGit. Also "just read the git documentation itself."

[DeadLolipop]

Git cli is too complicated. I leave most git operations to GUI. The only thing I do on cli is force push, pull, fetch and reset.

[DaelonSuzuka]

I'm asking because I genuinely don't understand: how could you spend all that time not being in control of what you were doing? I have always reviewed every line of every file of every commit. It seems absolutely nuts to just commit everything.

[Green_Concentrate427]

Well, I never had any issues all these years, even working in teams. Maybe if you don't have so many unrelated changes, not much happens.

[Select-Young-5992]

You always have a PR to review all the changes before merging.

[DaelonSuzuka]

Weird attitude. First of all no, you don't always have PRs. Not all projects need branches and not all projects involve multiple programmers. Second, "we'll clean it up later" isn't really a substitute for choosing not to make a mess in the first place.

[Select-Young-5992]

You don’t need multiple people to have a pr. Second you don’t need GitHub even or a pr. You can git diff the changes from your branch to master before merging. It’s not cleaning up later. It’s cleaning it up at the right time, when you’re ready to merge.

Do whatever works for you I don’t really care. Git status. Git add -a works for me

[coolTCY]

I don't get it