Changed width:600px to width:500px

git commit - m "optimized responsivity for enhanced mobile experience"

I found a cool project on GitHub. I forked it and added a simple dev server with the intent of making it more accessible which could lead to more activity = improved project. I created a PR with small concise commits with very informative messages.

The guy who owns the project comments and says "I don't want your dev server, I have an apache instance locally on my computer". I tell him "Ok sure, but wouldn't it be nice if everyone else also had a nice dev server which can be started with a single command?", and other people join the PR and agree with me that we should make it available for everyone.

But the fucking idiot doesn't care, "No, I prefer to use my apache server". YOU FUCKING ASS WIPE, why do you even put it up on GitHub if you don't want contributions to make your project better and more available? I saw other open PRs where he basically did the same thing, left a snarky comment without merging it. What a fucking tool. Worst spent time ever.

FUCK YOU

Woooooooo!
Just finished my first fully automated CI/CD system. Now all my commits go through the pipeline and gets deployed to live automatically.

It's a small project but still, it's really cool!

Another real-world argument for why I always say git is worth learning properly.

Had to track a really weird bug down today. Had no idea where it came from, how long it'd been in the code and hadn't the foggiest what was causing it. Realistically it could have been introduced any time in the last year or two, and that's tens of thousands of commits in this repo.

Git to the rescue. Knocked up a quick script to test the case in question, fed it into "git bisect run", and 30 seconds later git found the exact (small) commit that caused the issue.

It's a brilliant part of git, yet it seems like almost no-one I know uses it. Some use "git bisect", but using "git bisect run" and passing a script to it seems to be alien to most - yet it's probably my most used tool when it comes to tracking down bugs like these.

Newly hired developer who calls himself ”senior” on linkedin has not contributed for 6 months. At least. I have been very helpful on many pair programming sessions. Directing him. Being extremely precise how things works and are working together. Small and big picture. He calls me and ask questions and I answer. Explain. Again and again. But it does not stick.

Nothing.

Extremely precise tasks. Written specifically for him.

Nothing.

He has like 10 commits in one year. It’s the worst I’ve seen in a developer role.

The other day in a zoom meeting he failed to declare a variable correctly. He copy/pasted a line instead and renamed the variable.

I saw this early. But I need not to work with him for a long time. It is now very clear that he will never contribute but in fact decrease the velocity of the team.

One year is a long time.

He is stupid. He can’t learn. Did he not tell the truth about himself when management hired him?

It so sad they hired him.

I find it really hard to make small, specific commits. I always stumble on unrelated things I want to change.

This happened 3 years ago in my previous company. It was a small start up company and we worked on PHP stack. One of the its ex-founders had written Windows Mobile App which now had to be upgraded with new features. So we hired this new dot net guy. I always thought dot net guys were ELITE coders and was excited to see how they work.
While I played Xbox and had fun, our dot net guy stuck to his workstation furiously working. My boss who was casually strolling out of his office for a stretch saw dot net guy working hard and suggested we all developers should take him as an example.
20 days went by and each day the dot net guy did the same. He came, he silently worked on his workstation, he left in the evening. In those 20 days my boss asked twice to the dot net guy if he has finished features he was assigned but he said he did not. After a month when he said the same negative answer and had nothing to show for the work he has done he was fired.
I was so curious to see what code that ELITE coder had written for a month but could not deliver a feature(Maybe some error he could not fix?). So I open the code repo on which he worked and I see 30 commits from that guy to it. He had made a single commit each day(Fair enough he wants to commit everday before leaving). It was time to check his commit diffs to see his ELITE code. What do I find? In every fucking commit he either added a blank line to the DocBlock or removed the same. Nothing less nothing more! So much for the hyped not-so-ELITE dot net guy...

There was an issue whilst you were away, we had to make a small css change.. We pushed it into master but it said something about the branch being behind the tip by 50 commits or something. It's okay, we forced it up though and force pushed it to production as well but the site went down.. In the end we had to ftp it up manually but the customer is saying things that were there before now aren't there any more?

I thought you put this "release process" in so things like this wouldn't happen! I think we need to review it as it clearly isn't working.

