i am pretty new to GitLab and have a question concerning branches and updating the local repo.
Around two weeks ago i cloned a project and did a bit of work on it (mainly added one branch). Other people also have local repositories of that same project (hope that makes sense). Now I would like to clone only a single branch of one of those local repos made by other people and include it into my local repo.... How do i do this? Ofc I can clone the branch into a different directory, but my goal is only having one directory with only one name in which that branch is contained, so that I can switch between the branches I had from the beginning and the new branch I cloned.
Basically, in order to be more clear: There is a project called a_proj. Me and another person have cloned a_proj and therefore have local repos on which we do work. The other person added a branch called a_branch which I don't have. I want to include a_branch into my version of a_proj.
Additionally i have a different question concerning updating a branch. What if some person does some work on their local version of a branch I also have on my Local and I want to include their changes, or even change my branch to their version. How could I do that?
Thank you a lot for any helpful answers on this topic. If there is constructive critic about this post or the way I think about GitLab I am happy to hear it, as already mentioned, this is a pretty new topic to me and I want to learn wherever i can!
Okay, i figured it out. Was pretty easy actually once one knows what to do. For information, i am using GitKraken so it might be different for different environments but essentially the idea is to add the other person's project as remote, (where ones own project should also be a remote named origin). Then one can add any branch of those remotes to the Local project, simply by checking out the wanted branch. It then gets added to the Local repository on which work can be done.
I guess that isn't anything new to anybody who uses GitLab but i'll just leave it here in case some noob (Like me) also has this question.
Related
We are using Git for a website project where the develop branch will be the source of the test server, and the master branch will serve as the source for the live, production site. The reason being to keep the git-related steps (switching branches, pushing and pulling) to a minimum for the intended user population. It should be possible for these (not extremely technical) users to run a script that will merge develop into master, after being alerted that this would be pushed to live. master cannot be modified by normal users, only one special user can do the merge.
This is where I'm not sure how to integrate this identity change into my code below:
https://gist.github.com/jfix/9fb7d9e2510d112e83ee49af0fb9e27f
I'm using the simple-git npm library. But more generally, I'm not sure whether what I want to do is actually possible as I can't seem to find information about this anywhere.
My intention would be of course to use a Github personal token instead of a password.
Git itself doesn't do anything about user or permission management. So, the short answer is, don't try to do anything sneaky. Rather, use Github's user accounts they way they were intended.
What I suggest is to give this special user their own Github account, with their own copy of the repo. Let's say the main repo is at https://github.com/yourteam/repo, and the special repo is at https://github.com/special/repo.
The script will pull changes from the team repo's develop branch, and merge this into it's own master branch and push to https://github.com/special/repo.
Then, it will push its changes to the team's master branch. This step can optionally be a forced push, since no one else is supposed to mess with master, anyway. (In case someone does, using a forced push here means they have to fix their local repo to match the team repo later on, rather than having the script fail until someone fixes the team repo.)
At the same time, your CI software will notice that master has changed at https://github.com/special/repo, and will publish as you normally would. This is the linchpin: the CI doesn't pay attention to the team repo, so although your team has permission to change it, those changes don't make it into production.
This special user will need commit access to the team repo, in addition to its own GitHub repo. The easiest way is probably to use an SSH key, and run the git push command from the script, rather than trying to use the GitHub API.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I want to become a Git expert since I use it at work but only half understand it and several times have lost over a day's work because I ran some wrong commands. I've found several tutorials on the internet, but I don't feel like any of them help me actually understand how the application works. All the tutorials say "Here's how to initialize a repo, here's how to make a commit," etc., but they never explain what's happening behind the scenes.
For example, I still don't understand what happens when I push: am I actually replacing the entire repository at the remote location with the one in my commit? By the way, is a commit and actual copy of a version of the repository or is it just information about the changes between my copy and some other version? I want to understand those types of things and I haven't found a tutorial that helps much.
I've recently found myself in the same boat and did a whole bunch of research.
The first thing you need to conceptually understand is that basically, Git works with three areas:
The Development Area, The Staging Area, and finally The Repository (Repo)
The Development Area:
This is where your files are held on your computer. When you install Git you essentially get a framework of commands that will allow you to designate what directories on your computer are to be considered a development area (along with the rest of the commands to do things -- we will get to that in a bit). To designate a Directory on your system as a place you want Git to keep track of you use 'git init'.
The Staging Area:
So this is what threw me off at first. When you make a change to a file in the Development area, you send it to the Staging Area before you send it to the Repository. Thing of this as a temporary space for changes. The reason this is done is so that you can make a number of changes and Commit them as a Set of changes for a Project. This is actually really helpful because it allows you to control what updates and commits you send out. To send a file you change in your Development Area to the Staging Area type "git add filename.ext" or if all the files in a directory are ready to go to the Staging Area just type "git add ."
The Repository:
When you are ready to send all of your changes from the Staging Area to the Repository you use the command: git commit -am "Message explaining the changes / what your are adding, etc." Then "git push"
Let Git Help You!
Things in Git can be confusing at first, so I also recommend letting Git help you out a bit. You can always ask Git what the status of your Working Area / Development Area by using the command "git status". This will guide you.
As you know, one of the biggest appeals of Git is getting someone's code from an Open source project, working on it locally, making changes and then asking them if they will take the changes you have made - adding them into the project.
The concept behind this is to clone a project to your local system, then do everything above.
Look, that is a simple overview and you obviously will have to supplement it. I recommend checking out Derek Banas' Youtube tutorials on Git here: https://www.youtube.com/watch?v=r63f51ce84A&list=PLGLfVvz_LVvQHO1PfyscjIPkNJjgHsLyH
So you want to be a GIT expert...
First, let me say that when I began switching over to GIT from Subversion I had the same questions. My first recommendation is a textbook, this one got me over the hump Version Control with GIT (looks like it's $3 now!). I have found tutorials on GIT to be very command-centric.
About particulars you mentioned:
git init : initializes the current directory as the root directory for the project; basically it puts a .git/ directory there which where all the inner-workings of the repo are stored.
Pushing : you are not replacing the repository, you are PUSHING your lasted commits (git objects,files,modifications,etc) so remote is aware of the target branches history log
What is a commit? Think of a commit like a saved state that you can always go back too, but it's a little more than that since it can be compared against, and retain other info like who did the work and what time it was done.
I'd like to know if your switching over from another VCS cause if not it would make sense to do primary research on VCS concepts. GIT has fundamental differences which make it superior most of the time.
Last note is GIT doesn't store your files, it stores hashes of your files. -Good luck.
I started exploring Gitlab for version control management and I got an issue at the first step itsself. When ever I create a project its creating a new repository. I have few webapplications which are independent to each other. In that case do I need to use different repository for every project.
What I am looking for is what is what and when to use what but not able to find what is repository and what is project in gitlab website as well as through other sources as well.
Also I came across a term submodule, when can it be used. Can I create one global project and have all the webapplications as different submodules.
Can any one please help me in understanding the difference between those 3 and when to use what based on their intended way of usage. Also please help me by pointing to a good learning site where I can get the information of doing basic version control operations in gitlab.
Thanks.
Gitlab manages projects: a project has many features in addition of the Git repo it includes:
issues: powerful, but lightweight issue tracking system.
merge requests: you can review and discuss code before it is merged in the branch of your code.
wiki: separate system for documentation, built right into GitLab
snippets: Snippets are little bits of code or text.
So fear each repo you create, you get additional features in its associated project.
And you can manage users associated to that project.
See GitLab documentation for more.
The Git repo and Git submodule are pure Git notions.
In your case, a submodule might not be needed, unless you want a convenient way to remember the exact versions of different webapp repo, recorded in one parent repo.
But if that is the case, then yes, you can create one global project and have all the webapplications as different submodules.
Each of those submodules would have their own GitLab project (and Git repo).
I am new to the world of grunt but I feel like there must be a way to do this. Hopefully I can explain my issue in a way that makes sense so you can be of assistance.
Essentially, I have a git project, including a gruntfile, that I use to start all new websites. I clone the project, delete the .git folder and setup a new project in bitbucket for it. Over time I have had to make some modifications to the gruntfile and it is annoying to go back to an old project where I hadn't made those modifications. Is there a recommended way to ensure that my template is up to date on all of my projects?
Things to note:
1) I am familiar with grunt scaffolding but I have never used it, is this the use case for it?
2) my projects live in bitbucket and are private. My initial solution to this problem was to use grunt curl and pull the latest and overwrite the previous gruntfile
3) The issue with #2 is that I would need to put my username/password in the path and can't figure out how to prompt the user, even if I do and they enter the login incorrectly bitbucket still returns something (a bad login page) and this would overwrite my gruntfile.
Thanks in advance! I appreciate anyones input
I assume you are using git with bitbucket. If that is the case you can do a pull from a master repo that contains your template grunt file in each of your project repositories for the desired effect.
See this answer for how to pull from a remote repo.
remote repo q
Since you only care about merging in changes from the Gruntfile.js you can pull it specifically from the remote template repo. I'd suggest following this pattern assuming you add the remote reference to you template repo when necessary:
From you project repo create a new branch
Pull the Gruntfile.js from the template repo
Resolve any merge conflicts
Merge with master
See the last answer on this question for how to pull a single file:
fetch a single file
I have synchronized a folder with folder in tortoise svn. Now I want to synchronize this folder with another folder in tortoise svn. How to do this. Please guide me
The mechanism in Subversion are a little bit different. You speak here from a checkout, if you work on a local copy. There are two cases here:
You want to work on a different part of the repository:
Checkout that part at a new location locally (so you are able to work in parallel on both).
Switch your current location to the new part of the repository. This will replace all files locally, and you are no longer able to work on both parts in parallel.
The first scenario is normally used. There are some cases where it may be not appropriate:
You have not enough place locally. You should change that first, because you are not able to work anyway.
You are working on a branch, and want to merge some of the changes on the branch on the trunk or another branch. Then a svn switch is the normal way to do that.
Alternatively, you may do a sparse checkout of the common parent of the two folders, and populate only the parts you are interested in.