Trying To Understand/Determine A Basic Git Workflow

Question

I've been reading this popular document over and over to try and draft my own git workflow.

I think I have got it down, but I am still a little lost. Here is my current understanding...

We have two branches that will always remain active.

• Master: This is where I will push code that will actually be deployed to my production server and be used by my users.
• Development: This will be branched from the master branch. It will include all my new features, bug fixes etc that will be pushed into the next release.

We have multiple topic branches that will be branched from the development branch (I think). Once the topic, example the bug as been fixed, we merge that branch back into the development branch. Some examples:

• Topic Branch 1: feature-ajaxify-shoping-cart
• Topic Branch 2: bugfix-navbar-font-overlapping

Prepare The Release

• We have 1 release branch at a time that will be branched from the feature branch.
• Now we pull/merge all the features, bug fixes etc we want to push into the next release.
• We can leave some features we have been working on that wont be in the next release (I think).

Creating The Release

• Once satisfied with the releases, we can then merge that release branch into the master branch, and name the commit something like 'v1.2.0'.
• We also want to tag that commit with 'v1.2.0' so we can easily go back in time and see releases.

Side notes I have learned

The master branch is always nice and clean, and only contains commits that are releases (I think thats why we have a separate release branch, right?).

Please let me know where I have messed up or misinterpreted something etc. Thanks!

Emmer

What you have explained is correct, but looks like you have just focused on branch only though git have much more to offer. You may refer this answer to cover few more cases #40892985 – Pelisse

Answer 1

Your summary is accurate: you can find illustrated in this cheatsheet.

Be aware though that in order to test your feature with the other ones, you have to merge them to develop (git flow feature finish MYFEATURE).
There is another workflow (the Git workflow) which allows for a better feature promotion (to develop, then to release)

The difference is:

• with git flow:
  • multiple feature branches are merged in devel (where they discover if they can work together or not)
  • then release is created from devel (at which point removing features becomes complex) before being merged back to devel (and master).
• with gitworkflow:
  • feature branches are merged to a "public" "alpha" branch, which is reset after each release (meaning, deleted/recreated on top of the new release)
  • then a subset of those same feature branches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top of master after each new release.
  • then a sub-subset of feature branches are merged to master, to prepare the next release.

The "public" and "next" (aka 'devel') branches are never merged to master. They are "transient" or "ephemeral", always deleted/recreated.

Only feature branches are merged to the lifecycle branches (public, next, master). That means at any time you can chose to drop a feature between one stage of the development lifecycle and the next.

Imputable

Good to hear. So this method is called 'git flow'? I didnt really understand the link you posted, but I will try and make sense of it.I can do everything manually instead of using that git tool right? – Emmer

@Emmer All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/…. – Imputable

@Emmer The key passage: " in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts. Gitworkflow allows both goals to be achieved without sacrificing one for the other." – Imputable

Ok I understand the problem with gitflow (pollution of topic branches that may not be ready to go in the next release, so a lot of back and fourth pollution). But I still don't see how gitworkflow solves this. Instead of merging the topic branch into development, we merge it into next. Then what? All I see is the development branch changing the name to next lol. – Emmer

@Emmer The key difference is gitworkflow is using a transient branch to try and merge features branches, before merging (again) a selected subset of those feature branch to the actual release, as part of the next release. – Imputable

@Emmer the first merges are done in the ephemeral branch next (which is never merged to master: key difference with gitflow). The second merge (of the ones deemed compatible, for the next release) are done in master, to prepare the next release. – Imputable

So the transistent branch as you state would be the next branch? Say I'm done working on my topic/feature branch, I merge that into the next branch. My question now is where does it go after the next branch? And what if I have to rework on that topic, what's the process there? Really sorry having a hard time following, thank you for taking the time to help however! – Emmer

@Emmer on the rework side, That is what github.com/rocketraman/gitworkflow#make-your-topics-great describes – Imputable

@Emmer this is illustrated in hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb: "Now that the topic has graduated to next, it can be part of a beta, or acceptance release. So every topic on next can now undergo a second round of stabilization, which is exactly the purpose of a beta release / acceptance testing environment. However, note that with gitworkflow, we still have not committed (no pun intended!) to having this topic as part of our next release to production — it still has not been merged to master." – Imputable

@Emmer "What if topic branches continue to evolve with new commits after merging and testing on next? The branch is simply merged to next again, as is necessary." – Imputable

@Emmer "And lastly, once a topic is judged stable enough to release, the topic graduates again and is merged to master (or perhaps maint), again with --no-ff to preserve the complete history of the topic branch." – Imputable

@Emmer This is very different from gitflow, where the lifecycle branches are merged (feature to dev to master). Here a "topic" (feature branch) is merged as many time as necessary to an ephemeral branch pu or next (one which is recreated for each new release). And then, once ready, merged to master. pu or next are never merged to master. – Imputable

I think I got it now. We start off merging our feature1 branch into next branch. We work on feature 2 branch, then we merge that into next branch. We realise we need to update feature 1 with some additional functionality, so we go back to our feature1 branch, make the changes, then merge that branch back into next? Now we are happy with both feature1 and feature 2, so we finally push the next branch to master, then safely delete the branch. – Emmer

Did some more learning. We can also rebase the merge commits so that we dont have a long list of merges, just a list of actual commits that were undertaken to provide that functionality? – Emmer

@Emmer Wait..."so we finally push the next branch to master"? No: that is the all point of that workflow: you never merge an ephemeral branch to master: you only merge the feature/topic branches you are happy with to master. And you reset next to master in order to go on integrating other feature branches. – Imputable

@Emmer That is what I meant by "pu or next are never merged to master.". – Imputable

Ah huh! So next, like you said, is just there for us to test a combination of features. and see if they work well together / any conflicts. It makes a lot of sense now thank you so much! – Emmer

You got it. The pu branch is alpha (does it compile together), the next branch is beta (selected features to try together for the next release) – Imputable

@Emmer I have summarized our exchange in those comments in the answer. Please tell me if that summary makes sense. – Imputable

Yes your answer is spot on, I understand everything. Just one side question in regard to the merging of features into the master branch. Would the master branch commit history just consist of, for example, 'Added new feature 1', 'fixed bug1', 'updated customer controller'. Then at the top of those commits, a release. So its feature, feature feature, release, feature feature feature, release. If that makes sense. – Emmer

@Emmer Yes, that is the idea. You can see that idea in action in the Git repo itself: github.com/git/git – Imputable

Great discussion guys, thanks for the clarifications. I am missing something regarding next. Next could be an integration branch for 3 feature branches, but then we choose to merge only 2 to master. Master ends being different from what was tested on next, maybe feature 1 and 2 don't work as intended without feature 3 that was in next. Am I missing something? – Episcopate

@Episcopate "Master ends being different from what was tested on next": if that is a problem, delete the branch next first (since it is a transient branch), merge the feature branches you intent to go to production (you intent to merge to master eventually), re-validate your tests, then merge those same branches to master. Destroy next (again), reset it to the new master, and the next integration/validation cycle begins anew. – Imputable

Do you mean that if feature 3 was not planned to continue, then I simply delete next and I only merge feature 1 and 2 to a new clean next to test them alone before I merge them finally into master? I guess that makes sense...if feature 3 was not going to make it it is not needed in next so I can re-create a next branch that has only the stuff I need. – Episcopate

@Episcopate Yes, that would be the idea. The main point is not to merge integrations branches like dev to next, or next to master, but to merge only feature branches to said integration branches. – Imputable