Git Branching - Sanity check my assumptions on how to action this?
I'll spend some time with Git Branching this week as I still haven't ever done it in a project.
So far I know that I run the below code to create and move onto the branch
and once I'm happy with that, I then commit and push the code into the branch
from there, what am I doing? my assumption is the below...
So I pull any updates into main, I merge feature/add-todo into main, and i then push main to my remote repo (github).
Another thing I'm curious about is what happens if I create new files in the branches in VSCode? do they appear when I'm in feature/add-todo, but vanish if I git checkout back to main? saying if I were to create something like "AddTodo.vue" etc...
39 Replies
you misspelled "pull", by the way
i will tell you what i do at work:
- create a branch like
feature/[ticket-id]/title
- work on the branch
- create a merge request to master
- duplicate the branch to have -staging at the end
- merge to staging
- test staging somewhere
- repeat from "duplicate" until happy
- merge to master
the "duplicate" part prevents gitlab from throwing all the shit from staging into my work branch
and i always delete the branch when merging to stagingthere is a step before commiting to add the changes you made to staging area (index) with
git add so git knows what it needs to commit.
but that's a nitpickyeah, vscode complains if you dont stage any changes
btw the
merge to staging step here
you are merging the upstream main/master branch into staging right
then last step merge to master refers to merging the original feature branch without staging into upstream main/masterno, im merging a duplication of the branch you are working on
if your branch is
feature/123-abc/create-dummy-content, i create a feature/123-abc/create-dummy-content-staging branch
then i merge that -staging branch into staging
after a deployment cycle, i nuke staging and re-create from masterwhat is the
staging branch. is it a branch branched from the latest master/main
oh you just answered my badyeah
the staging branch is where we test the latest changes
usually, it is done in a
dev branch, and staging is a preparation before going to master, but i dont have 2 test serversI'm assuming at a company you usally work on the same repository unlike open source where you would instead create your own fork
yeah
and for myself too
gotcha gotcha
for example, for an opensource project, you just follow what the project tells you to do
but if it is just you or 2-e co-workers, this strategy works really well
and you have the staging branch for you to test your changes together with everybody else's
imagine you make a feature and it breaks someone else's code
by passing into a staging branch and then testing (even if locally), you or someone else can catch the bug and fix it
do you test pr one by one or does staging do multiple pr testing too?
for example if you and your coworker both are working on different features. You submit your pr first then test with
staging it passes but you don't merge it into master yet for some reason
you coworker an hour later makes a different pr for their feature. Do they merge into staging that has your code already?yes
and we can test both features together
got it that makes sense. Thanks
also, duplicating the branch is important
if you don't, and merge to staging then master, you can be pulling unfinished stuff
yeah if staging breaks then you end up pulling the broken changes into feature branch i assume
yup
to reply to the original question, there's many ways to use git branches as part of the development process, and they vary a lot from team to team. But for a single dev project they all simplify to more or less the same because you usually don't have more than one active branch at a time.
one way that is talked about a lot but rarely actually implemented is the GitFlow Workflow, basically you have 5 classes of branches, each dedicated to a point in time for a code bit:
- master is the reference branch (it's also called main or prod)
- then you have dev, develop (can be anithing along that line too) where finished but not yet published stuff goes,
- feature branches where you create new stuff
- fix or hotfix branches where you ... fix stuff.
- and finally realise branches to prepare realises
the gitflow workflow dictates which branch can be pull from where and onto which it can be merged (look up a diagram it'll be easier to understand)
but most of the time the gitflow workflow is not respected to the letter or it's adapted to suite the needs of the business
at my last place we didn't have a dev branch, only prod, feature and realise. we pulled from prod, made PR to realise that were merged when needed/ready then realise was merged onto prod
basically there's a way to do it per project
and not all ways work for all team size or project stuctures
as for the files "appearing" when checking in, yes, that's what happens, you could have just tried it yourself
git tracks changes, additions and deletions are changes so they are tracked (nothing would work otherwise)
holy shit lads, I forgot I even posted this
give me an hour to read
quick one - I did some testing and when I merged my branch into main, it didn't require a commit, is that normal?
wait, so you create git checkout -b feature/123/create-dummy, then you git checkout -b feature/123/create-dummy-staging straight away? so you write your code into staging and if happy, merge that into feature/123/create-dummy, and then if THAT works, you can do a merge request (this is a github only thing right? i dont see this on git) to push that into main (or master)
close, but no, that's not what i do
That's a fast forward merge, if there is only new commits on one side since the branches diverted it's possible to simply move them over like. In those cases doing a merge or a rebase has the same effect. If you don't want that you can use
--no-ff which will disable the fast forwarding and force the creation of a merge commit
(you can also merge more than 2 branches, there's rarely a need for that... But a commit can have any number of parent (normal commits have one, merge commits usually have 2))all my work is in
feature/123/dummy
i created it from master
then, i create feature/123/dummy-staging, and merge it to staging
if you test and there's bugs, you fix them and create the branch to merge again
otherwise, i just merge a pull request to masteroh you're losing me on "merge it to staging", what do you mean by staging sorry, I may be thinking of the wrong thing
we use a staging branch to deploy to the staging server, so we can test it on something other than my machine
ah ok
which I won't have solo, so it's main, main branch, then back to main
if it is a big enough project, you should
so by default mine have main branch, so would I branch off that to create say.... staging, so I have main/staging, and then I'd branch off staging to create and test? and if it works, merge to staging, and if all good, merge to main?
No, stagging is only a merge target
You never merge staging on anything
It's just a branch that has CI/CD pipelines plugged on it so it deploys to a server when you push commits to it. But you never commit directly to it or from it.
You can forget about it entirely and it would not change much
It can also be called test or preprod
ah ok
thanks
But again, every team uses git differently
Some don't use merge ever, they only rebase
Some do both
Some use squash merges
Most use a colorful mix of everything
I remember when I used to talk to db engineers in a previous job and a good 90% of them pushed everything straight to prod, no test branching
i mean the db engineer customers, not the ones at my job
anyway thanks peoples! I'ma go try build something quick before bed
Most people have horrible work habits, and the longer they stay at the same job the worse it gets
some do cherry pick from the stuff thrown from the dev branch into the staging branch to get it to master, without squashing commits
that's absolutely not me and i was scared when i heard that
I did that a few times...
of all the cursed stuff i do with code, i would never do that
But usually I cherry picked from the history
But I think I had to frankstein a branch together from several changes coming from multiple branches
Knowing how to navigate and manipulate the history is a real super power
in this case, the dude pushed to staging and deleted his branch intentionally
then he had to grab the changes back and fashion some franken branch
BTW CDL, look into interactive rebase if you never tried it
It's awesome
currently, all i use rebase for is to
git pull -o rebase -s theirs origin master
i don't remember the exact command, but yes, it does exactly what you think it does
including the history
i do hate i need to do a million git rebase --continue but meh