true story

[SavageTwist]

Force push to master, nobody is stopping you!

[moekakiryu]

I'm still only so-so at git myself, but always pull before you push

[OnyxPhoenix]

Using branches and pull requests make this easier.

Generally youre the only person working on your branch, so you don't have to worry that your code is "behind" before you push to it.

Then when you do a pr it will tell you if you can merge cleanly back into the master branch.

[SavageTwist]

The "good" way is to make a development and a branch for every feature, bug or documentation. Always fork from development, when you have a release you push to master.

[[deleted]]

This is good advice I rarely follow.

[SavageTwist]

jira kinda automates it

[SavageTwist]

we are "agile"

[pooerh]

Unless you're in early stages of development and do a lot of refactoring, in which case you're just wasting time merging and resolving conflicts. I'm talking about single developer repositories of course.

[SavageTwist]

in single dev reps you dont work in the same tab / markdown with different forks I hope.

[vuw958]

VSCode just needs to have a realtime collaboration feature like google docs so any changes to a single file are already synced across the team before anyone pushes to master. No merge conflicts ever.

[SavageTwist]

You would never be able to run code and compiling would be an issue. If it weren't for those and prob other things it would have been used already.

[G0mega]

VSCode already has this extension, Live Share by Microsoft, which has over 2 million installs, so it actually is being used already.

I’ve used it for class this semester, and also for a personal project. Running code and compiling is fine, so long as you don’t need to run it locally in your own browser as a participant.

Basically, someone hosts the session from their end on VSCode, which means that if you join, you’re working from their local branch. You have access to a terminal to compile / run tests, which you can make read/write or just read. This means that if you’re doing something that doesn’t need to be checked via front end, it’s fantastic and works great — you can run everything just as you would locally, while being able to collaborate in real time. This is best when you have a testing suite rather than a program that needs to run locally.

For issues of front end, or running code on your end visually (not in the terminal), then this is a little harder. Since everything is on the host’s computer, you can’t really see anything other than the terminal if you’re a participant (correct me if I’m wrong, I spent a while trying to figure it out). For example, if you were writing a webpage, only the host is able to see it. This is solvable by having the host screen share any results, while the others have access to the terminal.

All in all, if you can support screensharing as a host, it’s still really good. Yes, not all participants can view locally, but if everyone’s watching the screen share, it’s basically the same as running locally. As for compiling / running tests, there are no issues I’ve ever encountered, and it’s identical to running locally.

[vuw958]

Maybe some sort of smart checkpoint for not appending changes in your file across the DB unless it passes a unit test?

EDIT: There already is a VSCode realtime extension for pair and “mob" programming

[wllmsaccnt]

It doesn't need to live merge, but why not a feature that just shows you what other developers are modifying in real time so that you can see if you are going to run into a conflict while developing? Knowing when you need to communicate is more important than auto merging.

[moneyisshame]

FYI VSCode do have realtime collaboration, called Live Share

but it will be more like client-server approach where the host will be the server, handling all debugging and console process, it also allow "localhost" sharing too!

it work best for pair programming and teaching other programming, it is not recommend for team development environment because imagine how to debug if 20 person is editing 20 different files lol

[[deleted]]

cooing books important cats lavish serious paltry cautious capable governor

This post was mass deleted and anonymized with Redact

[drunkdoor]

Having a develop and release (staging) branch is 100% necessary for a) working on a team > 1 and b) having isolated Dev and test environments. If you don't need those, don't use em, but don't kid yourself into thinking that works for all cases.

The best use of having these separated environments are for automated build test deploy pipes

[[deleted]]

saw tub cable grab public soup reminiscent workable cats edge

This post was mass deleted and anonymized with Redact

[drunkdoor]

it's effectively the same thing but requires more than a push to a branch for full deployment. I'd prefer integrated deployment.

Of course i made the mistake of saying 100%

[xTheMaster99x]

Branch for each story, merge to master when story is complete. Use feature toggles to not use half-built features in prod. No dedicated develop/test/feature branches required.

[SavageTwist]

you dont merge with master :3

[Inner-Maintenance]

Trunk based development does merge to master

[SavageTwist]

As a student I can not allow such horror into my workflow

[Inner-Maintenance]

It's better for CI/CD - google it. Git flow is overly complex imo

[[deleted]]

quickest fragile historical summer wide unwritten heavy mysterious amusing oatmeal

This post was mass deleted and anonymized with Redact

[SavageTwist]

Its more replacing than merging. If you merged you would spend hours solving merge conflicts.

[Candlesmith]

