What your committing "policy"? How much do have to change your project to make it worthy of a commit?

What your committing "policy"? How much do have to change your project to make it worthy of a commit?

For instance, would you make a commit that fixes a typo in a comment?

Attached: git-logo.jpg (910x910, 76K)

Other urls found in this thread:

guides.github.com/introduction/flow/
twitter.com/AnonBabble

You commit whenever you want to. There's not requirement or standard what is okay or isn't except for don't commit something that breaks the build.

>commit stuff
>commit stuff
>commit stuff
>n commits later...
ah fuck if someone ever goes through the history it's going to be embarassing
>rm -rf
>git init

I commit for every logical change. I go in to edit with some purpose in mind (bug fix, add a feature, ...) and when that purpose is complete I commit. So, I would commit if fixing the typo was the reason I started editing.

>bug is introduced at a certain point in the history
>try to bissect
>the few commits all have a huge diff making bissect useless

t-thanks

Common issue but you can just maintain curated commits facing your remote-tracking branch.

I usually commit big chunks every few hours and at the end of the day I'm splitting these up into logical units, e.g. 1 commit per feature/fix.
Thank god for magit and staging individual hunks/lines instead of entire files.

learn how to rebase

At work? We don't use long-lived feature branches and hide most unstable code behind flags.

However, individual commits to trunk must pass the test suite always so we can roll back efficiently if there's a problem.

I've also worked in places that do use long-lived feature branches. I prefer it for work involving multiple developers (especially separated by many time zones) since it's easier to coordinate.

Is breaking tests in a commit okay?

>magit
my n word

>long-lived feature branches
I'd avoid those at all costs.
Not just because of merge conflicts but between long-lived branches the codebase as a whole can change massively (e.g. due to merging another long-lived branch)
Best approach is one master branch with CI and tags for release versions desu

Not that guy but you just make an unstable branch and work there, then merge to master when it's stable. I have never had a dev job in my life tho
See guides.github.com/introduction/flow/

>make a bunch of changes
>need to wait until it's not the middle of the night so the timestamp won't advertise how sad of a person you really are

Between adding a semicolon or changing a single letter case to adding half a dozen files and editing another half

Usually I only commit something that works. Occasionally, if I'll be gone for a while, I'll commit my WIP on a different branch so someone else can work on it or as an offsite backup.

You can avoid merge conflicts by rebasing on top of master or merging master in regularly. Unfortunately, I don't know a good way to automate this since resolving conflicts requires human intervention.

The problem that I have with trunk-driven development is coordination for big changes. If the new change exists conceptually as an idea only and a loose confederation of independent diffs awaiting review, then it's easy for people to get lost.

If you don't let people branch in the VCS, they'll do it in the file system (e.g. awesome_project2) or in the code using flags or environment variables or ifdefs or some other clumsy thing.

I will concede though that using branches like this has significant drawbacks though and in organizations where they're allowed people use them for things that are way too small to justify them.

Agreed.
Try to design your system such that you can introduce new work without breaking everything. Then integrate it as soon as you can.

Avoid refactoring unless it has a direction.

I have a colleague in my office who is getting lost because he can't help but touch every piece of code that he thinks doesn't live up to some ideal of Software Craftsmanship. His pull requests mix features + refactoring which makes it nigh impossible to merge. And because he touched too much code he ends up in rebase hell.

Long running feature branches have the same issues.

I feel for your colleague. I think it's a common junior dev problem.

If they're receptive to it, maybe you should explain the situation to them.

Use Gitflow, commit logical tasks, use pull requests

Wear programming socks, follow code of conduct, drink soy milk, approve PR with "LGTM"

Whenever I've made enough progress that a commit would be self-contained and describable.
>For instance, would you make a commit that fixes a typo in a comment?
Of course. I wouldn't just mix it with some other unrelated commit. It's important to be able to be able to view commits as units of change that has a singular purpose, or your history will be useless.

What's a good tool to curate commits?

>noble human mind tier
git commit -am "Added test functions to solver.cpp"; git push

