git branching and basic process for a new dev-CodePudding

I'm setting up a new dev pc and when I cloned our project using the url from the azure devops site, I realized that I was on the master branch instead of the one where I work on. The only thing in master is the initial commit when the project was created. We do all our work on and do our pushes to the dev branch.

When cloning an existing repo, should you start with the branch you work on, or start with master and then checkout the other branch, followed with a pull? What's the "correct" way to get a new environment up in a similar situation? I just don't want to miss a step that I'm not aware of.

For branches, here's what I found:

git branch shows me just:

* master

git branch -all

    remotes/origin/HEAD -> origin/master 
    remotes/origin/dev
    remotes/origin/master
    remotes/origin/somefeature

and git status shows: your branch is up to date with origin/master

I was thinking about deleting the repo and starting over and cloning the dev branch instead, but I'm not sure if that's what you should do. I'd like to know what someone with more git experience would do here.

CodePudding user response：

Assuming there is only a single remote repository:

When cloning a repo, the default branch is whatever HEAD is set to. Usually, this is master/main or whatever the 'default' branch is.

You can use git checkout -b <local_branch_name> <remote_branch_name> to create and switch to a local branch that starts at the head of the remote branch and also tracks that remote branch (aka pushing will push to that remote branch).

In your case, assuming that what you said is actually correct (all of your developers do all work on the same dev branch?), you can do git checkout -b dev origin/dev to create a local branch called 'dev' that tracks the remote dev branch

CodePudding user response：

If I were an admin of your repo, I would change the default branch in Azure Devops to dev. This way all fresh clones would initially have dev checked out instead of master. It doesn't really matter that much- to answer your question there isn't a correct way, but setting dev to the default saves everyone from having to checkout the dev branch (which is simply: git switch dev) before they begin working.

Additional thought: You mentioned the only commit on master is an initial commit. Do you intend to do anything else with that branch? If no, I would just delete master to avoid confusion. If you wish to keep it around, one common use for it would be for master to represent production code. So when you have hardened your dev branch, after you release it to production, merge dev into master. That way if you have to do a hotfix to production you could branch off of master instead of dev to work on the fix. Just make sure to merge master with the new hotfix in it back into dev when you're done. Note though, you could also just tag releases to production and avoid the master branch altogether. Then hotfixes would need to branch off of the latest tag instead of master. Entirely up to you...