I think that two criterias are important:

- don't block my productivity
- author should have his userbase in mind

1) Some simple anti examples:

- Windows popping up a big fat blue screen screaming for updates. Like... Go suck some donkey balls you stupid shit that's totally irritating you arsehole.
- Graphical tools having no UI concept. E.g. Adobes PDF reader - which was minimalized in it's UI and it became just unbearable pain. When the concept is to castrate the user in it's abilities and call the concept intuitive, it's not a concept it's shit. Other examples are e.g. GEdit - which was severely massacred in Gnome 3 if I remember correctly (never touched Gnome ever again. I was really put off because their concept just alienated me)
- Having an UI concept but no consistency. Eg. looking at a lot of large web apps, especially Atlassian software.
Too many times I had e.g. a simple HTML form. In menu 1 you could use enter. In menu 2 Enter does not work. in another menu Enter works, but it doesn't submit the form it instead submits the whole page... Which can end in clusterfuck.
Yaaayyyy.
- Keyboard usage not possible at all.
It becomes a sad majority.... Pressing tab, not switching between form fields. Looking for keyboard shortcuts, not finding any. Yes, it's a graphical interface. But the charm of 16 bit interfaces (YES. I'm praising DOS interfaces) was that once you memorized the necessary keyboard strokes... You were faster than lightning. Ever seen e.g. a good pharmacist, receptionist or warehouse clerk... most of the software is completely based on short keyboard strokes, eg. for a receptionist at a doctor for the ICD code / pharmaceutical search et cetera.
- don't poop rainbows. I mean it.
I love colors. When they make sense. but when I use some software, e.g. netdata, I think an epilepsy warning would be fair. Too. Many. Neon. Colors. -.-

2) It should be obvious... But it's become a burden.

E.g. when asked for a release as there were some fixes... Don't point to the install from master script. Maybe you like it rolling release style - but don't enforce it please. It's hard to use SHA256 hash as a version number and shortening the hash might be a bad idea.

Don't start experiments. If it works - don't throw everything over board without good reasons. E.g. my previous example of GEdit: Turning a valuable text editor into a minimalistic unusable piece of crap and calling it a genius idea for the sake of simplicity... Nope. You murdered a successful product.
Gnome 3 felt like a complete experiment and judging from the last years of changes in the news it was an rather unsuccessful one... As they gave up quite a few of their ideas.

When doing design stuff or other big changes make it a community event or at least put a poll up on the github page. Even If it's an small user base, listen to them instead of just randomly fucking them over.
--
One of my favorite projects is a texteditor called Kate from KDE.

It has a ton of features, could even be seen as a small IDE. The reason I love it because one of the original authors still cares for his creation and ... It never failed me. I use Kate since over 20 years now I think... Oo

Another example is the git cli. It's simple and yet powerful. git add -i is e.g. a thing I really really really love. (memorize the keyboard shortcuts and you'll chunk up large commits faster than flash.

Curl. Yes. The (http) download tool. It's author still cares. It's another tool I use since 20 years. And it has given me a deep insight of how HTTP worked, new protocols and again. It never failed me. It is such a fucking versatile thing. TLS debugging / performance measurements / what the frigging fuck is going on here. Take curl. Find it out.

My worst enemies....

Git based clients. I just hate them. Mostly because they fill the niche of explaining things (good) but completely nuke the learning of git (very bad). You can do any git action without understanding what you do and even worse... They encourage bad workflows.
I've seen great devs completely fucking up git and crying because they had really no fucking clue what git actually does. The UI lead them on the worst and darkest path imaginable. :(

Atlassian products. On the one hand... They're not total shit. But the mass of bugs and the complete lack of interest of Atlassian towards their customers and the cloud movement.... Ouch. Just ouch.

I had to deal with a lot of completely borked up instances and could trace it back to a bug tracking entry / atlassian, 2 - 3 years old with the comment: vote for this, we'll work on a Bugfix. Go fuck yourself you pisswads.

Microsoft Office / Windows. Oh boy.
I could fill entire days of monologues.
It's bad, hmkay?

