Merge locally or remotely?

Get Help Git
#1

Hi,

Sorry but I need to ask a question. I hope somebody here with actual experience could give me a hint :slight_smile:

When you’re working with a Git repo both locally and also remotely (GitHub), do you normally merge feature branches locally or remotely? If you do so remotely, then I should delete the local branch altogether? If it’s locally, then I should never create the remote branch?

I’d love if someone could clarify.

Right now my situation is:

  1. I created a main branch locally and I connected a new GitHub repo (via https).
  2. Then I created a feature branch locally and started working on it. After working on some changes, I committed and pushed the branch (and set upstream to the respective origin remote-tracking branch).
  3. Once I am satisfied with this branch working as I expect it, I commited and pushed again.
  4. Now, I’ve read that it’s recommended that branches be deleted as soon as you merge them, that is: not to keep them around.
  5. For that reason, I don’t know what should I do now, and I don’t find any specific explanation about it (in CodeCademy or Google in general, maybe I didn’t know how to search):
  • should I make a compare and pull request with a merge in GitHub and delete the branch? If so, what do I do with my local feature branch?
  • should I do the merge locally to my local main? If so, what do I do with my remote feature branch?

I hope my doubt is clear and hopefully and hopefully someone kind enough could give me a hint as to what I am missing?
Thanks in advance!! :tada:

#2

I don’t there is one fixed answer to this question, it will vary between projects and people you will collaborate with

Speaking from the limited experience I have, sometimes people worked in there own branch, and kept this branch around pretty much forever. Other projects a branch feat_x or feat_y would be created, once the feature was done, the branch was indeed deleted

There is usually a master/main branch, which runs in production. Then again, depending on the project we might have a staging branch (for staging server) and/or a dev branch (which ran on the dev server).

While working on a feature (in your own branch), you can just push to the remote of that branch. But I quite regular pull the branch (master, staging or dev) I want to merge with in the end. So you don’t end up with a massive amount of merge conflicts (changes other people made on the project)

hope that covers everything?

2 Likes
#3

Thank you for taking your time to answer this! :tada:

Yeah, I get a better understanding from your reply.

The part that - probably due to lack of actual experience - doesn’t totally sink in my half-dizzy brain :slight_smile: is I think because of the fact I am working alone on this miniproject, so sure, there is only a double existence of the same branch, my local branch and the remote, which contain always the same things.

Quite naturally, it’s difficult for me to imagine a real scenario. But I totally get from your answer that it’s better to pull first to avoid the merge conflicts (which I did in my case, even though it’s only me, just to simulate the real thing). I just don’t fully grasp the aftermath of the commit, pull & push part.

I’ve learned from your answer about the staging server concept (which is cool btw!), but what happens after that? My imagination: the staging branch might eventually make a compare & pull request to merge with the main branch? If so, what happens with your local branch, like how do you update your branches locally? Please apologize me if I sound a little dizzy here. :slight_smile:

What I did in my case: I made the compare and pull request on GitHub and merged there, but of course, after doing that, my local main branch and my local feature branch were ‘outdated’(?), so I just fetched and merged the main branch, after which I deleted the feature branch. Is this how it’s normally done?

Once again, thank you so much for your so valuable insight!!

#4

Even working alone, git is still recommended. You can see what changes you made and when. You can roll-back.

If you work with someone else in the same branch, that person does a push, you will have to pull before you can push again (git will say something like: you are behind). Plus, pulling you mean you can resolve any possible merge conflicts.

In Git , commit is the term used for saving changes. Git does not add changes to a commit automatically. You should also give good names to your commit message. So you can read this back later, and roughly an idea of what you have done

push will push to the remote (github, gitlab or bitbucket), now other developers can see what you have done

keeping your changes only local on the machine, allows you to do a rebase for example. Not something I use a lot, but can be useful. (don’t ask :wink: something for later)

On staging, people can test the code and changes. Then when things are ready, can be pushed to the main/master branch, which runs the production server.

you can have a local version of the staging branch, which you should then update/pull. Then depending on the flow, you either: update your own branch with the staging changes, or create a new branch for a new feature/bug fix

Depends on the team and project and what has been agreed. There isn’t one fixed way here

2 Likes
#5

Cool! Everything seems way clearer now. Once again, thank you so much for your really valuable insight!! :tada: :+1: :+1:

2 Likes
#6

If you wanted a little more practice with branching and merging but are uncomfortable with getting involved with a larger project at this time you could have multiple copies of your repo on the same computer.

As an example, say you have set yourself two tasks to complete on an existing project then you could clone your repo to a second directory and create a different branch in each of these directories where you complete your two tasks separately. Then try pushing one to your online repo, move to the second and try pulling the newly updated repo (so you’re up to date, not behind) then add your local changes and consider pushing again.

Taken a few steps further you could create a separate account for this (and even muck around with permissions) but it’s probably better to start simple.

The exact order doesn’t matter and the above is just one simple example (if you have branches then the merge may not even be necessary). Working like this might help you wrap your head around working with branches and separate repos before you’re comfortable working on an existing project. It’ll likely be slower so consider if it’s worthwhile or not.

By and large everything you do locally is fairly safe, it’s the push to the online repo you need to be careful with.

1 Like
#7

Great ideas! Thanks!

I will definitely try that, which is a specific version of a general principle I’ve been applying with most things I’ve been learning so far, by the way, mess them up and around until I break (and fix) them in my computer, ha ha, until I get how they work as reasonably clear as I can.

The idea of having two local versions blew my mind and I think as much as it may be slow, it can be go a long way in helping better understand the process, so I will totally try that.

Again, thank you!

1 Like