Home > Blockchain >  What is the "right" git workflow
What is the "right" git workflow

Time:05-02

I am a longtime Subversion user who has just recently started working on a project where git (GitHub) is being used for source control. There are no SOP's (standard operating procedures) when it comes to source control. I will be using GitHub Github-Desktop. I'm finding myself lost when trying to create a sane workflow to handle simple bug fixes/feature enhancements.

The first few steps are straightforward:

  • Create an issue in github for bug or feature enhancement
  • Create a branch (from main) for issue. Lets call this issue branch
  • Open issue branch in GitHub Desktop (link available in GitHub)

As I am working in my local issue branch, the remote main branch it was created from will likely have been updated by several PR's. Am I right in thinking I run a (higher) risk of merge conflicts if I 'ignore' these updates and open a PR on the main branch as it was when I created my local issue branch?

In GitHub Desktop - I see the option to merge branches. So, is the right thing to do what I have outlined below?

  1. merge remote main into my local issue branch
  2. deal with any merge conflicts
  3. commit changes to local issue branch
  4. push to remote issue branch
  5. PR on remote main from remote issue branch

Is the Squash and Merge a better option here?

Last part of my confusion here... I'm assuming GitHub Desktop doesn't pull from remote automatically? So if I were to merge (or squash and merge) main into my local issue branch in GitHub Desktop - I'd need to switch to main first - and pull. Then switch back to local issue and do the merge with local main?

CodePudding user response:

Am I right in thinking I run a (higher) risk of merge conflicts if I 'ignore' these updates and open a PR on the main branch as it was when I created my local issue branch?

Yes, in general, the longer a feature branch hangs out before merging with main the more likely there will be merge conflicts when you finally get around to it.

I see the option to merge branches. So, is the right thing to do merge main into my local issue branch - deal with any merge conflicts - then open a PR on main from my local issue branch? Or is the Squash and Merge a better option here?

I generally either merge main back into my feature branch or rebase my feature branch onto main. Personaly, I don't squash merge anything, but this is an option.

Last part of my confusion here... I'm assuming GitHub Desktop doesn't pull from remote automatically?

I don't use GitHub Desktop. From the command line, you will do

git checkout feature-branch
git fetch
git merge origin/main

I assume that GitHub Desktop has corresponding menus to perform these actions.

I'd need to switch to main first - and pull. Then switch back to local issue and do the merge with local main?

That is another possibility. I suggest reading about so-called "tracking branches" to understand more about how git fetch and git pull work. My example commands above take advantage of tracking branches to reduce the number of steps needed when switching back and forth between local branches.

CodePudding user response:

From https://docs.github.com/assets/cb-45720/images/help/desktop/fetch-button.png

Then you https://docs.github.com/assets/cb-36791/images/help/desktop/windows-rebase-current-branch.png

And force push (assuming you are the only one working on the branch)

force push

If you had a PR already opened, it will be updated automatically.

  • Related