>enlightened mind
git commit -am "ALSKJDjsdklf"; git push

>ascended mind
alias gc='git commit -am "sdafjhskjdf"; git push'

>the godhead's infinite conception
cp -dr * ~/backup

> implying codes of conduct are bad

>implying I implied programming socks were bad

>haaaaaands

I just fucking send shit whenever.

if I gave a fuck, I'll rebase but i usually only bother with that when I'm making some merge request.

At work, I don't have the luxury of git because some faggot thinks svn is better for some autismo fucking reason and everything from word doc specs to ancient, unused code is managed in one massive fucking svn repo. It's literally hell on earth how fucking terrible svn is. even 1.8 has some half baked shit like file-only changelists and partial checkouts only seem to work after you wasted a few hours checking out a giant folder of WIN32 binaries you don't even need because GNU/Linux.

>> implying codes of conduct are bad

>implying they are good
waste of time and never actually enforced or only enforced when convenient.

this. use common sense and don't try to make up rules or systems where none exist just for the sake of it.

HEHEHEHEH

Better to commit as often as you can. You can always squash later.

If you are thinking this, you are doing toy project that doesn't need scm at all. Same thing with licences. It's funny how much time people spend time with things that don't really matter. Just get your ridiculous toy project even started and stop spreading your autism.

>would you make a commit that fixes a typo in a comment?

Yes, everything that can be seen as its own chunk. A typo in a comment is independent of a new button or whatever. So it just gets into its own commit.

This way others can better follow what you did. Maybe not too important for the comment typo but if your "button-commit" would be declined for whatever reason, the typo will not be fixed.

Commits are free.

You always commit in logical chunks, how difficult can it be? If you're just fixing a typo, so be it. Try to find more typos and fix them as well...

>ah fuck if someone ever goes through the history it's going to be embarassing
git rebase --interactive [--onto branch/ID] branch/ID
git push --force remote branch

To be honest I usually only commit just before the pull request for a feature. Sometimes it ends up being like two-three commits when I find stuff to fix.

rude

>using CLI
I understand when doing commits. But don't tell me you people resolve merge conflict/inspect git diff in terminal.

I use SourceTree. I had to resort to CLI a couple of times for some niche functionality. Also, my superiors are using CLI exclusively - they aren't forcing me to use it, but obviously they can only explain to me how to do stuff in CLI - not in other software.
Although, they are either using IDEs or Bitbucket for diff.

what's the matter with that?

I find GUI git mergers confusing so I just edit the conflict files manually in a text editor/IDE.

I constantly use git diff in terminal.

And if you can use vim or emacs or such, you can obviously easily resolve merges in the terminal too.

That sounds tedious. With a GUI client it's two clicks.

Two clicks to do what exaclty, a merge of left or right without edit?

Yea, vimdiff or whatever you want to use does that too, but you're also already where you need to be if you want to actually edit something.

And you can get plugins for some convenience functions like vim-conflicted which automatically starts a 3-way diff and two 2-way diffs.

Pic related, the graph in the middle is just the author of vim-conflicted explaining what the 3-way diff is about. The 2-way diffs are then for base&local and base&upstream

Attached: tab1.png (957x599, 78K)

I started learning how to use git last night for a group project. I pushed like 3 commits out of 5 for editing the readme

That's fine. Now, in case the group does not like many commits because they actually have to read them, just create a branch that tracks the shared repository.

Then merge your stuff on that branch before your push it to the group & just continue work on your branch.

You could also do interactive rebases.

Well, we decided to keep the master branch as is and then we created separated branches for each of us with our test builds or small changes and once the other person reviews and we both agree we will push his or my branch into master.

Uh well yea, but beyond that you can locally open any number of branches that never get uploaded because they don't even have any remote tracked branches that git push will upload to.

You use these local branches to do all your messy experiments and dumb commit messages nobody else will understand and then generally merge into the "sanitized" branch that will be used to upload more meaningful commits.

At least that's a good way to use Git.

me...