Hey DevRant, this is my first time working collaboratively on a project with Git and I'd like to know what's the best strategy to adopt.

Is it that every member has their own branch on origin that they push to, then we meet and plan out merges when it's time to release? Or does everyone just push to master, but stash or commit their local changes before they pull?

It's a Greenfield project, with just a bare repository on the central server. It's an MVC app where I've decided to do the View & Controller portions and the other person is doing Models and data services layers.

gitflow is the way to go.

https://atlassian.com/git/...

Good god, don't use Gitflow if you don't absolutely have to. It's overengineered for the majority of projects.

@nitwhiz this looks great! Thabks.
@VaderNT although this particular project is a small one, most of what we work on will be large info systems. This might be a good chance to try out Git Workflow and see what's up.

@VaderNT dafuq. As soon as there are more than 2 people involved and it's about the implementation of actual features, it's the best workflow to go by.

> Is it that every member has their own branch on origin that they push to, then we meet and plan out merges when it's time to release?

That sounds like everyone has a long-lived branch, which is generally not a good idea: The more two branches diverge, the harder it is to merge them, which means having "fun" resolving merge conflicts. I recommend to keep branches focused ("feature branches") and short-lived.

@nitwhiz if you just need to collaborate, you can get by with just feature branches.

Gitflow adds a lot of complexity concerning releases. Complexity that you may need if you support multiple live releases, which is... not most projects. And even then, there are simpler ways to do it, see https://endoflineblog.com/follow-up...

The whole idea around Git is that you don't have to choose just one way. Devs can have their own servers to push to and you can merge from those servers into origin or to your local branch which you can push to origin

Although I will say that most will rebase onto the latest commits that their target branch has to avoid unnecessary merge commits.

I adhere to @VaderNT opinion.

will the code be hosted at gitlab?

we used to do gitflow in the past, it worked but it was a bit of a pain in the ass.

But at some point gitlab added the ability to create merge requests from issues. This means that the workflow is this:

1) Someone lets the dev team know that some shit is broken
2) Somebody in the dev team creates the issue "shit is broken", let's assume the autogen id is 34, and that issue is assigned to a specific dev.
3) That specific dev goes into said issue and clicks that magic "Create merge request". This button creates a branch with the name #34-shit-is-broken from master and a merge request referencing that branch, with a status set to WIP (work in progress).
4) The dev runs git fetch, then git checkout #34... and starts to work on it
5) When the changes are done, the dev pushes the changes, then goes to the issue on gitlab and marks the issue as not in WIP anymore.
6) The leader/dev merges that into master or not if it sucks.

Switching from gitflow to this was definitely a gain for us. Aside from easy, it is secure too if you want it to be because you can restrict who can merge MRs and push to master.

This "flow" is not fork based. Everyone pushes to the main repo, aka origin. Gitflow is fork based, everyone creates their own fork and do inter project merge requests.

Fork based flows are more appropriate for when you don't know the devs I think.

@erandria According to the atlassian link up top, gitflow isn't fork-based. It's definitely branch-based.

@Drewtato wow, what a big twat I am... I take that back then...

@VaderNT i give you that, you are right.
But the whole feature-branch thing is a good, as you said, too.

@erandria you don't fork the whole fucken repo for changes, you make feature branches, where a specific set of changes is made and merged into a develop branch. On release, you merge develop to master, so you only got "final shit" in master.

I see that this is a "suck it and see" kind of situation. Seeing that Gitflow and feature branch both provide a good collaborative workflow, I think I'll start off with feature branch (since it's simpler) and move up to Gitflow if we realize we need some more organization.

Thanks for the feedback, everyone!