0

I have a repository on git, which I am cloning from into a server that compiles and runs it.

Since that server is local on my network, I can further clone the project that is accessible via samba or even open it on my preferable editor and work on it from there, doing the changes I need or anything else.

Here is where things get complicated, I would like to be able to keep the clone I have on my server, synchronized(up to date) with the git repository(which I can't push things to), while retaining the changes I do locally to my server repository.

What is the most common practice if there is one for this specific case or what should be the advised route to follow for this?

If I had to describe the current process I do, it would look something like this:

  1. git reset --hard origin/master
  2. git fetch origin
  3. redo all changes
  4. repeat when new stuff on the origin...

I assume, I would in either case need steps 1 and 2 because if I commit git would complain about changed files not allowing to simple git pull it.

An alternative to the above, I think would be something like:

  1. generate patches
  2. git reset --hard origin/master
  3. git fetch origin
  4. apply patches (could fail here depending on how the files changes, so manually would be easier to identify...)
  5. repeat when new stuff on the origin...

So repeating my question again:

  • What is the most common practice, if there is one, for this specific case or what should be the advised route to follow for this scenario?

I am not an expert in git, I do know how to use part of it, but the above scenario is something new for me.

Guapo
  • 3,446
  • 9
  • 36
  • 63
  • Do you realize that `git reset --hard` throws away all local changes? – Code-Apprentice Mar 25 '17 at 10:14
  • @Code-Apprentice yes I do, at this moment I have a document with all changes that are done to redo all those, which I think is something I shouldn't need, but I am inexperienced with git and do not yet know what would be the correct approach to sort this situation out, so here I am. Which is also why I have steps 3 on my first procedure list and step 4 on the other – Guapo Mar 25 '17 at 10:15
  • I have answered with some suggestions. However, I don't understand what you mean by "all changes that are done to redo all those". Can you elaborate on this? – Code-Apprentice Mar 25 '17 at 10:18
  • @Code-Apprentice well say you have file a.php, and you change 3 methods in it. That means you did changes to that file. Now you need to pull from the origin(you can't push anything to the original repo), it won't work because you have changed files, that were never committed to it, thus you need to clean the project or revert changes. After doing so and pulling the project you would need to apply all the modifications again. – Guapo Mar 25 '17 at 10:21
  • Why do you make changes to a.php without committing them? – Code-Apprentice Mar 25 '17 at 10:22
  • @Code-Apprentice if I commit the changes locally what difference would it make if I can't push the changes to the original repo? I mean the files would still be different and it would still require me to revert/clean it no? – Guapo Mar 25 '17 at 10:23
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/139014/discussion-between-code-apprentice-and-guapo). – Code-Apprentice Mar 25 '17 at 10:23

2 Answers2

2

Why don't you use a branch?

The moment you cloned the repository, you got a local one. You can create branches and use them to version your code locally, without ever pushing to the remote.

Create your own branch based on master

git checkout master
git checkout -b mybranch

Keep commiting your changes to mybranch. Whenever changes appear in the remote repository, update master and merge it into mybranch.

You could also share your work with others if you set up your own remote. Git allows you to work with multiple remote repositories. If you don't have access to the one you used to clone the project, nothing stops you from creating your own one where you do.

toniedzwiedz
  • 17,895
  • 9
  • 86
  • 131
  • Oh, that sounds much more like what I need, how would the merge work in the event of modified files? – Guapo Mar 25 '17 at 10:24
  • @Guapo the changes from `master` would get introduced into your branch. In case the same files got modified, you'd have to resolve some conflicts (a matter of choosing which changes you want to accept, your own, the remote changes, or both). A full explanation would be too long to put in an answer, just follow the links I posted. They lead to chapters of a really nice book on Git. Reading them should make things much clearer. – toniedzwiedz Mar 25 '17 at 10:26
  • Will do thanks for the short resume on what would happen. – Guapo Mar 25 '17 at 10:28
1

First you should follow the instructions from the GitHub help to create a fork. After you do this, you will have a local repo and a personal clone (or fork) on the GitHub servers. The local repo has two "remotes". origin points to your personal GitHub repo. upstream points to the original main repo.

Now when you want to make your own changes, you should create a branch:

$ git checkout -b mybranch master

This command will create the branch and check it out. Now you can use git add and git commit to commit your changes to your local repo.

If you decide you want to submit your changes to the original repo, then you first need to push your branch to your personal GitHub repo:

$ git push origin mybranch

Then log in to your GitHub account and create a Pull Request. Your changes will be reviewed by the maintainers of the original repo. Most likely they will give suggestions of what you need to do to improve your changes before being accepted.

When the original repo is updated, you can pull those changes to your local repo with

$ git checkout master
$ git pull upstream master

You can also update your personal GitHub repo with

$ git push origin master

And you can merge the changes into your own work with

$ git checkout mybranch
$ git merge master

If there are any conflicting changes between the update to the original repo and your own work, then git will tell you. Then you have to manually resolve these conflicts. You can do this directly in any text editor or use one of the many visual tools which are available. See How to resolve merge conflicts in Git? for details.

Community
  • 1
  • 1
Code-Apprentice
  • 81,660
  • 23
  • 145
  • 268
  • Wouldn't that make me fall under the same issue of my second procedure list? As in if the files I have previously modified have drastically changed the stash would fail to implement it back in? – Guapo Mar 25 '17 at 10:19
  • @Guapo Yes, in both of my suggestions, you have the potential for merge conflicts that will need to be resolved manually. – Code-Apprentice Mar 25 '17 at 10:21
  • @Guapo Answer completely rewritten after our conversation in chat. – Code-Apprentice Mar 25 '17 at 10:57
  • Awesome thank you very much that is very much what I need. No+1s or check as right answer was as valuable as the time you took to explain things to me on the chat which I am very grateful for. – Guapo Mar 25 '17 at 10:58