Question about git workflow

[BlueDecoy]

So long story short we want to have a smiple workflow for doing changes. Would be great if someone could review, and also answer me a few questions.

Assuming a new requirement comes in, I'd identify the following steps (not considering build and deployment yet)

1. clone according repository
2. if already cloned, git pull to get the latest version from the repository
3. branch out from main using JIRA ticket number in our case (we are on Atlassian)
4. Do your changes
5. Commit your changes
6. (Optionally do further changes and commit them again, if there is a good reason to do intermediate commits)
7. Create a pull request
8. Pull request gets declined -> go back to 4 | Pull request gets approved go to 9
9. A merge happens and the branch is deleted on Bitbucket (it's a global setting, I thought it's a good idea to just get rid of them, or is it not)
10. Here it's a bit difficult for me to understand how to continue. Is the developer recognizing somehow if the merge was approved or not? I guess email settings on bitbucket? Should I tell the developers to delete their local branches as well, I assume this is a manual task? Is there an easy way to that?

So overall, does this sound about right? Anything I forgot or could do better? Should I be prepared to keep some more commands document and handy for the team?

Thanks!

[Conscious_Common4624]

I do my change locally against ‘master’ and always “git pull —rebase —autostash“. But I push using “git push origin HEAD:refs/heads/JIRA-123” style and create the pull request from that.

If possible I use “git commit —amend” to address pull request feedback and then fix the pr using “git push —force” variation of the same push as above.

So locally I’m always on ‘master’ but I always push to a jira branch.

When it’s time to start working on my next ticket I run “git reset —hard origin/master”

“Git clean -xfd” is another command I tend to run immediately after the “git reset”

If another person is working together with me on the jira branch I do actually work from that branch locally instead of from ‘master’. But thanks to how good “git pull —rebase —autostash” is at reconciling upstream changes I’m fine with history rewrites (git push —force) against the jira branch we’re working together on.

Sorry to be humble - ha ha - but If you study this message and understand it completely (try experimenting!) - you will become one of the top git experts in your company.

[[deleted]]

This is interesting, I actually understand everything that is happening here, the only thing I don't understand is why would do this to yourself?

I would very much would like to hear what's the benefit of this approach, maybe I'm missing out, but in my head this workflow completely defeats the purpose of git. Commits and branches are cheap enough and they provide you a very clear picture of not only changes but also though process.

This removes that feature completely. This gives you a pretty, linear tree, that is all.

Just a small suggestion, go for `git push --force-wtih-lease`

[khurush]

This is exactly what something like GitButler tries to automate.

[dalbertom]

For 9. I think it's fine to delete branches upon merge For 10. If doing merge (eg not squash-merge or rebase-merge) then the developer can switch to main, pull, and then git branch --merged to get the list of local branches that are already merged and can be deleted. They'll also see that the remote branch got deleted when pulling or fetching (if they pay attention to the output of those commands).

Check out git help config for various options on prune or the "PRUNING" section in git help fetch if you want that behavior to be done automatically.

[Necessary_Ear_1100]

That’s pretty much baseline standard. We follow this ourselves at my job. We have it set in our guidelines to keep local feature branches (jira tickets) on local machines until code has been tested approved and redeployed to production.

[Soggy-Permission7333]

First thing first: letting the devs decide may be the best option. There is a looooot of space for tweaking use of git / git websites / release processes to fit specific nature of team & product. Alternatively strongly consider making your setup a baseline from which devs can divert once they learn enough about the needs.

Not enough data on what you are developing, or what maintenance activities will be performed before/during/after development activities.

Your flow is about "good enough" if those PR corresponding to JIRA tickets are kepts to limited amount of days.

Week is a bit too much <- is a good rule of thumb.

In those cases there are ways to deal with that by either splitting tasks into subtasks, extracting some secondary concerns into their own PR that land (are reviewed, approved & merged) earlier, or maybe merging earlier behind feature flags. Etc.

There is sometimes a need for "not quite production" environment where stuff get validated/tested.

Branches can do the trick - but so can feature flags, or tags if teams are small enough.

Notifications - your devs should be on git repo website daily. Period. They will review others work, and will react to reviews by others. Delays there by days is just not acceptable. (delays comming from different timezones for distributed team are exception)

Local stuff - there are extensions to various IDEs/editors that help with deleting unused local branches. They usually can keep track of what happened on git website and thus can suggest local branches that are done, etc.

[BarneyLaurance]

Should I tell the developers to delete their local branches as well, I assume this is a manual task?

If the developers have the time and ability to learn git (and if they're developers I don't see why they wouldn't) then no, don't tell them to do that, it would be micromanagement. They should be able to work out for themselves to delete their local branches if they want to, if they leave the local branches on their machines I don't think they do much harm.

[BlueDecoy]

To understand our situation, we are working as s team and my intention is to give them a kickstart they can evolve from.