branching-model | Semantic branching model | User Interface library

I read a lot lately about different branching models and always ended up with Vincent Driessen's approach as the best setup for my development team.

One thing which bothers me is the problem when different versions deployed at different customers should get hotfixes. In this model each hotfix should be tagged and merged into master.

But this could imply the timelime on master gets messed up as the one hotfix would be merged on master after a newer version was tagged...?

I have two main branches: master and develop.

My usual workflow on a new feature is:

1. Create a new branch from develop: git checkout -b develop
2. Code and test the feature
3. Commit the changes: git commit -a -m ""
4. Change back to develop: git checkout develop
5. Merge the feature back into develop: git merge --no-ff
6. Delete the branch: git branch -d
7. Push develop to remote: git push origin develop

Now I need to work on a new feature that requires the current feature. My new workflow would be:

1. Create a new branch from develop: git checkout -b develop
2. Code and test the feature
3. Commit the changes: git commit -a -m ""
4. QA is currently validating
5. Create a new branch from myfeature: git checkout -b
6. Start coding newfeature
7. QA is done validating, commit current code: git commit -a -m ""
8. Change back to develop: git checkout develop
9. Merge the feature back into develop: git merge --no-ff
10. Delete the branch: git branch -d
11. Push develop to remote: git push origin develop
12. Change back to newfeature: git checkout newfeature
13. Finish coding newfeature
14. Commit the changes: git commit -a -m ""
15. Change back to develop: git checkout develop
16. Merge the feature back into develop: git merge --no-ff
17. Delete the branch: git branch -d
18. Push develop to remote: git push origin develop

Is this a proper workflow? Is there any repercussions to deleting the branch in step 10 (i.e. does it orphan newfeature?)?

The original guidelines were from Vincent Driessen's A successful Git branching model. I also read Create a branch in Git from another branch, but it doesn't really get into deleting the branch that spawned the new branch.

I am using Git Flow, "A successful Git branching model":
https://nvie.com/posts/a-successful-git-branching-model/

but I do not fully understand it, so I am asking your help.

In our project we are using gitlab and there are 2 branches from the project which is the master and develop.

I was told to branch out from the develop branch so heres what I did:

1. First is that I clone the remote repository, the default branch is master
2. Second I branch off from develop branch using the command - git checkout -b develop origin/develop
3. Now in my local I have two branches master and develop
4. I have a question when creating a feature branch, is it only locally? like using the command git branch -b feature_branch, is this process correct ?
5. Now if the above process is correct, and I have my changes on the feature branch should I merge it into the develop branch? is that right?
6. Now If I want to push my local changes, should I push it to the remote develop branch? or on the master branch?
7. If I pull changes from my team, should I pull it from the remote master branch? or in the remote develop branch?

Can anyone give a clarification to this, if you can give right commands, I'll appreciate that also, thank you. or a step by step process.

I'm using GitFlow in my git repository, so I have a master, develop and (temporary) release branch.

Workflow

1. I create a new branch from develop (e.g. fix/fix-the-bug)
2. I squash my fix into meaningful commits
3. I merge my fix/fix-the-bug branch into develop
4. Once I've got enough branches merged, I create a (temporary) release/x.y.z branch from develop
5. I version-bump my scripts in the release/x.y.z branch and tag that commit
6. When I want to merge release/x.y.z into master, I get merge conflicts. It seems like master does not understand that commits are already present in master
7. release/x.y.z branch gets merged into develop
8. I delete release/x.y.z

Few things to notice, not sure if they are all correct:

• I squash my commits into one commit when merging into master
• There should be a git tag on master indicating the version number, but not sure if that would work correctly if I squash the commits.

Question

I'm now wondering:

• how I can fix my repo, since I don't think I should be getting those conflicts.
• Any further advice on the workflow (e.g. in which part I could perform the squash best) would be welcome.

I'm looking for best practices on how to deal with issues, boards and merge requests on Gitlab.

This is my board on Gitlab

The merge request linked to issue #3 (with label "Doing") was merged on the develop branch (I'm following git-flow). I'd like to mark this issue as done because we're finished working on it, however it's not merged on master yet. Should I close the issue? If not, is there a convention on how I can mark it as "done" in the sense that we're finished our work on it?

I read this famous article.

I understand how bob and clair can sync with origin, but I don't understand the connection between alice and bob and david and clair.

The article says:

[...]But besides the centralized push-pull relationships, each developer may also pull changes from other peers to form sub teams.

Technically, this means nothing more than that Alice has defined a Git remote, named bob, pointing to Bob’s repository, and vice versa.

Do I understand it correctly that two teams (alice and david) sync from origin but created their own git server endpoint to make it accessible to bob and clair?

Giving a go at the Gitflow workflow and noticed something odd on Githubs Network tab.

On the remote I have 3 branches: master, develop and app (ignore this). On the local I have same branches, plus a feature branch: feature-1. At this point, my Network tab looked like this:

I performed the following git commands on the local after adding a single file to feature-1:

While trying to simplify :

while having the requirements:

1. Running Parallel masters
2. Running Feature branches, that might / might not be released
3. Handling Hot Fixes
4. Handling Vulnerability Fixes

Looking at A successful Git branching model

Can we do away with release branch as long as we tag the master branch after every release?

Can we also do away with develop branch?

Release branch can be branched off master at the start of the new sprint and devs can create their features branches off of that. If a hotfix merge to master (current release) happens in the middle of a sprint, the hotfix can also be merged to the current release branch at the same time as feature-branch-hotfix-

Code from feature/develop branches should be deployed to DEV environment

Feature branches by themselves should not be deployed at all.

Prefer my strategy in which a merge request from release-* to master kicks off the jenkins pipeline build via webhook, that will auto merge release-* to master, build from master and tag the merge commit.

Im currently working on a project for school where I need to use git & github. I'm fairly new to git but know the basic commands for committing, branching and pushing.

Now my question is, how can I create the following branch structure :

master | ---- branch_1 | ---- subbranch_1 ---- subbranch 2

I've already tried a couple of things : first I followed a guide which you can find here but all my branches where on the same hierarchical order. I also exactly followedthis article but here again my branches were on the same level.

Please can anyone help me with this. Thank you in advance.