When you stare into git, git stares back.

It's fucking infinite.

Me 2 years ago:
"uh was it git fetch or git pull?"

Me 1 year ago:
"Look, I printed these 5 git commands on a laptop sticker, this is all I need for my workflow! branch, pull, commit, merge, push! Git is easy!"

Me now:
"Hold my beer, I'll just do git format-patch -k --stdout HEAD..feature -- script.js | git am -3 -k to steal that file from your branch, then git rebase master && git rebase -i HEAD~$(git rev-list --count master..HEAD) to clean up the commit messages, and a git branch --merged | grep -v "\*" | xargs -n 1 git branch -d to clean up the branches, oh lets see how many words you've added with git diff --word-diff=porcelain | grep -e '^+[^+]' | wc -w, hmm maybe I should alias some of this stuff..."

Do you have any git tricks/favorites which you use so often that you've aliased them?

Today was my last day of work, tomorrow i have officially left that place. It's a weird feeling because i'm not certain about the future.
The job was certainly not bad, and after all i read on devrant i'm beginning to believe it was one of the better ones. A nice boss, always something to eat/drink nearby, a relaxed atmosphere, a tolerance for my occasionally odd behaviour and the chance to suggest frameworks. Why i would leave that place, you ask? Because of the thing not on the list, the code, that is the thing i work with all the time.

Most of the time i only had to make things work, testing/refactoring/etc. was cut because we had other things to do. You could argue that we had more time if we did refactor, and i suggested that, but the decision to do so was delayed because we didn't have enough time.

The first project i had to work on had around 100 files with nearly the same code, everything copy-pasted and changed slightly. Half of the files used format a and the other half used the newer format b. B used a function that concatenated strings to produce html. I made some suggestions on how to change this, but they got denied because they would take up too much time. Aat that point i started to understand the position my boss was in and how i had to word things in order to get my point across. This project never got changed and holds hundreds of sql- and xss-injection-vulnerabilities and misses access control up to today. But at least the new project is better, it's tomcat and hibernate on the backend and react in the frontend, communicating via rest. It took a few years to get there, but we made it.
To get back to code quality, it's not there. Some projects had 1000 LOC files that were only touched to add features, we wrote horrible hacks to work with the reactabular-module and duplicate code everywhere. I already ranted about my boss' use of ctrl-c&v and i think it is the biggest threat to code quality. That and the juniors who worked on a real project for the first time. And the fact that i was the only one who really knew git. At some point i had enough of working on those projects and quit.

I don't have much experience, but i'm certain my next job has a better workflow and i hope i don't have to fix that much bugs anymore.
In the end my experience was mostly positive though. I had nice coworkers, was often free to do things my way, got really into linux, all in all a good workplace if there wasn't work.

Now they dont have their js-expert anymore, with that i'm excited to see how the new project evolves. It's still a weird thing to know you won't go back to a place you've been for several years. But i still have my backdoor, but maybe not. :P

Unpopular opinion about Microsoft buying GitHub.

Just putting it out there that when you made your github repos you did so under their privacy policy and terms and will be protected under those in the future, and that both GitHub and Microsoft are corporations with the goals of making money.

Are people seriously mad that their code has gone from one capitalist corporation to another, with no foreseeable change in privacy or data policy? I have respect for those that switched to self hosted long ago since that's going from corporate to private, but if you throw away the UX and community GitHub has developed because a multinational corporation (with so many branches, products and divisions, which happens to have a few products you don't like) will soon own it, are you actually making a rational, guided decision?

Also just throwing it out there that GitLab is also a company. They've also had issues with keeping data intact in the past. They do, however, have free private repos (although I can't ever trust someone who gives me "free" privacy) as well as builtin CI. There are some definite upsides to it, although the UX has a ton of differences. If you're expecting the same dashboard and workflow you've used on GitHub, don't, GitLab has cool features but the bells and whistles aren't the exact same.

If you're switching to GitLab solely because of Microsoft, step back and think, regardless of how popular it might make you to hate Microsoft, is it really worth changing your development ecosystem to go from one corporate entity to another solely because you don't like the company?

