I'm new to having git set up for multiple users. I typically used it by myself with only one branch. I have a questions that I couldn't find safe answer to via Google:
If I'm currently pulling a feature development branch into my dev server to test the feature and I suddenly discover the need for a hotfix can I re-branch(checkout) the hotfix branch (part of master not dev), pull the files in and start working on/testing a hotfix or will my next "git add ." add the files from the feature branch(which are still on the server) to the hotfix branch therefore mixing the two branches?
If I understand your question, I think your asking if, having changes on the development branch, and then switch to a hot fix branch, will the changes get intermixed with the new branch?
Typically, what I would do is use "git stash save" of any changes on the development branch, checkout the hot fix branch and dothe changes and commit, switch back to the development branch, and then "git stash pop..." To get the development changes back.
You can do "git status" after each step to ensure the working area has what you expect.
Related
As in the title: there's always the statement The source branch is 1 commit behind the target branch. How is it even possible: both master and develop branches are up to date, no one made any modifications in the meantime, and the merge request gets created via GUI operating on the most up to date version of the repository, isn't it?
I read GitLab documentation saying that it could be the merge commit counted as this 1 commit behind, so I changed my project settings to:
It didn't change anything however: there's still the same message:
So far, I make a rebase in the following way:
git checkout master
git pull
git checkout develop
git merge master
git push
to line up the branches, but I'd like to save myself these few additional steps. Is it possible to achieve?
I am using the Android Studio functionality to manage my branches/commits etc.
I have the master branch which is reserved for final versions, then I have my development branch and then I open new branches for any features I want to work on.
I've just noticed that my changes in my new branches are automatically merged into my previous branch.
For example, if I'm on the development branch then create a new branch "Image gallery" and add something, when I go back to the development branch, that thing I've added is already there!
This beats the whole purpose of using branches, what is going on? Did I click anything I shouldn't have clicked?
If we are not commit the changes which we are done in the feature branch(image branch), it will added to the development branch when we change the branch local. First we need to commit the changes which is done feature branch(image branch). Then we need to change the branch to the development.
I'm new to Git and I'm really confused here. I have a HTTPS from my github, and I am using terminal from a virtual box to try to pull the latest files from one of my branches.
Everytime I use the following command:
git pull http-link or git clone http-link
it only pulls the files from the master branch, and not ALL the branches. I know this because when I run git branch I only see the master branch, and not the develop branch that I have in github. I want the files from this develop branch (NOT master) so I can push the changes to that branch, before merging to master. Please advise.
it only pulls the files from the master branch, and not ALL the branches
The rules for pull are somewhat configuration-dependent, but I can tell you that when you clone it is getting the entire history (all branches) unless you give it specific options telling it not to (such as --single-branch).
I know this because when I run git branch I only see the master branch
That's because by default git branch lists the local branches, and not every known branch from the remote(s). You can say
git branch -a
to see the rest. They'll appear with names like
remotes/origin/branch-name
because what you have are not proper branches; rather these are sort of "bookmarks" that tell you where the remotes branches were, when last you fetched from the remote.
By default, cloning does not automatically create local branches for every branch on the remote (but it does fetch the branches). By default cloning does check out the default branch from the remote (master in this case), creating the local branch for it. And there are shortcuts built in to git such that, in a typical configuration with a single remote, you can say
git checkout branch-name
to create the local branch corresponding to the remote's branch-name branch.
Note that when you do this initial checkout, you don't want to say
git checkout remotes/origin/branch-name
because that does something else. Rather than create the local branch, this simply puts you in "detached HEAD" state, with HEAD on the same commit as the remote branch.
My requirement is whenever developer try to do check-in existing GitLab repository then before doing check-in in repository,build should trigger (Jenkins build) and Junit test case should run on new check-in and if passes then it should go forward and will allow developer to do check-in in main repository.
I am not sure but is pre-hook commit can achieve this requirement?
While you could achieve this with pre-commit hooks, it's more common to do so with post-commit hooks on the server-side.
You can achieve this by operating a branch based workflow, there are multiple to choose from - I would recommend reading through this guidance by Atlassian.
Developers will create branches from a 'main' branch (often master, but can be a 'dev' branch working towards a release for instance), then develop code on that branch. They will then push their branch and commits to the remote repository (GitLab). When ready to merge into the main branch, your developers can open a merge request onto the main branch.
On GitLab you can setup a webhook to trigger Jenkins builds when a push event occurs. I would recommend this guide to guide you through it.
In the GitLab project settings you can require a passing build before merge requests are allowed to merge.
Furthermore, your understanding of Git seems incorrect - check in is not a term used in Git. Please take a look at the Git documentation. In Git a developer creates commits against a local copy of the repository, then pushes these to a remote repository (GitLab/GitHub etc.). There is no direct equivalent of the 'check in' used in various centralised version control systems e.g. SVN.
I am working on my master branch and have some uncommitted changes inside the master branch. I have already created a feature branch and I am able to switch to my feature branch using the git checkout feature_branch command. I have couple of doubts here which I am listing below:
Why am I seeing the uncommitted changes in my branch when I have made my changes inside my master branch. If I commit my changes in the master branch and switch to my feature branch, I do not see the committed changes specific to master. I am expecting the same behavior for uncommitted changes also.
I came across the stash command in Git and there it was mentioned that if you have any uncommitted changes inside the master branch, and would like to switch to some other branch, git will not allow you and hence you need to stash the changes inside the master branch and then only switch to the development branch. I did not face this issue. Am I missing something here and if so, what is the significance of using the stash command?
If I commit my changes in the master branch and switch to my feature branch, I do not see the committed changes specific to master. I am expecting the same behavior for uncommitted changes also.
That's not a sensible behavior. Uncommitted changes are by definition not made to a branch. Branches are pointers to commits, and there is no commit associated with uncommitted changes. They are made to your working directory and have nothing tying them to any branch. They aren't even associated with Git. Until you commit (or stash) them, Git does absolutely nothing to track them, and it will never try to manage them for you.
I came across the stash command in Git and there it was mentioned that if you have any uncommitted changes inside the master branch, and would like to switch to some other branch, git will not allow you and hence you need to stash the changes inside the master branch ...
That's wrong. Stashes don't exist inside any branch. There is one global pool of stashes.
... I did not face this issue.
You will only be prevented from switching branches if doing so would cause your uncommitted changes to be overwritten.
Am I missing something here and if so, what is the significance of using the stash command?
You only need to worry about stashing your changes if they affect any files that would be changed by switching branches. If you have modifications to a file that is identical between two branches, switch from one branch to the other will not require a stash. If the file is different on your other branch, Git will not let you switch branches, as this would destroy your uncomitted changes.
It is safe to try switching branches, and if Git warns you that "uncommitted changes would be overwritten" and refuses to switch branches, you can stash your changes and try again.