So another project I’ve been working on where git was being used for a repo, but like every other time I’ve used it with multiple people it didn;t do what it says on the tin, and people were overwriting patches that shouldn’t. So can I suggest some tutorials for Dumb Patchers, which goes from how to setup a git in the first place, and through how to work on one as part of a team, how to merge branches, what to look out for and what not to do.
Many of us work alone mostly, so its not necessarily an issue, until you have a group project. So some rules, or suggestions for work flows, how to spearate patches, have multiple documents etc I think would be useful, especially as some libraries are becoming quite large and people should ideally be adding to them as they go.
I think you are speaking about merging patches that have been changed by several people at the same time. This issue is addressed by this tool:
That does sound useful, but a git for v4 would be useful anyway, as what sounds like a simple clear tool for coders, is a weird obstacle course for people outisde of the creed, or at least it seem pretty wierd to me! Maybe its just me thats the dummie, who knows!
@catweasel have you tried https://desktop.github.com/ it made it much clearer and easier for me.
Pairs really well with visual studio code as a text editor https://code.visualstudio.com/
We use Gitextensions and avoid using branches and all the bells and whistles. Just commit, push and merge.
Here an example of our workflow with many ppl
Very smooth collaborative workflow with almost no conflicts.
Thing is, when working with Git with multiple people, its all about communication. When you don’t set rules like : Who does what? which patch/code is owned by who? Stuff happens like you describe. We talk about stuff like that, several times a day and do updates depending on the progress of the project.
Git isn’t the problem, only lack of communication creates problems.
Once you are clear about what your concern (patch) of the project is, you can inspect the changes in Gitextension before pushing them. If there is something in the changes which should not be changed by you, just rightclick and “revert change”.
Gamma/VL will make this a bit more complicated but i think i’d split the tasks into libs /VL documents for each team member, and one member gets the right to pull it all together. we will see.
Good summary, communication and gitextensions is definitely the basis of a delightful life with git.
some additional info regarding gitextensions/git. i find it a bit painful to install gitextensions with separate installation for git and kdiff. something which might be confusing the first time.
and there are quite a few settings to tick, to get it to work. one thing which seems important (since it caused some weird errors in the past) is this window
this is the default setting in the screenshot but i always choose “Checkout as is - commit as is” to make sure git isn’t altering the code.
Whats your experience ? Important or not ?
it is recommended to leave the default there. the feeling that git will “alter the code” isn’t something you need to pay much attention to. it does this millions of times every minute, no worries there.
it is rather problematic, if you think about it, because you will then get linux file endings locally if you check out repos that use the default setting.
we also used “as-is” in the beginning, but we now switched back to the default, because of these kind of problems.
we had broken XML files aka v4p due to this, but this is years ago.
would any of these tutorials be helpful or would you say the git side is clear, it is really mostly about .vl documents specifically?
Also these are great references for recommended practices on:
Branching:
Commit Messages:
- https://github.com/erlang/otp/wiki/writing-good-commit-messages
- https://medium.com/better-programming/how-to-write-good-commit-messages-and-why-is-it-important-18ac406ce33a
Of course nothing is written in stone, take from these only what makes sense for your team and project.
@joreg I would still say a video for dummies would be good, given that nugets need them, and you I guess would like people to contribute to VL. A simple how to get started and how to make a nuget, and how to add someones update to your git, ie what to look for when you do it would be good. All the git tutorials are made by/for programmers, and if you are a lone patcher, then “take from these only what makes sense for your team and project.” isn’t a helpful suggestion ;)
I’d say define a best practice for patchers, demo it, and then maybe we will all have a similar method of working.
@catweasel this has not been forgotten and some documentation has alreade been added as stated here.
@tonfilm also went over good practices here.
To add to that I recently came across this way of doing things and I am enjoying it a lot. The branching model is well known in the software industry and there are tools which support it (Bitbucket supports it by default, so does Github and Git for Windows so if you have Git and Windows you can already use it).
I am starting to use on my own VL and work repos and things remain very clean and easy to make sense of. Also it automates all the branching, merging, deleting old branches and naming things properly which is great, less chance for human error.
I essense you have 2 main branches:
- main or master : for releases only
- develop: for internal dev, can be used for prerelease, should remain stable at all times
and then you have some other additional branch types:
- feature/XX: individual features dev. Should branch off develop and merge back to develop
- release/YY: individual release branch, prepping the code for a release. Branchess off develop, merges into main/master. Must be tagged with a version number
You can also use hotfix branches which I rarely use.
The strategy in general is documented nicely here: https://nvie.com/posts/a-successful-git-branching-model/ (as seen in my previous post)
This of course is a preference of mine and your project’s demands could find this is too much to bear with, or too little. There is just no golden way to do things right on git.
what I read recently, is that git-flow is a tiny bit over-engineered and developers tend to use a simpler version of it nowadays. especially if you don’t develop at an enterprise level. it is just hard to get everyone on board because git-flow is always the top search result when searching for anything regarding this topic.
for example:
it basically gets rid of the develop branch, you just use main as the working branch and create branches for each major preview/release and a branch for bigger features that involve fundamental changes.
we internally only work on preview branches and almost never on main/develop. release branches usually only contain one commit that changes the version from preview to release.
Adding yet more to this endless topic, a few tips that may have already been covered elsewhere but could still be useful can be found in the “General workflow” section of the Kairos developer manual.
You can ignore all of the git-flow related information before and after that section if it doesn’t suit your needs.
Cheers.