I use GitLab and GitBub as well as Bitbucket and selfhosted git on a daily basis. They each have their upsides and downsides; but I think switching from one to the other solely because of Microsoft is not only totally irrational, but really makes light of/disrespects the amazing tools and UX the teams behind each one have carefully developed. Pick your Git hosting based on features and what works out for your use case, not because of which corporate overlord has their name plastered on it.

(Also just throwing it out there that lots of devs love VS Code, and that's Microsoft owned too... They did also build and pioneer a bunch of really cool shit for devs including Typescript so it's not like they're evil or incapable in any sense?)

You can hate me: as a 34 year old php developer, i've never used git in my workflow...
I plan to start today using it on one of my personal project (only because i have arrived at "backup-49.rar")(yes i develop on windows).
Finger crossed

You know what? Fuck it. Git CLI. Hot take.

Question is "least favorite". Not "worst". Not "least important".

Git is great, essential, fantastic, whatever. But I hate interacting with the CLI. I can never remember the stupid fucking commands, I always mess shit up if I need to do something outside of my normal workflow, and honestly, usually the correct way of doing shit looks fucked.

So fuck git CLI and its learning curve

Story time:

At a precious employer.
Hire shit-hot contractor.
No technical test at interview stage because he’s so shit-hot.
Is a uni lecturer.
PhD in mathematics.

Me: Shit, this guy must be good!

6 months later and a tragedy of errors and clearly misspent company funds later:

Manager: can you look at what x did and merge it into the product?

Me: Sure. *looks* *yells fuck very loudly*

*walks over to manager*

“Soooo... you know those 6 months and thousands and thousands you spent? It’s all for nought. There’s barely anything there, and none of it works.”

Manager: “Shit. What are we going to do? Can you fix it?”

Me: “To be honest, it would be quicker to just do it from scratch than try to work out what he’s done and failed to do.”

Manager: “Fuck. Ok. Go for it.”

I then had to build this entire new lot of systems, a workflow system, a user management and permissions system.

I got it done inside a month or so.

For context, we (the devs) knew something was afoot when the contractor couldn’t work out why his keyboard wasn’t working (it wasn’t plugged in), and he also *really* struggled to find his way around visual studio and git.

The moral of this tale? *always always* screen your candidates. Even if they seem amazing on paper.

Created a branch for the first time. Now I can switch and stuff. 😍

Awesome!

My typical development workflow:

$ ssh user@devserver
$ cd /appdir
$ git clone/pull
$ vim file
$ vim another file
$ tail -f /var/log/applog
$ vim file
$ git commit -am 'fixed the glitch'
$ git push origin dev
^D

In ancient times, a friend and I made a new website for a golf course, in exchange for free golf whenever we wanted it. We were traveling to Texas for work(we were Linux sysadmins for a defense contractor at the time) and found out that mechanical/logistic issues at the airport in Houston would delay our departure by two hours, but this wasn't until after the plane was fully boarded and had begun to taxi. So we sat on the tarmac at Kansas City Airport for two hours with nothing to do but release that website. We finished some perl hooks to site resources, and pushed the site live. This was on a laptop tethered to a phone with a CDMA data connection, before even EVDO was released.

Even so, it went great! I sshed into the server(running netBSD), swung over the necessary tags, and the site was up.

My workflow today is largely the same, just with git and a more elaborate .vimrc.

I dont know what to feel anymore.

Got hired directly without an interview into 'Data-analytics' department in fortune 500 company. This is my first job. Got hired because this company want start a website that cost millions.

Even though I am junior, I can see that this company has no idea about software development at all. No git server, no code review, no quality assurance and no proper workflow. No senior developer to guide us (junior dev) too.

There is one 'senior' consultant that work on automation project here but he just focus on his work and don't help us directly too.

The contract is about 1 year. Still got 11 months to go :/

Lead messed up the Git workflow (New repo), ask me to fix it. And when I said that we better do it from first properly, asked me if I even know git 🙄 Feel insulted.

Our class has a google docs document where we take notes for our technical subjects. I sneaked in a little note about git: "git push -f" is the recommended programm when pushing to origin for a smoothless workflow.

Let's see how many sheeps follow my instructions blindly😈

I started my actual gig as CTO of construction group (Innovation Hub) a year ago. And it was a hell of a ride, implementing kind of a scrum-ban for project management, XP, peer-reviews, a git-flow, git commit message formats, linters, unit testing, integration tests, etc...
And it's the fun part because with the CIO we had to drive the board to do A LOT of changes in their IT/Innovation drive.

But in one year there is a lot of KPI that went up :
* Deployment: When I arrived it took three stressful days to deploy a new version of one application, once a month. Today we do it every week, and it takes three annoying hours.
* We had no test. NOTHING! Today we have 85% code coverage for the unit test, and automatic integration tests run by our CI server every day.
* We had almost no documentation. Today our code is our documentation (it automatically extracted and versioned).
* We had 0 add value in the use of git. With commit messages as "dev", "asked task", inside jokes and a lot of "fix" and "changes". Today we have a useful git, and we even use it to create our deploy changelogs (and it's only mildly annoying!).
* More important, the team is happy! They get their purpose, see betterment in their tech mastery. They started doing conception, applicative architecture, presentations, having fun.

There is still a LOT of bad things we are still working on, and trying to solve (support workflow and betterment). But seeing what they already did, I'm so proud of my TEAM! I'm a fucking asshole, workaholic, "just do it" kind of guy. But they managed to achieve so much. Fucking PROUD!!

An amazing git story: A month ago coworkers did research and started with merge requests. Their workflow is as follows: A Feature is developed in a branch, then a merge request is opened. After a very short review it will be closed (rejected) and merged without request. (wtf!) After that the develop branch will be tested later, in case of bugs, a new branch per feature is opened.

A loooong time ago...

I've started my first serious job as a developer. I was young yet enthusiastic as well as a kind of a greenhorn. First time working in a business, working with a team full of experienced full-lowered ultra-seniors which were waiting to teach me the everything about software engineering.

Kind of.

Beside one senior which was the team lead as well there were two other devs. One of them was very experienced and a pretty nice guy, I could ask him anytime and he would sit down with me a give me advice. I've learned a lot of him.

Fast forward three months (yes, three months).

I was not that full kind of greenhorn anymore and people started to give me serious tasks. I had some experience in doing deployments and stuff from my other job as a sysadmin before so I was soon known as the "deployment guy", setting up deployments for our projects the right way and monitoring as well as executing them. But as it should be in every good team we had to share our knowledge so one can be on vacation or something and another colleague was able to do the task as well.

So now we come to the other teammate. The one I was not talking about till now. And that for a reason.

He was very nice too and had a couple of years as a dev on his CV, but...yeah...like...

When I switched some production systems to Linux he had to learn something about Linux. Everytime he encountered an error message he turned around and asked me how to fix it. Even. For. The. Simplest. Error. He. Could. Google. Up.

I mean okay, when one's new to a system it's not that easy, but when you have an error message which prints out THE SOLUTION FOR THE ERROR and he asks me how to fix it...excuse me?

This happened over 30 times.
A. Week.

Later on I had to introduce him to the deployment workflow for a project, so he could eventually deploy the staging environment and the production environment by hisself.

I introduced him. Not for 10 minutes. I explained him the whole workflow and the very main techniques and tools used for like two hours. Every then and when I stopped and asked him if he had any questions. He had'nt! Wonderful!

Haha. Oh no.

So he had to do his first production deployment. I sat by his side to monitor everything. He did well. One or two questions but he did well.

The same when he did his second prod deploy. Everythings fine.

And then. It. Frikkin. Begins.

I was working on the project, did some changes to the code. Okay, deploy it to dev, time for testing.

Hm.

Error checking out git. Okay, awkward. Got to investigate...

On the dev server were some files changed. Strange. The repo was all up to date. But these changes seemed newer because they were fixing at least one bug I was working on.

This doubles the strangeness.

I want over to my colleague's desk.

I asked him about any recent changes to the codebase.

"Yeah, there was a bug you were working on right? But the ticket was open like two days so I thought I'll fix it"

What the Heck dude, this bug was not critical at all and I had other tasks which were more important. Okay, but what about the changed files?

"Oh yeah, I could not remember the exact deployment steps (hint from the author: I wrote them down into our internal Wiki, he wrote them done by hisself when introducing him and after all it's two frikkin commands), so I uploaded them via FTP"

"Uhm... that's not how we do it buddy. We have to follow the procedure to avoid..."

"The boss said it was fine so I uploaded the changes directly to the production servers. It's so much easier via FTP and not this deployment crap, sorry to say that"

You. Did. What?

I could not resist and asked the boss about this. But this had not Effect at all, was the long-time best-buddy-schmuddy-friend of the boss colleague's father.

So in the end I sat there reverting, committing and deploying.

Yep

It's soooo much harder this deployment crap.

Years later, a long time after I quit the job and moved to another company, I get to know that the colleague now is responsible for technical project management.

Hm.

Project Management.

Karma's a bitch, right?

Ubuntu, Openbox, vim, duckduckgo, Gmail, mailgun, digitalocean, xterm, libvirtd, remmina, polipo, insomnia, ulauncher, copyq, nextcloud, rofi, ssh, bash, Firefox, Firefox-Dev, Vivaldi, steam, itch, git, proton, wine, vlc, cherry mx brown and black, android, mint mobile, Asus, amd, ubiquiti, and plex.

What's in your workflow?

I have been working with git for years now, and I could never work on a project (regardless if big or small) without it. Its great.
However, just a couple of days ago I learned about the git flow branching model.
Even tho I also worked with branching on a daily basis for years, I did not know about this model. And I have to admit: Its awesome.
If you don't know it, I highly recommend you to look it up. It really improves the already organized workflow with git even more. :)

I love git stash.

It's helps a lot for doing refactors to me. I guess it's not the most complex workflow, but it wasn't obvious to me when I started with git. Let me explain.

Refactors. As you start writing the first lines of a refactor, you start to notice something: you're changing too many things, your next commit is going to be huge.

That tends to be the very nature of refactors, they usually affect different parts of code.

So, there you are, with a shitload changes, and you figure "hey, I have a better idea, let me first do a smaller cohesive commit (let's call it subcommit) that changes a smaller specific thing, and then I'll continue with the upper parts of the refactor".

Good idea, but you have a shitload of changes nearly touching every file in your working copy, what do you do with these changes? You git stash them.

Let's say you stash and try to do that smaller "subcommit". What sometimes happens to me at this point is that I notice that I could do an even smaller change inside this current "subcommit". So I do the same thing, I git stash and I work on that even smaller thing.

At some point I end up `git stash pop`ing up all these levels. And it it shows that git stash is powerful for this.

* You never lose a single bit of work you did.
* Every commit is clean.
* After every commit you can run tests (automated or manual) to see shit is still working.
* If you don't like some changes that you had git stashed, you can just erase them with git reset --hard.
* If a change overlaps between a stash you're applying and the last "subcommit", then
if they differ, git shows conflicts on the files,
if they are identical, nothing happens.

with this workflow things just flow and you don't need to wipe out all your changes when doing simpler things,
and you don't need to go around creating new branches with temp commits (which results in bloated temp commits and the work of switching branches).

After you finish the refactor, you can decide to squash things with git rebase.

(Note: I don't use git stash pop, because it annoys the fuck out of me when I pop and you I get conflicts, I rather apply and drop)

I pushed all my work to Friday
And I (git) pushed all my work on Friday

😂

Goals before week 200:
- Release some tracks
- Play a few gigs
- Build python program which I've got in my head for some time now
- Master git workflow

Edit: typo

Textexpander. Ggpu = git push upstream, gg. = git add ., and ggc = git commit -m "" ... I love that I don't have to type out my whole damn name, username, email and work email all the time. Just expanding my email address is enough of a win for me with that tool. Also Alfred + utf symbol workflow. And newest addition - vimium to easily pin tabs.

!rant

I love the cloud. Not the google drive kinda, but the one that integrates with your workflow like git. Tinkercad, for example, its great that i can just log in from my work pc and continue modeling where i left off.

Okay. So finally I moved into a new pc. Because I never worked in a company, I have absolutely no idea what is the proper standard workflow of developing a website. My work flow was the same in past 12 years, how I have learned in the school: Used xampp, developed everything, used git only locally, when stuff was ready I fired up Filezilla and uploaded everything, and used ssh to make the final adjustments. When I have made some changes, I just uploaded the files I have touched, in the same way, optimized if it was necessary, done. I wonder if someone can clarify me how a proper workflow looks like for php/laravel, mysql, nothing fancy. Is using xampp still okay? Or what is the industry standard procedure?

I invited a colleague to the repository and taught her some basic git so she could edit some texts without having to interrupt my workflow.

All of a sudden, some parts stopped working. Guess i should have been a bit more articulate when telling her about commit messages..

I've been training a few junior devs for about a month in the use git and adopting to a collaborative team workflow. My blood is boiling at this point. As part of the training we had the junior team build an iOS app. Their solution was for each of the to have a git repo of their own and a master repo for everyone. If they can get it to work in their individual repos, they would move that code over to the master repo. This seemed to have worked for them but it's completely wrong in trying to understand how integrating their work by the hour or so would benefit everyone involved and ultimately how that can influence the quality of the product. So I highlighted the problem with the individual repos and encouraged the use of a single remote repo. OOP is none existent all the code is slapped into a view controller. I have about given up. Let's see what this week will bring.

I scratched my head when GitHub gave a name ("Flow") to a normal workflow of git. Anyone else?

Coworker just showed me how he avoids merge conflicts and I'm undecided on it. We use feature-branch workflow, so if a feature takes a long time to finish, it may mean merging master multiple times. He avoids it by stashing changes instead of committing them, then when he needs to merge master into the branch it's still clean. When the feature is done and he's ready to commit, he pops the changes and git diff shows all the changes before you push and you just change what you need instead of being forced to use the horrible merge software.

There must be problems with this, right? This seems too easy for it not to be the standard.

Workflow? WTF! 😅
When your team lead posts all the pending / new Features that needs to be integrated into the app in GitHub repo - > Issues.
And then asks me what's the status of Bugs.

Like what the FUCK am I supposed to say. You. SIR, motherfuck, just added list of all new features in git issues and you want status on Bugs.

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?

Hi everyone, I’m trying to wrap my head around dev ops but struggling with the whole continuous integration workflow. From my understanding it goes something like the following:
1. pushing a change to some repository (git)
2. Some tool (Jenkins) tries to build it and if it’s succeed, creates a image /container (docker).

These containers are hosted on some cloud service (aws)

Some workflow, walkthrough, or examples would be very appreciate.

Does anybody here developing Opencart module using Git, I am just curious how the workflow looks like

Note: I know, Opencart is not really a good choice

How do you protect your team's git remotes?
We tend to protect the master and stage branch from force pushing and only allow merging pull requests after successfull recent tests and successfull review by someone with proper permissions. Depending on the project the Dev branch is only protected from force pushing though. All other branches are free to handle however wanted.

We recently had someone do a "git push -f --mirror" without understanding the command. Quick reminder what that does: it mirrors all your local branches to the remote so that the remote will be a mirror of your local repo. Branches that exist on remote but not on your machine will be removed from the remote.
A then needed to work from B's feature branch but of course that was gone... So while the idiot didn't fuck up our protected branches he still fucked over other people's workflow with that.

Is there an alternative to outright blocking force pushes which could have prevented that (except force pushing intelligence into his brain)?

So for fear of starting a flame war which should I learn and go through the hassle of setting up for this superior workflow everyone goes on about... Vim or Emacs?
I need to configure it for dotnetcore, editorconfig, Perl, php, docker, git etc. I work across windows mac and Linux so it would be nice to have an editor that worked the same everywhere. Currently leaning more towards vim as I don’t really know much about Emacs so what’s worth investing my time in?

!rant

Often times while working/debugging I get to a state where the app/whatever works but then I realize that it didn't, so some more changes and I get to a new state.

Question is, does there exist something which lets me switch between these states without messing up my git? I do have a solution in mind but want to know if it already exists.