XEN.
This is not bad.
This is more like kill it before it lays eggs.
The deeper I got into XEN, the more I wanted to lay in a bathtub full of acid to scrub of the feelings of shame... How could anyone call this good?!?????

So we were supposed to have another good build today.

Supposed to.

This one guy on our team gets weird sometimes, and refuses to commit his shit until the last minute. He says "Don't worry, I'll handle all the merging, it'll be fine!"

What he forgets is that much of our code relies on his! His latest commits reworked a couple entry points and a class definition. No backwards compatibility.

He made his commit, and nearly our whole stack shit the bed. Jesus jumping Christ. Weekend? Nope.

I found a great app on iOS that allowed me to clone my Git repo, make commits, change branches, it had everything! I made a small commit and went to push to the remote server, but then it told me that I had to purchase premium to be able to push to remote. I was kind of upset, but I went to check the price of premium, in case it was a few cents. Nope, $25 just to be able to push commits. Seriously? If I was at my computer I’d be able to do this for free.

I haven't been able to work on the computer without getting a headache very soon after for almost 2 weeks straight now.

I presume I have grown a sensitivity to bright light, stemming from the time I dimmed my phone all the way about 5 months ago and never set it back until just now.

In my classes I will get random headaches that hurt like heck and make me feel groggy, making me unable to focus at all. And while doing computer work, I'll get the same thing.

I've tried getting my eyes checked again, and got new glasses about a week ago - still no help.

Prior to this incident I was working hard on a volunteer project with a small team. Since then my progress and commits have dwindled greatly, and I feel stressed out because I can't do what i want to do without hurting and feeling like absolute shit!

I'm currently trying to get my eyes used to bright lights again by setting things like my phone screen to a brighter setting, changing some dead light bulbs in different rooms of the house, and getting more involved outside.

I hope this goes away soon - I don't want to have this stupid headache every time I go to code or work in class.

Code reviewer tried as hard as possible to find issues in my commits.

After timereportimg 3 hours extra in a small ticket, he concluded we needed to try a different approach, even if code was OK? Why?

Simply because it was his idea and his idea is better. The reviewer needs to feel his superiority by any means.

Honest question:

I did a project and delivered it, but my boss did 4 commits after that. Without giving me any feedback.

They were small things: using a different library (just one line), and removing one debug line that caused a bug.

Should I ask him for feedback or just tell him "Hey I saw your commits, I'll make sure to use the new library and never let any debug line in"?

Me: I should divide my project in small parts. It will be a piece of cake.
Also me: (on last day of submission) 76 commits in 34 minutes.
*Face Palm* 🤦‍♂️

It's a nice feeling. Even if the commits are rather small.

Edit: Should say "you've pushed" rather than "you've commited".

May's last week was very hectic. I had just finished my final exams and there were going to be semester project evaluations in that whole week.

@safiullah and me had decided to make a whole Social Network with all features in it, for the DB course project.
All other classmates were making small management systems like ticket booking and etc.
We thought that if we really wanted to learn DB concepts then we should come up with something different than a management panel.
Hence we did it. This was the first time we used a framework. Well, I had written that PHP framework while i was learning about how frameworks work and the way they are made. So it wasn't a big thing but it was something which could be used as a base for clean and organized code.

It took about a month of commits and pushes and it resulted in a very good social network. It had all the features and algorithms present in a starter social network.

For us students, we were happy to see what a fine job we had done. We learnt a lot and used new concepts.

When we went to the instructor, she asked us to sit down and show the project. @safiullah placed the laptop, and logged out from the social network so that he could show her a demo.
She exclaimed,"Why did you do it (Log out) ?"
He replied: "To show you how it works🤷🏻‍♂️"
She:"Get to the previous state and leave it"
Then she asked different questions like what was a post request in php and how it differed from get? what library for DB connection was used... etc.
We explained each and every step.

She saw the frontend design and said "You've just added text to the elements" as If we were showing her a theme demo with hard coded text accomplished by inspect element.

She did not take a look at any other page than the one we had shown her at start. She navigated to no other page and asked nothing about what total features were implemented and how they were done?

Then she said Thank You and we left.

