barrjamy via Git for human beings schreef op 14-05-2017 20:20:

> We have access to: 
> 
> Git Enterprise, Git Bash, Git stash (same as bitbucket?) and Git Desktop (I 
> think)

I don't have answers, but don't forget that BitBucket also has
SourceTree, which seems to me like a good client, I haven't used it yet,
because I haven't done anything on Windows, but if you use Windows, or
the Mac, you can use it probably? 

https://www.atlassian.com/software/sourcetree 

I will say that Git is a Git. 

Like Linus says, ;-), it is an asshole. 

Git generally means to me learning a default mode of operation or
workflow out of the millions of things you can do. Once you limit
yourself to that workflow, git becomes managable. 

The question is learning or defining that workflow that you agree with.
In actual fact I don't really think there are millions of viable
workflows. There are only a few that work. 

- it should be possible to easily copy commits from one repository to
another, not just from branch to branch. 

- the dev to main project branch is simple enough 

- the question seems to be on how to identify and copy changes into your
backup set 

- in general a backup can just be a copy of a repository that only
rarely pulls from the main (project) repository 

- this feels a bit unsafe, so I guess you want to create real
(independent) copies, but copying changes normally does come down to
copying commits 

- if you don't want to version the backup set it would be possible to
identify all files changed in the latest commit or since a certain date.


- if the backup set is a repository it can just pull the changes from
the other (main) repository 

- what you get is different versions of the same repository that are
just different locations on disk or on servers 

- therefore all of these versions are really just near-identical copies
that just see different moments of being updated or pulled into 

- there would be no identifying what has changed, git does this for you,
but you don't have fixed files on disk. 

- all files sit in a "working directory" that can change at a moment's
notice if you run a Git command 

- backups of these repository copies become very important. 

- if you want real, fixed data directories (file hierarchies,
directories) you would have to 'mine' data from the real git
repositories in creating copy scripts 

- it is possible to only fetch the main (master) branch of the project
repository and leave the development branch out of it 

Thus far it doesn't seem like you would be doing anything special. You
just have different stages of "pulls" from one clone to another. 

You say you have "numerous" project areas. 

Then either the backup and the live versions will also have those
branches (but only one can be checked out at any one time) or you have
to merge them but branches are not directories.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to