On Thu, Sep 20, 2018 at 08:33:57AM -0700, checkmen...@gmail.com wrote:
> I have my project hosted in a gitlab server. The master branch used to
> be updated often after every local modifications and commits.
>
> The project folder name of the initial copy is myproject.
>
> Later I backed up this copy and started work on a local copy of the
> project with the project folder name myproject-dev. This had .git and
> I added, modified and deleted some files. I locally committed the
> changes to this copy on my local git repository.
>
> Can I do git push origin master now so that the modifications done to
> this local copy will get fully reflected in the master branch.
>
> I had a fear of using the Git branch feature on my live project,
> That's why I did it this way. Please also mention how I could've done
> this properly using the Git branch feature.
## Background
Well, let's put these things in context first.
The first thing to understand is that Git repositories are not in any
way concerned with how you name filesystem directories containing them.
To be concrete, when you work with the Git repository located in "myproject"
or in the repository located in "myproject-dev", Git pays no attention to
the names of these directories.
So, you may well forget about these details and read on.
The next thing to consider is that at first you had two Git
repositories: on local, in the "myproject" directory, and one remote -
hosted by the GitLab server. When you literally copied the "myproject"
directory into another, "myproject-dev", you effectively cloned the
local repository at the state it had just before the copy.
Since that was a full copy (I beleive), you have also copied the
configuration of that initial local repository, and the configuration of
a Git repository stores things like the names of remote repositories it
is able to talk to and the logical linkage of branches in the local
repository with the branches in remote repositories.
This fact means it's perfectly possible to do something like
$ git push origin master
from "myproject-dev". It will work. But there might be a problem which
has to be understood - read on.
## What to do with divegred histories, if any
I warn you up front that what will be written in a moment might be a bit
hard to absorb but fear not ;-)
When you do `git push `, the "receiving" branch must be
fully contained in the local branch being pushed, for otherwise the push
will be rejected by the remote side.
To explain it in simple words, if your local branch ends with the line of
commits
… → A → B → C → D
and the branch in the remote repo you're about to push to ends in the
line of commits
… → A → B
the push will succeed - as Git will update the branch in the remote repo
with the series C → D.
If, conversely, the receiving branch would end in something like
… → A → B → X
the attempt to update it with C → B would obviously fail.
What this means for you, is that _if_ after copying "myproject" into
"myproject-dev" you have recorded one or more commits on "master" in
"myproject" and then pushed "master" from there into "master" hosted by
GitLab, and in the meantime recorded _another_ series of commits on
master in "myproject-dev", it is unlikely that an attempt to push
your commits from "myproject-dev" will succeed due to the reasons I
explained above.
If you will find yourself in this situation, you will need to reconcile
the divergent lines of development done in "myproject" and
"myproject-dev". The usual approach to this is as follows:
1. Make sure the latest work is pushed from "myproject" to GitLab.
2. In "myproject-dev", do the so-called rebasing:
- Bring the latest changes from GitLab into the local repository:
$ git fetch origin
- Rebase your local work on top of the changes the "master" branch
hosted in GitLab contains:
$ git checkout master# if not done yet
$ git rebase origin/master
3. Now push normally:
$ git push origin master
Make sure you have read and understood [1] first.
## Branching
As to branching, the simple advice is: do not be afraid of branching.
There _are_ things needed to be understood before you use it, but
branching is the bread and butter of Git, and to really leverage the
Git's powers, you have to grok it anyway.
Since long ago, Git contains a safety belt enabled in all local
repositories: the so-called "reflog" which records past states of your
branches when you do any "drastic" action on a branch - such as that
"dreaded" `git reset --hard` call.
As usually, I would advise to read the docs first!
People for some reason like to think it's okay to go full-on in bashing
their head against a tool and pray that would work. It won't. First
learn, then do. The book at [1] is a good starting point.
If you will find it too complicated, start with [2].
1. https://git-scm.com/book/en/v2/Git-Branching-Rebasing
2. http://tom.preston-werner.com/2009/05/19/the-git-parable.html
--
You
