Confused trying to merge branches


I am new to using Git and I currently have the master branch and a second branch I’ve called “Development”.

I’m currently working on the Development branch.

~ R_projects\Default_Dashboard>git branch
* Development

I’m trying to “push” all the changes and files from the Development to the master in order to update master and continue with the Development.

I looked up the cheat sheet and what made the most sense was:

git merge master

Which now says Already up to date but when I change to master in my IDE (RStudio) the “old” stuff is still on master, but when I change to Development the files re-appear. Now I’m afraid to “play” around and lose the work I’ve done…

I know this should be quite straight forward, but honestly I got quite confused with how git works. Pull you are uploading changes and push you are downloading… (guess pull from your computer to cloud and vice-versa)

I read about the use of:

git merge --squase feature 


git merge-base main feature

Any how, now I’m afraid to tinker with it and screw up my work.
Any insight please?

All I’m trying is to clearly understand how to simply have two branches the master and my development. Use the development for dev and “upload” to master when I reach my desired mile-stones.

I thought I had figured it out but, obviously I’m overseeing something crucial.

Thank you for your time.

This is almost what you need. :slightly_smiling_face: What git merge BRANCH does is to merge BRANCH into the current branch. So in your case you’ve been trying to merge master into Development, and apparently all those commits were already in Development.

So if you want to merge Development into master instead, first switch to the master branch:

git checkout master

And then merge Development:

git merge Development

One more clarification: “Push” is a separate concept, that refers to sending your new commits to somewhere else (e.g. a repository on GitHub).

Good luck!

1 Like

It worked! Thank you!

How can I give you a virtual hug? :hugs:

Thanks for the clarification, that makes more sense!

If I want to keep a copy online on the GitHub repository, then I have to always “Push” after commits correct? By pushing I’m “saving” the commit to the online repo right?

One more clarification: “Push” is a separate concept, that refers to sending your new commits to somewhere else (e.g. a repository on GitHub).

If I keep using my Development branch making regular commits and “pushes”, I will be keeping the GitHub repo up to date and if I want to go back I can “Pull” to get my last commit for given Development branch.

Larger milestones I merge the Development branch to the Main branch (and push this merge to GitHub repo) that way I have several layers where my code is being saved.

Is this the proper way to use GitHub?

Then obviously by having this structure the scalability of the code increases since you can have many hands on the same project.

I’m used to R in which projects are locally saved and I’m trying GitHub for “real” for the first time :slight_smile:

1 Like

Thank you! :smile_cat:

Yes. The commit as such is complete when it’s saved to your local repository (which is a full Git repository by itself), pushing is what copies it to your GitHub repository. Git - Working with Remotes might be helpful with understanding the connection.

The first part is correct, the second part is not. Pull is a combination of two operations: Fetch, which retrieves new commits and other updates from a remote repository, and merging a certain fetched branch into your current branch. Checkout (and maybe reset) is what you need to go back to a previous commit.

There are different ways to handle branching. Part of it depends on the size of your project (especially how many things are going on in parallel), how you handle releases (if any), and things like that, and part of it is taste. Using topic branches is pretty much always a good idea, if you need something more complex depends. Git - Branching Workflows gives a good overview of common strategies.

The links above are from the Git - Book, I highly recommend reading at least chapters 2 and 3 in full. :slightly_smiling_face:

1 Like