I used git branch -d myBranch to delete a branch. However, when I am on master and try to checkout a new branch with git checkout, myBranch still appears in the tab-autocomplete.
How do I remove the name myBranch from tab-autocomplete for git checkout?
git fetch --prune --all
Posting this as its own answer since it's a one-line fix, but if you vote be sure to vote for twalberg's answer.
twalberg's suggestion to git branch -a led me on the right track; my coworker suggested git fetch --prune --all to prune all the dead branches from all the remotes, which is useful when working with lots of devs with lots of forks.
One possible reason for this is that, if a remote branch (e.g. origin/myBranch) still exists, then git checkout myBranch will succeed as an alternative to git checkout -b myBranch origin/myBranch. This is intended as a convenience for the common case of checkout out a remote branch for the first time, creating an identically named local tracking branch.
There are other possibilities, too, depending on what exactly you are using for completion, but that's one of the first things I'd check. If you run git branch -a, and there is an origin/myBranch listed (or one for a remote other than origin, if you have such), then that's a likely culprit.
Depending on your setup, there is another source of what might look like old or deleted branches - your git-completion may also be suggesting tags along with branches.
I was fooled by this recently - our CI/CD pipeline tags all our builds, and even though certain branches would be released and/or deleted years ago, the tags persisted. Cleaning up old tags on the remote was the solution here (there is a guide here).
(I answered this here as well - not sure if it counts as a duplicate as it's on StackExchange...?)
Related
I have small experience using git repos. So i'm a little bit confusing, trying solve my problem.
I use Xcode installed (not vie terminal) git system and remote github repo.
The problem is for some reasons I've been commiting code for last 2 weeks not inside my master branch (it's the only one), but somewhere else (in source control navigator it seems on project level (high blue folder with project name)). So because of that i coudn't and still cant push changes to github.
if i select master branch, the last commit was 2 weeks ago. However if i select highest blue folder with project name, i see fresh commits.
How can i carry over all commits (or at least the last one) back in my master branch, which is connected with remote github repo and not lose data?
And what actually happened?
From your comments, it appears that somehow you ended up in a detached HEAD state, to which you have made several commits. However, it is easy to get out of this situation. Just checkout a new branch from your detached HEAD state, and then merge this branch back to master:
# from ac4c47c
git checkout -b your_branch
git checkout master
git merge your_branch
Then, you may push master to GitHub. Or, you could push your_branch to GitHub and open a pull request back to the master branch. Note that if you have unfinished work currently in your working directory and/or stage, you should finish it and then commit before creating your_branch.
Hello so I've done this before I just completely forgot how.
What I am trying to do is I have a remote on my github repo and I have an old version that I would like to revert to meaning I can commit from it and it would now be at the top of the repo if that makes sense since my current repo is having some issues and I want to go back to a specific version.
I remeber slightly what I was able to find out last time which worked out beautfully and that was I checked out the version I want and then I created a new remote or split the remote or something, added the version on to the new one and then merged the branches or remotes. It was something along those lines, I just don't remember exaclty and I would appreciate someone guiding me through as I am unable to find the old posts I was previously looking at.
This is a Swift Xcode project
Thank you in advance for all of the help
Instead of rebasing/restting your branch, you could revert the past commits you don't want, in order to create a new commit which would restore the state of the branch to the content of an older commit.
See "Git reset --hard and a remote repository"
git revert HEAD~N
git push
Using terminal git, you can do git rebase -i HEAD~N where N is the number of commits you want to backtrack. Then you can choose to drop or edit commits. In your case, you only need to drop the most recent commits and then you will be effectively back to one of your previous commits. In other cases, this can be used to combine/split commits as well.
Hypothetical:
I'm working on a project and let's say I create a branch table-settings off of master. I commit changes to three files:
plate.swift
bowl.swift
fork.swift
Someone comments on my pull request and says, "We don't need those changes to plate.swift right now.
Either on github, the command line, or a source control desktop app, is there a way that I can revert all changes to a single file in a commit or pull request, back to the state it was in when I created the branch?
What makes this different from "How do I revert a file to the previous commit", is that I'm wondering if I can revert a file that's been edited and committed multiple times, to the state that it was at when I created the feature branch it's on.
If you want to make it to a state that's in master then do following from your branch
git checkout master -- /path/to/plate.swift
above command will make it to a state, that's in master. Then commit and push normally. e.g.
git commit -m 'reverting not-required changes'
git push;
Thanks!
The duplicate link in the comments basically has you covered, but in this situation I might be inclined to do the following:
git checkout HEAD~1 path/to/plate.swift
This will reset plate.swift to the version one revision prior, when you created the branch. Then you can amend the commit via
git commit --amend
Now your commit will contain all the previous changes minus the changes to plate.swift, which file will appear unchanged. You would then have to force push using this:
git push --force origin table-settings
The reason the force push is needed is because we have rewritten the last commit in the branch. But this approach is possibly nice for the reviewers, who will see a feature branch which looks very similar as when they commented.
If your feature branch has already been checked out by reviewers, then a safer option would be to just do a normal commit:
git commit -m 'reverted Plate.swift'
But I have found that amending can be useful when you end up having to make a number of tweaks to a pull request but you don't want to uglify your branch's history with many commits.
I am new to git. I know few basic things about git and I have quite successful in using it.
So I have a master, develop branch. From develop I have branched out to a feature branch and a release branch. For branching out from develop I used the following commands.
jgitflow feature-start from develop
jgitflow:release-start from develop
Now I am done with the feature and I want to merge into develop. I am doing this for the first time. Now I am confused as to how to do it. Ideally I should be using the below command:
jgitflow:feature-finish
The other option I believe is doing a pull request.
Please let me know which is the correct options and what happens if there are conflicts while using jgitflow:feature-finish
Pull Request is essential as it would get the changes reviewed. However, if you merge from the PR, you would still be able to run jgitflow:feature-finish, albeit it will result in keeping the remote branch (if pushed before).
Ideal way would be to
Raise PR for the feature, get it approved.
Run the feature-finish command to merge the changes to develop and clean up the local
and remote feature branch.
To resolve conflicts, it is always better to pull from develop locally instead of merging through feature-finish as it can get messy.
The details are available at https://bitbucket.org/atlassian/jgit-flow/wiki/goals/feature-finish
Use the necessary flags like keepBranch, squash based on your requirements.
You should also use featureRebase as true. This will rebase the feature branch before merging from the origin which is develop in your case. This will allow you to handle conflicts in a better way.
The easiest way to avoid conflict when trying to finish a feature is to adhere to the following workflow before executing finish-feature:
git fetch: make sure your local repo copy is up-to-date
git checkout develop: go to develop
git merge origin/develop: make sure your local develop is up-to-date (origin being the remote's name here)
git checkout <feature-branch>: go to you feature branch again
git merge develop: Merge and solve conflicts, if any (on you feature branch)
mvn jgitflow:feature-finish you already solved the conflicts, so this will work
I would not recommend the featureRebase option which was mentioned in another answer since you said you only know a few basic things about Git. Rebase can complicate things if you have pushed your local feature branch and other people are working on it.
Rebase is only safe to use on local branches since it changes the history.
Regarding pull requests, see Gitflow Workflow With Pull Requests on https://www.atlassian.com/git/tutorials/making-a-pull-request/how-it-works
I've looked around the site but I couldn't find an answer that covers mine entirely, so please excuse me in advance if I missed it.
I inherited a VB.NET project that didn't have source control (it started as a pet project of a long-gone dev and nobody ever bothered after that to put it in), and by a friend's suggestion I thought about using Git for source control.
The project is a niche product that is customized and sold according to the customer's specs, so that brings the problem that even if 95% of the code is the same for all the customers, sometimes up to 10% of the code is changed and tailored for each customer, by changing or adding lines to existing functions, sometimes adding whole blocks of code, but there's no commonality in the changes between different customers (a function changed in one might not be changed in another).
To complicate things further, due to maintenance contracts, updates made to the baseline app have to be replicated in the customer's branches should they want them, and sometimes changes we make for a specific customer are good enough that we want to put them in the baseline app and replicate them to the other customers, BUT keeping the customizations for each customer!
So with my little knowledge of Git, I thought it would be like:
(customer 1)
C1-----
(main) /
A------B------D
\
\ (customer 2)
C2-----
\
\ (customer 3)
C3-----
...but I can't see how it's going to work after that:
Can I merge SOME changes from the customer's branches into the main trunk WITHOUT merging others that are only useful for that customer?
Can I merge SOME changes from the main trunk into each customer's branches WITHOUT losing the customizations in those branches?
Can I "mark" specific lines of code so they are not merged/committed?
Three or more devs will be working in this, each in his own machine but pushing changes to the company's repository for synchronization. What are the implications for this process?
Right now, every customer has a separate folder and separate project files with all their source code. How would be the import process to put those folders them into Git?
All of this must be done with Visual Studio, with Gitextensions and the Git Source provider for VS. Is it supported, or it has to be done with the console?
Thanks and sorry again if it overlaps with another answer.
I'm relatively new to git and normally use PoshGit for all my operations, so while I may not be able to help you with everything, I hope I can help with some things:
Can I merge SOME changes from the customer's branches into the main trunk WITHOUT merging others that are only useful for that customer?
Can I merge SOME changes from the main trunk into each customer's branches WITHOUT losing the customizations in those branches?
From what I understand, both of these operations can be achieved by using git cherry pick, which allows you to pick a particular commit from one branch, and add it to another without merging the branches together.
For example, assuming you want to add a change made to customer1's repository, to customer2:
First you get the hash ID of the commit from customer 1 that you want to insert into customer2
git checkout customer1Branch
git log
commit 2e8c40025939e8cf41dec70f213da75aa462184b
Author: xxxxxxx
Date: xxxxxx
This made a change that you want...
You then copy the first few characters of the hash you want to cherry pick, change to customer 2's branch and cherry pick it into the branch.
git checkout customer2Branch
git cherry-pick 2e8c40025939e8c
Now, if you do a git log, you'll see your cherry pick at the top. A similar tutorial can be found here (http://nathanhoad.net/how-to-cherry-pick-changes-with-git)
Can I "mark" specific lines of code so they are not merged/committed?
You may find help from a similar question was asked and answered here:
Commit only part of a file in Git
Three or more devs will be working in this, each in his own machine but pushing changes to the company's repository for synchronization. What are the implications for this process?
Since GIT is a fully Distributed VCS, each dev on your team will effectively have a full clone of the central repo on his own machine (complete with full history of that repo.) This means that log history queries and other requests (such as finding out who did what) don't need to go through your central server, but can be done privately and offline by each dev.
Similarly, the changes that each dev makes will become available to all of you (for example, all new branches will be available), but it can sometimes be frustrating to be working on the same features if you're not quite used to git.
As always its a good idea to commit early and often, this will decrease the tension you're likely to face when changes clash. you should also set some structure to when pushes are done, especially if you rely on each other's work to continue.
Another idea you may want to try is having one person in charge of the repo and having him merge changes and patches to help coordinate your efforts.
Right now, every customer has a separate folder and separate project files with all their source code. How would be the import
process to put those folders them into Git?
EDIT
Thanks for clarifying what you meant by this question. You could expand on a similar approach adapted from the answer given here: How do you create a remote Git branch?
Create a new mainline branch for your BASE project and push it to your remote repository.
cd baseProjectDirectory # navigate to your main project directory
git init # git initialize the dir
git add . # recursively add all files in directory to git repo
git remote add <remote-branch-name> <remote-url> # Add the url to your remote directory to your git repo
git commit -m "Initial commit of base project"
git push <remote-branch-name> <local-branch-name>
This will establish your Baseline project on a remote repository called remote-branch-name under a branch called local-branch-name.
You can then navigate to your other projects and repeat these steps putting your repositories under different branches on the same remote, by using new local branch names, i.e. instead of using the local-branch-name when creating a branch, just use a new branch name, such as git checkout -b new-local-branch-name
so if, for example your base project push (the last line of code) was:
git push clientproject base
Where "clientproject" is the name of your remote, and "base" is the name of your local branch, you can just change the line to:
git checkout -b client1 # Creates new branch named client1
git branch -d base # Deletes base branch
git push clientproject client1
Note that while it's not strictly necessary to delete the "base" branch before continuing, it does keep your repository cleaner and is thus considered good practice. Don't worry about losing anything though, your entire git history from base will be copied to client1 on checkout.
Also note: Since your situation requires you to do this from different directories, you'll probably be deleting a branch named "master" and not "base".
Pushing like this will keep client1 on the "clientproject" remote, but will place the project under on a new branch called client1, complete with its own history.
The same steps can be used for the rest of the projects. If I've lost you anywhere along the way, I suggest reading the above link (it's much more concise than I am).
All of this must be done with Visual Studio, with Gitextensions and the Git Source provider for VS. Is it supported, or it has to be done
with the console?
I haven't yet used VS with Git, but I assume most if not all these operations would be supported since they are native git commands.
Hope this helps.