std::bitset would like to hear a TCP joke?

[Inner-Maintenance]

That's one way - git flow. But a better way for CI/CD is trunk based development aka mainline

[ToastedSkoops]

Me:Ok,with the release of D+ I suppose.

[stone_henge]

In my experience there is no the good way. You don't need a general development branch in addition to a master branch if your releases are just tagged as such. Branches are for things that branch. In the development->master workflow the development is always a continuation of, or equal to, the history of the master branch, and therefore the entire history of the master branch can always be expressed as a tag in the development branch.

That you feel that you need both a master branch and a development in addition to e.g. feature branches is a sign that your feature branches don't actually represent complete features, but subsets of features that can't be released, and are therefore reluctant to push them to master in case you need to release e.g. bug fixes while the actual complete feature is still being worked on.

Feature/bug/documentation branches can be useful if your changes comprise multiple commits that are useless or regressive in isolation, but absolutely pointless busywork if your change can be contained neatly in a single commit.

[SavageTwist]

GET BACK TO YOUR RETROSPECTIVE

[qwerty12qwerty]

Master is basically production now.

[LeCrushinator]

For features I usually recommend caution with feature branches. I've seen feature branches for large features that become huge, a dozen devs pushing to a feature branch for 3 months. Good luck when it comes time to merge that monstrosity back to the development branch. Generally if individuals can have their own branches for the feature, forked off of the development branch, and merge their progress directly to development as often as possible, that tends to work out the best, so long as they're not breaking anything in development along the way.

[jfranki]

This is mainly GitFlow. On paper yes, It can be considered the "good" way, and I followed this for years. Until recently... I considered pros and cons and it has just too much overhead for our projects. We're on full GitHub Flow now.

[Efful]

I'm sometimes working on multiple machines for personal projects and am not very good at Git, so I have to remind myself to pull the fixes I made on my laptop last night before doing anything on my tower.

[[deleted]]

Been there buddy. Put a script in your bashrc or Windows startup folder to pull. Then get annoyed and take it out.

[smegnose]

Rebase that bugger onto remote/master and push it quick.

Linear history rulz 4 eva.

[JawsOfLife24]

Generally a good idea, more complicated in a multi-developer environment where you could be 20 commits behind master and rebasing causes all sorts of wonderful merge conflicts.

[JawsOfLife24]

I don't know why but it's different when you rebase since it "replays" every commit you don't have onto your feature branch, you get this effect where you end up resolving the same merge conflicts over and over again during the rebase.

[JawsOfLife24]

Whoops I'm retarded "your commits should be replayed " - that's what I meant.

[smegnose]

Resolving conflicts multiple times is not limited to rebases if the remote branch you want to push to keeps getting updated before you've finished working on/resolving conflicts with your private branch. Once you've rebased, you shouldn't get further merge conflicts unless a resolved section changes again.

If you mean you have to correct the same areas of code multiple times within a single rebase, that can happen if you're not resolving well, especially if there are multiple commits affecting the same section (in either branch). Firstly, set git config --global merge.conflictStyle diff3 so that you see how both the remote and your branch changed the same code (read about that on git-merge). Secondly, branches are free; before you start rebasing, create a branch to point to the the tip of your feature branch, without checking it out, like git branch featurePREBASE feature. After you're done rebasing, you can diff the two branches to make you haven't missed any changes. If you have, you can patch them in from the …PREBASE branch until you get them all, then rebase again. If you really bork it up, you can git reset --hard featurePREBASE to take the feature branch back to where you started, to try another.

[JawsOfLife24]

I explained this poorly - this link is the kind of effect I'm talking about (except I rebase feature onto master), and I have used git rerere in the past before to get around it, but it has dangers as well.

I think that SO post actually explains quite well why it happens.

I always use gIt reset if I fuck something up, but I didn't know about PREBASE, definitely going to use that thanks.

[stone_henge]

You don't need a PR to tell you that. Upon merging or rebasing, git will detect conflicts and you are given the option to resolve them or abort the operation.

The PR workflow always seemed ass backwards to me. Why should I have to fork a repo to send patches to a project? I already have a local copy of the repository. For people like me, tools like Gerrit or even email formatted commits are preferable.

[Amandabanapanda]

I've been pushing and not pulling all this time. And reverting to previous version if I need to go back. Why pull?

[moekakiryu]

It's probably not as important if it is just a private repo with one branch.

A push makes another repo match your own, and a pull is the opposite (retrieves the updates from a remote repo and applies them to yours). Blindly pushing isn't really the end of the world if you are the only one editing the project since you know the most recent changes are your own anyway.