After some days marks were uploaded in LMS and we were just two points above the average.

She took no look and gave us the least when our project was the best.
I'm 100 percent sure she thought that we were showing her a project copied from somewhere else. 🤣

Remember that git commits are just like commitments in a relationship.

Make them small and avoid the big ones.

TFW you know you're going to be seen as a sort of code anarch or unenlightened (foo)barbarian for even suggesting that there are other git workflows more suitable than GitFlow, but you do it anyway.

Saying that I keep my master unprotected feels like telling Grandma I worship Satan.

I work with a very small team that's always physically nearby, we all get along well, trust each other and communicate to know what everyone is up to, which I guess is hard to believe in and of itself, but is it so fucking hard to believe that we'd be okay without redundant eternal branches or a vomitload of unbisectable history-warping merge commits?

How do you deal with situation when u need to merge multiple feature branches to develop branch? All feature branches have develop branch as base. So as soon as one feature is merged to develop then there will be contlicts in other feature branches.

Should I merge first feature branch to develop, then rebase feature2 branch on most recent develop and then merge the rebased feature2 branch to most recent develop and continue like that?

What if later I need to do hotfixes for previously merged branches? Should I revert them then rebase them on most recent develop and once again merge it to develop? Or should I just make small commits for fixes.

For a small team (<= 7 people) working on a self-managed Gitlab instance ('Starter' subscription), is it better if each user keeps a fork of the project they work on (working on other branch than master) or have everybody work on the same fork (still, different branches)?

Also, squash commits on branch merging, yes/no and why?

bitbucket you slow fucking sack of shit, we've confirmed with our remote team members that other people on other networks have it slow as shit too

I really wish we could convince our team to migrate to gitlab or github instead

can't tell if it failed to find the pull request associated with certain commits because it's slow a shit, shit (because it's atlassian bitbucket) or both

there is the small chance that maybe it's just the shit telecom industry in this country too on top of it, but things were acceptable before

Today it took me *five* commits and nearly 2 hours to tidy up a module before doing a tiny 5-minute change.
I could have just done my change but that thing was so messy, I first had to straighten things up.

It's not that I didn't expect that, the module was mainly done by my dearest co-worker who's code usually causes me anaphylactic shocks.
But I'm always amazed how hard it can be to follow a style guide, and ours is really small anyway.

I hate it when colleagues name their commits with a non descriptive name like "minor changes", "minor fixes", "small changes" and so on. I know that good naming is a difficult task in software development, but do I expect to much when I want them to explain shortly what exactly they changed since the last commit?
Good commit messages are always helpful if you want to do good PR reviews and furthermore if you want to go back to an older commit because someone fucked something up.
Don't get me wrong, my colleagues are great people and great developers, but some of them ignore the fact that good commit messages might be useful in the future for others and themselves

Hello, I am doing master in Pharmacy, but I like programming and consider to switch or connect somehow industries. I could write simple scripts and small programmes in Python, but I want to write code with good practice from beginning.

So my question what should I know and put in use, maybe some resources if someone has them or just terms for further search. At this moment I use gitlab for VCS (my commits sucks and my whole usage of Git sucks, but at least I use branches), I am trying to separate control from model (MVC but I guess I do it poorly), also I use keepchangelog rules for changeling, and semantic versioning for versions, PEP8 and Pokemon names for my variables and functions as it helps read code later.

We're slowly migrating to VSTS (sigh) from Mantis and SVN for tasks management and code repo.
It's been 4 months now and we still have to move the code from SVN to GIT, asked management when they plan to do that and they still give no ETA, and when asked to make sure our commits stays intact after the transfer I got told "no need for that we're just gonna copypaste the last version of the source code". And most likely the local SVN server we're using is gonna be dismissed.

On top of that, by the way they want to use it, VSTS is being terrible for tracking stuff. I'm so used with other tools at home for some side projects and even though I expressed my concern about VSTS I got ignored over and over...

Bonus (not so) fun fact: branches are something mythic here so everyone else commits straight to master and it's a pain in the ass everytime, because people happen to break things most of the time.

And no, unfortunately this is not a small company.

Send halp please 😭