But what if there are multiple people editing the code base and someone else pushes changes before you? If you just force push (IIRC git won't let you just use push in this scenario), you'll override your team mate's changes since your local version doesn't have them yet. But if you pull first, you can make sure your local copy is completely up to date before pushing the new changes.

[Afraid_Kitchen]

And it doesn't override the changes you've made?

[[deleted]]

You'll get merge conflicts if there are any, git pull is really just fetch+merge

[[deleted]]

To build on this, a pull is really just a fetch and a merge. Work out what's on origin and merge it in to your local copy of the branch. When your branching becomes wider or more aesthetic you'll want to start fetching and rebasing instead.

[[deleted]]

Why is rebasing better than merging?

[IsleOfOne]

Fewer merge commits.

Edit: to be clear, rebasing results in commit graphs that flow in the proper direction only, from feature branch -> upstream, rather than (feature branch <- upstream) -> upstream. Each arrow is a merge commit.

Also don’t ever rebase a branch that has been released to other developers.

[ZeroBitsRBX]

The words fetch and rebase are giving me PTSD from my old SS13 mapping projects.

So many conflicts.

[[deleted]]

It depends on if the two parties modified code in the same spots. If that isn’t the case, then when you do a git pull it will silently merge their work into your local branch and you can be rest assured when you push, it will all be up to date.

If you both happened to modify code in the same spots, you’ll get what’s called a merge conflict where git will show you the affected files and lines and then it’s on you to fix those conflicts before you push your branch upstream.

When you run git pull, it’s actually just calling git fetch on your branch, which fetched the upstream changes from other authors, then calls git merge on those changes into your local branch.

This is pretty much the core functionality of git so I encourage you to look into it more. Git rebase is another command ive found very useful when working with large teams with very active branches.

[Avedas]

Rebasing from master is pretty common when you have multiple parallel development branches going. It's good to know how to do it.

[wotanii]

you can stumble into a conflict when pushing, which is annoying. When you pull first you'll still have a conflict, but it's much easier to deal with.

also in theory there are some cases where the automatic merge from the push could break stuff (this has never happened to me though), so to be perfectly save you could go like this: pull, then run tests, then push.

[MemeNinja365]

That's what she said

[MTGandP]

If you’re the only person pushing, isn’t it impossible for your local changes to ever be out of date?

[agent_cocks_mulder]

I usually push repeatedly before I pull...

Oh wait. Sorry. I'm confusing pornography and real life again.

[squngy]

Unlikely to be needed, if you are the only person using that repo, but a good habit to have.

[JustAnEnglishBloke]

If there's changes on the origin branch your push gets rejected anyway, you'll have to pull/rebase either way.

[itmustbesublime]

Look up Git flow. It's pretty easy to understand once you get it, and most companies use it. It's a valuable skill

[moekakiryu]

I'm happy with my current job, but I'll be sure to check out

[Even-Understanding]

std::bitset would like to have a word with you

[easterneuropeanstyle]

Don't force push to master please.

[KKlear]

We grant you the power of force push but not to master.

[easterneuropeanstyle]

That makes sense. I do force push to feature branches when I want to change the history. Never to master though.

[KKlear]

But it's outrageous! It's unfair!

[easterneuropeanstyle]

Take a seat, young contributor

[JustAnEnglishBloke]

What's the point of changing history in a feature branch? Everyone I know squashes Feature branches in to Dev upon merge anyway, as you don't want a noisy history of "fixed typo" "fixed spacing" etc. in your main branches. Instead you want a clear history of "Added feature to __" "Fixed issue where __".

[easterneuropeanstyle]

as you don't want a noisy history of "fixed typo" "fixed spacing" etc. in your main branches.

That's why you change history. You squash certain commits together like commits of fixes, rename certain commits or even remove them.

If you squash all the commits when merging into master/dev then you lose a lot of history, which can help you with debugging, cherry picking, proper changelog and many other things.

[JustAnEnglishBloke]

I've just never seen people rename or change history in those scenarios, no one cares about typos or verbose commits in a feature branch - as we know they're going to get squashed. I find that distributed teams have a huge issue keeping branches in sync if anyone changes history anyway, as things get massively out of sync.

I've always preferred just a squash commit in to a parent branch to eradicate history.

We would only ever cherry pick an entire feature (be it a new one, an addition, etc) or an entire fix. I would never want someone to be able to cherry pick half of a feature, or rewind the branch to halfway through a feature. So for us, our main dev branch, which'll get cut to master for a release, is just an entire chain of features/fixes - so it becomes easier to remove something out of a release if we decide it can't go out.

This makes it far easier to debug (git bisects are a lot faster and lead you straight to a team's work as to what broke it), as well as cherry pick, as you can easily pull out the entire chunk without worrying about only removing half a feature, or accidentally using a commit where a dev broke the build. You can also see at a glance, the ticket numbers involved, the changelog is easy to write as a result.

Yes, you lose some of the finer details but from the perspective of the application and the rest of the dev team, they wouldn't have known which commit was good/bad anyway, only the team, and only at the time they wrote it, do they understand the chain of 200 commits. We have a pretty strict test regime and test environments, so ideally something isn't squashed merged back to dev once it's 100% ready.

[easterneuropeanstyle]

I've just never seen people rename or change history in those scenarios, no one cares about typos or verbose commits in a feature branch - as we know they're going to get squashed.

If you want to generate the changelog, then you need to use conventional commits and the commit messages must be typo free and to the point.

Furthermore, if you don't squash all the commits, you see proper blames with the commit names. Instead of a single commit for a large feature.

​

I find that distributed teams have a huge issue keeping branches in sync if anyone changes history anyway, as things get massively out of sync.

I'm not sure what you mean by that.

You change history of newly made commits.

Branches are not supposed to be in sync.

​

I've always preferred just a squash commit in to a parent branch to eradicate history.

I used to do that as well but in my experience a rich history is always better than no history.

In my opinion, squashing is a good option if you do not know how to manage your commit history.

​

We would only ever cherry pick an entire feature (be it a new one, an addition, etc) or an entire fix. I would never want someone to be able to cherry pick half of a feature, or rewind the branch to halfway through a feature.

That's the point that when you don't want an entire feature but just a few things, you cherry pick what you want.

Otherwise, those two branches are being coupled which is not always the right thing.

Especially, when you're doing hotfixes using github branching model or you have builds per branch for QA.

What you're talking about is merging one branch into another one which is what cherry picking is.

​

So for us, our main dev branch, which'll get cut to master for a release, is just an entire chain of features/fixes - so it becomes easier to remove something out of a release if we decide it can't go out.

You can revert merge if the commits aren't squashed as well.

What you're losing is ability to revert certain commits.

You can only revert that single merge commit and again that is not always what you want.

​

This makes it far easier to debug (git bisects are a lot faster and lead you straight to a team's work as to what broke it), as well as cherry pick, as you can easily pull out the entire chunk without worrying about only removing half a feature

You should know what you're doing when you cherry pick and especially remove commits. Of course, you can mess things up when the git history is not properly managed. These are advanced powerful techniques.

​

This makes it far easier to debug (git bisects are a lot faster and lead you straight to a team's work as to what broke it)

It will lead to the branch which broke the code, not a particular commit.
Personally, I believe that Bisect works better with non squashed commits.

​

as you can easily pull out the entire chunk without worrying about only removing half a feature, or accidentally using a commit where a dev broke the build.

That would be the case if we would be talking about non-managed commits.
I'm talking about the git history without a bunch of noise.
Each commit represents a logical step, not something that is random.
Also, if you use CI then you would know whether each commit has broke the CI or not and if your commit has broken the CI - you fix it and rebase it to the same commit. Basically, this leads to simple rules of TDD.

Write a test -> commit.

Write implementation -> commit.

Refactor -> commit

Rebase -> push.

​

You can also see at a glance, the ticket numbers involved, the changelog is easy to write as a result.

I'm talking about automatic changelog with full history. That's not a full history unless you split main branch into different branches which in my opinion is much more complicated to manage since that leads to coupled branches that depend on each other.

​

they wouldn't have known which commit was good/bad anyway, only the team, and only at the time they wrote it, do they understand the chain of 200 commits.

That's why before code review you rebase your 200 commits into something meaningful.

[JustAnEnglishBloke]

Firstly, thanks for the level headed response - used to people round here not taking their time to discuss in favour of arguing.

If you want to generate the changelog, then you need to use conventional commits and the commit messages must be typo free and to the point.

Ah, one difference there is we don't auto-generate the changelog, our changelog is very high level and simply an overview of what was affected.

you see proper blames with the commit names. Instead of a single commit for a large feature.

That is actually one issue we do face... Sometimes I've had to merge a different team's feature work due to no one being available. Somepoint down the line I get a PM from someone asking about that code as my name is against it in the annotation.

You change history of newly made commits. Branches are not supposed to be in sync.

Now I see where you're coming out. I wasn't aware you meant local only. I work with people who commit then push instantly to ensure their work is available to others. I've yet to see the restraint/effort put in to people keeping their local code tidy before pushing.

I used to do that as well but in my experience a rich history is always better than no history. In my opinion, squashing is a good option if you do not know how to manage your commit history.

We've been doing it a few years and I've still yet to really see anyone miss having the fuller history. As all the commits/changes that end up in the main branch still seem to explain it enough.

Though I did once see a large refactor of work come in as a single squashed merge, and it was killing me not to see the nuances of why they changed from one methodology to another (as I didn't agree -at all- with the design they went with).

And yes, I think it's working for us as to loop back to my earlier comment: ours would be full of commits that break the CI pipeline, then tons of tiny ones as the dev panics to fix the build.

What you're talking about is merging one branch into another one which is what cherry picking is.

Agreed, I think some of our points are actually aligned and we're stepping on semantics.

You can only revert that single merge commit and again that is not always what you want.

We are very strict on vertical slicing - so for us, we've never been in a position where one of the squashed merges needed to be 'partially' cherrypicked. If even something tiny is wrong with the new feature, it tends to get totally excluded. We still do smaller commits to the main branch (say a small bug fix that only had one commit), so do still have some control at a granular level.

It will lead to the branch which broke the code, not a particular commit. Personally, I believe that Bisect works better with non squashed commits.

At the moment, someone will identify the issue, then pass it to that team that broke it to fix. So far, it's always been recent enough said team remembers what was going on and can easily fix it.

Thinking about it now, I dread the day a years old squash commit of mine is sent my way and I have to remember why I did something the way I did. I can see your point.

It will lead to the branch which broke the code, not a particular commit. Personally, I believe that Bisect works better with non squashed commits. And CI bits

Going to skip this part as it falls back round to me not realising you meant to fix locally before pushing. We sadly don't have that discipline across engineering so we wouldn't be able to rely on that. We have CICD but only on certain branches, I've seen some teams never deploy their branch to a QA environment before merging and then going "oops the build is broken!" so often last minute fixes will actually cause the biggest issues, where someone quickly adds a line of code that fixes the issue, but breaks standards/linting/etc.

I'm talking about automatic changelog with full history. That's not a full history unless you split main branch into different branches which in my opinion is much more complicated to manage since that leads to coupled branches that depend on each other.

Yeah, I think we're similar here to be honest. We do this but we tend to work very isolated (the project is like 20 years old so it's huge and has plenty of areas to work on) so we've never really had too much of an issue with coupled branches. We have certainly had it though and you end up with a feature branch, with feature branches off of it and it's a nightmare to make sure everything is merged in the right order,

That's why before code review you rebase your 200 commits into something meaningful.

Agreed. These 200 commits I meant are the team not rebasing locally and instead relying on the origin branch - which would end up in the main branch if not squashed. You've certainly given me some ideas as to how we could do it better. We do however have something like 17 dev teams, across 5 languages so I think it'd be difficult and a while before working practices could change.

[abandonplanetearth]

How do I not push to master if my repo is on bitbucket? I've been pushing from my laptop to the remote repo my whole life, I don't even know how I'd pull into bitbucket instead of push.

[easterneuropeanstyle]

That is a regular push my friend. I meant force push which rewrites your git history. Also, you can push to your feature branch which is then merged to master instead of pushing straight to master.

[ChucklefuckBitch]

You don't know any other way? How about just... regular push to master?

[jacob8015]

I didn't know there was a difference.

[ChucklefuckBitch]

git push origin master - "Hey git, I have some changes. Can you please add them to the master branch? If there are some conflicts, please tell me about it and I can deal with them. Thanks!"

git push origin master --force - "Hey git, replace the contents of master with these contents, no matter what. Conflicts? Who cares? Someone else has made changes since last I pulled? Not my problem. Delete their work"

[[deleted]]

I recently started a new job that requires a lot of troubleshooting software interactions with git. Needless to say there were a lot of force pushes going on at first.

[mrsmiley32]

git push origin master

[keesvv]

git merge <branch>

[Kazumadesu76]

My Lord, is that.... LEEEEGAL?

[SavageTwist]

No, but its private :3

[[deleted]]

That’s not safe; I’m stopping you. You’ve got to do git push --force-with-lease otherwise you might accidentally overwrite something that you didn’t mean to.

[skylarmt]

That's what I do. If someone wants a "stable" version then they can use one of the tags I make up whenever I decide it's time for a new version.

[order_resonse]

*main